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 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.
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 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.
Well, Marco has no solution - he has to lobby Apple to include APIs he needs for his app. His lobbying isn't going to improve his users' experience. I also can't port my app to the iPhone, as it would require me to lobby Apple to include APIs I need.
I'm trying to illustrate how there is no perfect ideal approach.
Most of Apple's APIs are wonderfully general (e.g., look at their full 3d-aware Core Animation capabilities that are better than any desktop system (other than Mac OS X, which shares the same capabilities).
They specialize APIs when it would be harmful to generalize.
They're fighting at every turn for battery life (I'm at WWDC this week, and have seen that mantra (optimize for battery life) at nearly every talk), which is tough on developers but great for end users.
Pandora and Skype can network in the background; I don't understand why Instapaper can't. Maybe it could play some John Cage while downloading to qualify as an "audio" app. :-)
Right. The other common case is just holding a socket open, for IM and SSH clients among others. That uses much less resources than streaming audio, but it's apparently not allowed either.
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 memory.
If you use the APIs mentioned above it is possible to continue playing (streaming) music, doing something else during a Skype call or update your location whenever you connect to a new cell tower* . If you need turn-by-turn you get access to constantly ask for GPS, this aside from calling/playing music is the only 'real' multitasking as it continues in the background until you tell it to quit.
The Worker API allows you to complete a task, for example continue uploading that video file to Dropbox. Once it's done the Dropbox app quits (or is frozen in memory as everything else).
Push notifications allow to access a server but it seems as someone else here mentioned the payload is too low, and only accessible as soon as the app is activated.
I can't tell for sure though as I'm not an iPhone developer just following it closely and most of this information comes from the January(?) keynote when iOS4 was introduced.
*Because GPS sucks battery you app gets called whenever you connect to a new cell tower, this according to Apple, should be sufficient for services like Google Latitude where the exact position at any given point isn't that important like it is for turn by turn navigation.
Ahh, great thanks, this is a really good summary! :)
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.
I think Apple could solve all of this by adding something as simple as a crond that executes processes at scheduled times, similar to what Marco is requesting.
I'm sure Apple would do it properly and have all apps with scheduled tasks accessible from the Preferences screen so you could disable or change the schedule of them easily.
There is real multitasking for Native apps like iPod, Mail, Phone, SMS, Safari, Clock, etc. Apple has chosen to not allow other apps to run in the background on a permanent basis due to memory concerns. Indeed, the iPhone and especially the iPad runs out of memory shockingly easy. I have noticed that iOS 3.2 on my iPad is actually intelligent enough to start unloading backgrounded native apps from memory when I get low on RAM. I'm running SBSettings and Backgrounder on a jailbroken iPad and I can see that when I get down to about 10-20MB free apps will start getting closed.
As long as these idevices only have 256MB of RAM this will be a problem. I think the approach Apple is taking is the right approach. An app like Pandora should be able to spin off a "stub" process that doesn't have any of the UI overhead but simply the network and audio code to continue playing an existing stream.
These are all "hacks" that will hopefully be outdated in a couple years when we're hacking away on our A9 cortex 2 ghz. dual core iPads with 4GB of RAM.... (hey, I can dream right?)
That’s exactly what Apple should do, hopefully soon.
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.)
This is a really simple and strong proposal. It's amazing the power that a single url fetch request can have, although the ability to post data is probably necessary for a number of categories of work (for example, any location based apps).
That these background services are not composable puts some limits on their potential usefulness, but it sounds like this plus the existing services would cover most bases.
This is the issue with Apple's 'multi-tasking' model. Want to write an alarm clock replacement? Can't do it, you need a hook that doesn't really exist. This guy needs this hook. Someone else will need another hook. Does apple play os whack-a-mole (creating a lot of fragmentation)? Or are you just out of luck for a whole load of apps?
While I don't necessarily disagree with your point, an alarm clock may not be a good example. It looks like you could use scheduled local notifications for that.
Don't those work more or less like the network notifications? They don't bring the app to the foreground, they simply give the user the option of launching the application from an alert dialog....
The author's suggestion for Apple to add an alarm-like service is exactly what Android has. Most of the iOS multi-tasking which Steve Job claims is better than everyone else, is also a direct copy of Android's but in a more severe limited manner. But of course everyone thinks Apple invented this.
Indeed, the alarm service does exist, but the API call you'd use (android.app.AlarmManager.setInexactRepeating()) doesn't go nearly as far as he is suggesting about being smart with power/bandwidth/CPU usage. Although it is clever how it will "adjust alarms' phase to cause them to fire simultaneously, avoiding waking the device from sleep more than necessary".
One way to work around it would be to just register for significant location updates, which are bound to occur as the user moves around. Those updates trigger a callback into the app, which could then check the timestamp of the last articles update, and fetch new ones if enough time has elapsed.
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.