I'm pretty uncomfortable with this new "push notification" system.
To my mind, a good way of getting 'background' apps to respond to events
is to use some kind of registration system, similar (but more advanced)
than that used by Palm.
The Palm model is that when an event is fired (such as waking the
device, or getting signal, or having an SD card inserted) each
application is woken up (not launched, just woken; no GUI appears) by
the system and informed of the event, and responds to it if it wants to.
Although this has the advantage of not having to have apps running at
all times in the background, and actually works very well, it is pretty
inefficient and doesn't scale to higher numbers of bigger apps.
The addition of a register of event interest would address this. Instead
of polling every app when every event fires, the system could consult
the register, and see which applications have registered interest in
these events. These apps - and only these apps - could be woken and
informed of the event, and could respond to it as they wish.
This would mean you could write a replacement email app, which responded
to the "new email" event. Or an IM app that responded to the "new IM"
event. Or an improved alarm that responded to a "user alert" event, etc
etc.
If you wanted to add new types of event, you could do this by writing
daemons; these would be restricted-footprint background processes whose
sole purpose would be to check for a real-world event (eg checking an
RSS feed) and - if found - publi****ng that event to the system, so that
the apps on the register of event interest could pick it up. To save
battery life etc, the daemons needn't run the whole time; the system
could provide a schedule and the daemons could register to be woken
every minute, every five miuntes, every half hour etc. The system would
then only wake the daemons that are due to be woken, and would wake them
at a specific time in its schedule. This avoids the problem of apps
polling every n minutes but being unsynchronised with each other, so ten
apps polling every five miuntes gives you a poll every thirty-odd
seconds.
This could be kept simple for the end user; a software developer
develops both the GUI app and the daemon, both are installed as part of
one download, and the end user is none-the-wiser. It also allows for
more flexibility for the geek; you love the RSS app from thisDeveloper,
but the RSS daemon from anotherDeveloper is faster and more efficient,
so you just drop in the better daemon.
However.
What Apple has done is place themselves in a Blackberry-style role as
arbitrator of messages (didn't they criticise the need for an
intermediary server a little while back?). Any event and response has to
either go via the cloud or be initiated in the cloud. This restricts you
from responding to events such as "phone powered on" or "alarm
triggered" or whatever; as an example, this makes it impossible to have
an app that updates the start screen (the one that says "slide to
unlock") with a different image; this is possible with Jailbroken apps;
there's something out there that changes this screen to display unread
message counts, weather re****ts and whatever (I'm vague on the details)
meaning you can check these things at a glance, without touching the
screen.
Additionally, this method raises questions as to how apps could be
written that integrate with services by other parties. For example, a
Twitter client could only make use of these type of notifications if it
is an official app from the people who control the Twitter servers, or
if a third-party server were to store your credentials for the service
and check status on your behalf, in order to push that status to your
phone.
Both of these make me uncomfortable.
Part of the appeal of software these days is that you can pick and
choose - your choice of email client works with your choice of mail
provider; but here we're faced with the idea that the Google email
client can only be used with the Google email service (and vice versa),
and the Fastmail client can only be used with the Fastmail service.
Or, of course, you could trust a third party to hold onto your email
credentials and log in for you, behind the scenes. Hmm.
Additionally, Apple have restricted event types to messages (which
triggers the system to display a message on a floating onscreen menu),
badges (badging your app with a value, presumably only numeric) and
sounds. There's no way to force something to *happen* when an event is
received; you can only display text, badge your icon, or play a sound. A
developer cannot say, for instance, that when this event happens the
phone should vibrate, or an image should pop up on screen, or anything
else. Just text, sound or a badge.
It concerns me. It's a step in the right direction, but not a very big
step. I have a feeling that, even with the app store, jailbreaking will
continue and thrive, mainly for this kind of reason.
-zoara-
--
"Ignorance more frequently begets confidence than does knowledge."
- Charles Darwin
|
