11–20 of 35 posts
Can someone briefly explain how the "multitasking" works, then? I was under the impression that this will be possible, too. I suppose apps that are sent into the background are just frozen in their current state and continue to run where they left of, when going into foreground? Just a guess, though..
Can someone briefly explain how the "multitasking" works, then? I was under the impression that this will be possible, too. I suppose apps that are sent into the background are just frozen in their current state and continue to run where they left of, when going into foreground? Just a guess, though..
Starting with iOS4 developers have access to a set of APIs. Audio, GPS + 'Location', Push, Phone (think Skype), Worker and probably a few other APIs. Until now, when the user pressed the home button you were able to write your state to flash if necessary. Now there is another way to 'freeze' your app and keep the state in memory -- at least until iOS4 decides your app won't be needed soon and fully quits it to free m…
So, what is missing (i guess) is some background service API. Sounds pretty much like the Android way (minus the background service). But it should be good enough for the majority of apps, i think.
Earlier quoted context omitted.
Push Notifications have a very small payload on iOS; besides, the app doesn't get "woken up" and allowed to run to process the payload until it's switched to.
Right. The best they can do is to respond to the push notifications when the user next runs their app . So Instapaper could present the possible downloads in a dialog, then when the user agrees, use Task Completion to download them in the background. This might be workable, and would often be very useful, though less convenient than a true background fetch.
The advantage is that making things simpler allows them to concentrate and spend more time making them better, while the disadvantage is that it leaves lot of developers unable to meet their users' needs.
The alternative approach (Android) where APIs are pretty general allows far more developer power, then downside there being that it makes a lot of things harder/more time-consuming.
Part Apple's making-software-simple philosophy is that APIs are written for specific cases - you write apps for a single resolution in iOS, you call system services instead of multitasking etc. The advantage is that making things simpler allows them to concentrate and spend more time making them better, while the disadvantage is that it leaves lot of developers unable to meet their users' needs. The alternative appro…
I also like his idea of iOS only allowing polling when signal is above a threshold. Data requests while in marginal coverage chew battery at an extraordinary rate. Changing my Fetch frequency on 3 mail accounts from 15 mins to 60 mins more than doubled battery life.
ReMail approached this by setting a timer to remind the user to launch the app and download mail to index. The data load for checking mail with arbitrary attachment sizes is considerably more than what Marco's talking about. I'd bet the data transfer problem is something Apple considered.
Even for small data sets, using data continually adds up. After getting their first data bill, users might prefer to be manually in charge of their data usage.
They could even allow the users to set the checking interval – there is already a setting for (non-push) Mail, they wouldn’t even have add another one, just turn that setting into a “Load new stuff every X minutes” setting. (I’m certain that waking the device every thirty minutes, turning on the radios and then checking everything at once probably saves the most energy.)
Part Apple's making-software-simple philosophy is that APIs are written for specific cases - you write apps for a single resolution in iOS, you call system services instead of multitasking etc. The advantage is that making things simpler allows them to concentrate and spend more time making them better, while the disadvantage is that it leaves lot of developers unable to meet their users' needs. The alternative appro…
I like Marco's proposed solution, because polling is an easily abstracted or generalized operation. Pooling app polling would save a tremendous amount of setup and teardown time. I also like his idea of iOS only allowing polling when signal is above a threshold. Data requests while in marginal coverage chew battery at an extraordinary rate. Changing my Fetch frequency on 3 mail accounts from 15 mins to 60 mins more t…
I'm trying to illustrate how there is no perfect ideal approach.