
IPhone multitasking and background updating - barredo
http://www.marco.org/684391075
======
martythemaniak
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.

~~~
Terretta
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.

~~~
martythemaniak
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.

------
wmf
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. :-)

~~~
orangecat
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.

------
buster
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..

~~~
barredo
There's real multitasking for Native apps (since 1.0) and a limited
multitasking for 3rd party apps (since 4.0)

Edit: Downvoted? Am I wrong? Just curious

~~~
illumin8
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?)

------
ugh
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.)

------
houseabsolute
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.

------
enjo
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?

~~~
poutine
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.

~~~
enjo
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....

Or am I wrong?

~~~
poutine
Yes, but for an alarm clock it'd work. You can set custom sounds, etc. You can
also schedule up 64 of them and have them recur.

------
Arron
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.

~~~
adrianmonk
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".

------
hiroprot
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.

------
barredo
What about Push? Can't anything be done with it? Like Mail.app

~~~
glhaynes
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.

~~~
stcredzero
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.

~~~
glhaynes
Yeah. Mr. Arment's proposed solution sounds pretty good to me, and seems to
fit the "spirit" of the existing multitasking APIs.

