[mitchellh]

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.

[barbs]

> 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]

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

[andrewmackenzie]

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]

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]

Gotcha. Thanks for the insight. Strange to launch an app with such an issue.