OS 4.0: Saved State and task switching

[PeteLP]

One issue which I'm very anxious to learn about, and which has not seen much discussion, is how well 4.0 actually does in switching back to apps who were running. The ability to automatically save state in every app, switch to another app, and return to the app exactly as you were is a huge win for me. I'd love to hear from the beta testers on this regard.

- Are all apps working well in this respect?
- Are all current apps sufficiently well behaved to return to EXACTLY where they were? (I understand that stacks and registers are restored to their former condition, but I'm wondering if there are any/many quirks so far)
- Is switching back appreciably faster than loading, for Apps like Navigon (that can take 20 (?) seconds) to load from scratch?



UPDATED:
I understand now that only apps recompiled and released after the 4.0 upgrade will work with task switching. Given that, I'd greatly appreciate hearing from developers on your experience with your own apps, with respect to each of the above questions. Also, are you finding that, in addition to the compile, there are fixes required to get task switching working properly.

I'd very much welcome as many responses as possible

Thanks
Pete

 

[Kahnyl]

No third party apps work with it yet. Only a few Apple apps. And they work perfectly.

 

[PeteLP]

No third party apps work with it yet. Only a few Apple apps. And they work perfectly.

I had the impression that apps would be frozen as they were and restored without special programming in the apps. (That the OS was saving the state for all apps by use of OS code, requiring no special app code) I had the impression that only those apps that wanted to use background services needed to modify their code.

Have you tested this? Are you certain? This would be a big disappointment to me. So many apps currently do such a bad job at saving state, that I'd assume they would also fail to take those steps to assure saved state works.

OTOH if you're saying that a simple recompile will turn on this feature, that would be quite a relief.

Pete

 

[fishkorp]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.4 Mobile/7D11 Safari/531.21.10)

An app has to be compiled under 4.0 for it to work. I confirmed this by recompiling one of my apps. It only saves the state after a recompile targeted at 4.0.

 

[PeteLP]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.4 Mobile/7D11 Safari/531.21.10)

An app has to be compiled under 4.0 for it to work. I confirmed this by recompiling one of my apps. It only saves the state after a recompile targeted at 4.0.

Thanks for your response. That's a relief. Would you care to give me your impressions on the questions in my original post (including load time vs switching) as pertaining to your own apps?

Thanks
Pete

 

[peteo]

How is the saved state implemented? Is the memory that the app is using saved to the flash? or is it locked in memory? how hard is this to add to your program? (do you need to code your app to support a data base?)

 

[fishkorp]

From what I noticed, you do not have to do anything to tell it to save the state. The dev just needs to target the app for 4.0 and the OS automatically handles it. The speed on loading, at least my app, is a big difference. The app I tested on did not save which tab a user was on in preferences or anything like that. So every time the app started it would fetch data for 3 different tabs on startup, taking a few seconds of load time. With the 4.0 version if I quit the app, not only will music continue playing (that I had to make changes for), but any time I go back into the app it was in the exact same state it was when I shut down. So no reloading of the views, it was all instantaneous. If there's a thread doing something to update something in the view, it gets called as soon as it comes back into focus. There are other things that can be done when entering/leaving the background as well. The app I tried it on wasn't complicated enough to need to do anything else. So far, I think it's a great implementation, but still has a few limitations.

 

[peteo]

From what I noticed, you do not have to do anything to tell it to save the state. The dev just needs to target the app for 4.0 and the OS automatically handles it. The speed on loading, at least my app, is a big difference. The app I tested on did not save which tab a user was on in preferences or anything like that. So every time the app started it would fetch data for 3 different tabs on startup, taking a few seconds of load time. With the 4.0 version if I quit the app, not only will music continue playing (that I had to make changes for), but any time I go back into the app it was in the exact same state it was when I shut down. So no reloading of the views, it was all instantaneous. If there's a thread doing something to update something in the view, it gets called as soon as it comes back into focus. There are other things that can be done when entering/leaving the background as well. The app I tried it on wasn't complicated enough to need to do anything else. So far, I think it's a great implementation, but still has a few limitations.

Thanks for the info. So do you think its saving the state to flash (I doubt it) or just keeping it in ram. If its keeping it in ram, can you try opening up allot of web pages in safari and see if it kills the app?

 

[fishkorp]

Thanks for the info. So do you think its saving the state to flash (I doubt it) or just keeping it in ram. If its keeping it in ram, can you try opening up allot of web pages in safari and see if it kills the app?

It's in RAM. Your test isn't going to be valid in beta 1, because there are other memory issues (noticed leaks). Would be better to wait for a later beta to give it a real try.