Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>So, in general, performing heavy lifting on the main thread will cause the UI of the app to lock up. The OS is looking for applicationDidFinishLaunchingWithOptions to return after a reasonable amount of time. If it doesn't, it'll kill your app and give you the 8badf00d exception code. Just look at your elapsed time; more than 20 seconds! I've gotten 8badf00d for launches taking less than 5 seconds.</p> <p>And obviously you won't get this crash on all devices all the time. If your set up depends on internet connectivity (as mine did), you may get it on a device that is trying to connect on Edge or a shady WiFi connection. If you're doing a ton of heavy graphics stuff, this could pass the loading time threshold, as well. It's possible that the only reason you're seeing this in iOS5 is that Apple reduced the loading time maximum limit for iOS5 devices (better hardware, better software, load times should be better as well, one could make the argument). I would highly suggest kicking off the set up in a background thread. If that setup is integral to your application, consider loading up your splash screen first with a loading indicator, and removing that view once the set up is complete. From a user perspective, they would just see the splash screen on launch like normal, and then maybe an activity indicator or something appear, and then when it disappears they have a fully configured set up.</p> <p>The other options would be to optimize the heck out of your loading code so that it happens in less than a few seconds. But if you're at 20 seconds now, I don't see THAT much optimization being possible.</p> <p><em><strong>UPDATE:</em></strong> From the apple docs:</p> <blockquote> <p>The most common cause for watchdog timeout crashes in a network application is synchronous networking on the main thread. There are four contributing factors here: synchronous networking — This is where you make a network request and block waiting for the response. main thread — Synchronous networking is less than ideal in general, but it causes specific problems if you do it on the main thread. Remember that the main thread is responsible for running the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive. long timeouts — If the network just goes away (for example, the user is on a train which > goes into a tunnel), any pending network request won't fail until some timeout has expired. Most network timeouts are measured in minutes, meaning that a blocked synchronous network request on the main thread can keep the user interface unresponsive for minutes at a time. Trying to avoid this problem by reducing the network timeout is not a good idea. In some > situations it can take many seconds for a network request to succeed, and if you always time out early then you'll never make any progress at all. watchdog — In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time, the watchdog will kill your application and generate a watchdog timeout crash report. The amount of time the watchdog gives you is not formally documented, but it's always less than a network timeout. One tricky aspect of this problem is that it's highly dependent on the network environment. If you always test your application in your office, where network connectivity is good, you'll never see this type of crash. However, once you start deploying your application to end users—who will run it in all sorts of network environments—crashes like this will become common. Warning To summarize, if you make synchronous networking calls on the main thread, your application will suffer from watchdog timeout crashes when it's deployed to a wide range of users.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. POApp Crashes on Startup with iOS 5 - Cannot Reproduce
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USjmstone617
    1. USjmstone617
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the input. Actually the app launches within 1-2 seconds, and works fine for 99% of our users (who number in the hundreds of thousands). The real question is: why is our app taking 20 seconds to launch on these rare occasions that it crashes? All of the startup code is handed off immediately and there's no reason for startup to be taking so long. The crash log doesn't seem to point to any of our code.
      singulars
      1. PO
      1. This table or related slice is empty.
    2. CO[self performSelectorOnMainThread:@selector(loadGame) withObject:nil waitUntilDone:NO]; does not hand it off. It performs this on the main thread.
      singulars
      1. PO
      1. USjmstone617
    3. COIt does allow applicationDidFinishLaunchingWithOptions to return immediately.
      singulars
      1. PO
      1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload