iOS app crashes on startup under slow internet connections

Question

I'm using the beta Stack Exchange app version 1.4.2 with iOS 9.1. When I have a fast internet connection, it works as expected. However, when the connection is extremely slow (sometimes unusable), the app freezes for around 20 seconds and then crashes. This is worse than having no connection at all, since with no connection the app opens with an error message.

I found that under slow connections (GPRS¹ in this case), the app freezes with this screen and after around 20 seconds, it crashes:

With no connection at all, the app opens and errors as expected:

This is probably because the SE app tries (and fails) to connect to the servers when it finds a connection. I've noticed that when my wifi is a bit slower, the app takes a few more seconds to open.

¹ Although this (GPRS) is a type of internet connection, I couldn't manage to open any web page with it.

Answer 1

This will be fixed in the next beta build.

The app depends on the site list (/sites) for many things it does. As such:

1. it gets loaded before the first login. It is subsequently loaded once every 24 hours but continues returning old values until the new version loads.
2. we have a synchronous method on the site cache to resolve sites by host name or API site parameter. We're relatively certain the site should be there when the request is made.

Because some cases could arise that we call the synchronous siteForApiSiteParameter: and the site list isn't up to date, the method's default action is to try loading the cache and block until completion. This of course assumes that this will be a rare case and that the /sites API call should complete in a timely fashion.

You, however, have reached a state where this call is being made every time you load the app and the request is so slow the device's watchdog timer is killing the app because it still hasn't finished launching after 20 seconds.

My theory:

1. You opened the app. It may have kicked off the call to refresh /sites. This took a long time or failed.
2. The feed loaded, including a hot question from a site that was not in the app's site cache. The feed loading process blocked on the call to /sites.
3. You got sick of waiting and left the app. The app saved the contents of the feed to disk.
4. The app was terminated in the background without completing the call to /sites.

Now, every time you return to the app the feed prepares to render its saved contents, gets to the unknown site, and blocks on the call to /sites. Since you're on GPRS the app hangs and you get caught by the watchdog.

Solution

My solution has been to defer or eliminate calls to the /sites when rendering the sites.

The particular code you got caught on was for evaluating whether or not to display a site icon on a feed icon based on whether or not the preceding item was on the same site. There was no reason to even resolve the site here because the site parameters we had was good enough.

Similarly, the feed would pass the resolved site to the cell when rendering the site icon(s), meaning it would block when configuring the cell. Now the feed just passes the site parameters to the view and it either renders the known site or displays a placeholder background and asynchronously reloads /sites to display the icon when available.