3 ms·

Great redesign. In case any TripIt engineers/employees/etc are browsing, I do want to say that design aside, the biggest issue with the iPhone app is that API

Great redesign. In case any TripIt engineers/employees/etc are browsing, I do want to say that design aside, the biggest issue with the iPhone app is that API requests are made in the main thread, so the GUI locks up. It is incredibly annoying to tap on a page, have it be frozen, then a few seconds later the API requests finishes and it processes your tap which takes you to a SECOND screen which requires an API request, and you're frozen again. TripIt should be one of those apps that is "open, read, close" in 10 to 15 seconds. The API requests are brutal, brutal.

andrewmackenzie 14y ago
Ya that's what devs were telling me while I was working on it. Could loading the app on individual "event cards" with cached data, like I proposed, potentially "solve" that problem? Or is there a better way? If there are no upcoming trips or cards, I designed an empty main Trips table to load instead. Was the least interesting of the comps, so I left it out of the site.
- SeoxyS 14y ago
  The main problem isn't a design problem, it's a problem of the developers being incompetent. Accessing network resources on the main thread is a massive beginner mistake. Though pre-loading the card with cached data while the real data is being fetched is absolutely the best solution and experience.
  - andrewmackenzie 14y ago
    Gotcha. Thanks for the insight. Strange to launch an app with such an issue.
barbs 14y ago
> The biggest issue with the iPhone app is that API requests are made in the main thread, so the GUI locks up. Wow, really? That seems like a major oversight. I'm pretty inexperienced in the iPhone development scene, but I know with Android development this sort of thing is strongly discouraged. There's even a mode called "StrictMode" where any file and network access on the main thread will cause a crash instead of hanging.
- srik 14y ago
  Blocking the main thread is just as much discouraged in iOS development too. Wonder how it got through testing.

andrewmackenzie 14y ago

Ya that's what devs were telling me while I was working on it. Could loading the app on individual "event cards" with cached data, like I proposed, potentially "solve" that problem? Or is there a better way? If there are no upcoming trips or cards, I designed an empty main Trips table to load instead. Was the least interesting of the comps, so I left it out of the site.

SeoxyS 14y ago
The main problem isn't a design problem, it's a problem of the developers being incompetent. Accessing network resources on the main thread is a massive beginner mistake. Though pre-loading the card with cached data while the real data is being fetched is absolutely the best solution and experience.
- andrewmackenzie 14y ago
  Gotcha. Thanks for the insight. Strange to launch an app with such an issue.

barbs 14y ago

> The biggest issue with the iPhone app is that API requests are made in the main thread, so the GUI locks up. Wow, really? That seems like a major oversight. I'm pretty inexperienced in the iPhone development scene, but I know with Android development this sort of thing is strongly discouraged. There's even a mode called "StrictMode" where any file and network access on the main thread will cause a crash instead of hanging.

srik 14y ago
Blocking the main thread is just as much discouraged in iOS development too. Wonder how it got through testing.