#comments

What's an iphone?

Sure there are problems... but it's a problem that needs to be solved and this push issue doesn't do it. Maybe even cpu accounting with built in suggestions as to what might be the problems could help shift the blame from Apple. Ah well, hopefully as you suggest, battery and cpu improvements will find a hardware solution to the problem. Times gonna tell on this one!

As for the G1, interestingly enough, at the end of that post the author still prefers the G1 so background apps can not have killed the battery to an unusable level. I guess we'll see.

Yeah - I used to think that brick would be the way of things. Of course I wasn't thinking about making it razor thin and using the surface as a multi-touch UI, so that shows how much I know!

Comments are not enabled by accident. Someone said they'd had to put the page through 'readability' http://lab.arc90.com/experiments/readability/ in order to read it, and out of shame I changed the theme, but forgot to re-add the disqus. Thanks for pointing that out!

Apparently, the G1 does not do it: http://awurl.com/rQN0Tzq8U#first_awesome_highlight

As far as these ideas go - I think the scrutiny aspect would be hard to control - for now, Apple aren't soak testing apps in any particular way, and the problems could easily emerge later in the usage.

Secondly, there would be no easy way to know for the end user to know which App was the culprit, so either the switch would just end up being OFF, or the battery life would unpredictable.

In both cases, everyone would regard Apple's solution as a failure, as opposed to blaming the buggy app - which is what they would probably prefer. Also, "No Task Manager on the Phone" is #1 on the 10 commandments of Steve IIRC.

I think the time slicing idea has more merit. Apps could indeed register for a callback and get woken up. However the question is - what do they do then? Poll something on the Net? If they are polling then they have to do it frequently and fire up the radio etc. every time otherwise they can't deliver a timely notification to the user - something which push notifications optimize across all the apps. If they aren't polling something, then what are they doing? Background grinding of some sort? If so, your battery is dead again, and that work should be something done in the cloud.

With a timed solution, there could be a safeguard whereby only a fixed time is allowed before the OS kills you, to prevent runaway mandelbrots ( :-) ) - but that would be fiddly because again if you are polling, the CPU timeout will interfere with network latency etc. Also, what if the user starts the UI while the background component is running?

Basically this route leads to the madness associated with concurrency in general, which is usually most easily solved by queues - which is essentially what they've provided. Remember many of the programmers will not be careful - they will be rushing to make money out of farts.

I think my conclusion is that polling is bad, and grinding is also bad and should be done on a big fat machine in the cloud.

The part of the equation that I don't see solved yet, is how you upload data to the cloud without keeping the user waiting. Apple uses mail for this. Obviously, apps can now use mail attachments, but the user is still in the loop. It would be nice to see a queue going to the cloud in the other direction, although that's a trickier issue because of the variability of the data size.

Perhaps they could provide a global mechanism to queue up HTTP posts, for data going the other way for stuff like uploading photos etc.

And WRT the IM client security issue - yeah - for sure that's an issue. If the IM network wanted, they could provide OAUTH tokens, or whatever, but the lack of backgrounding doesn't change this - you have to trust the app developer not to phone home with your credentials anyway.

I look forward to seeing how Palm solve it, if they do.

Just realized, there aren't comments enabled on your blog... what up with that?? Heh, but it's a good point you raise. You're probably right that the hardware interaction bits could prove to be the most significant of the lot. It takes that whole nike+ business to the next level, well a few levels later. On a slight tangent, I wonder how the bluetooth control deals with the whole non-tethering business.

But definitely, this will start a whole new ecosystem of iPhone based peripherals, the likes of which we haven't seen yet. It'll help sell iPhones for sure! Some years ago I envisioned a device that would be a little brick and sit in folks bags that would provide horsepower, connectivity and storage - it would be surrounded by a bunch of different skins for different features that would use that brick as the brains - basically dumb terminals of differing form factors - a phone skin, an e-reader, etc... they would all be simple devices because they'd basically be I/O for the brick. It seems that the iPhone could become that thing. I'm looking forward to it!

Robin, just checked out your post - it makes an excellent point. I'll respond there about it, though. :)

As for here and background apps, I think there are probably ways to make background apps reasonable to battery life. Although, the G1 does it, no?

My initial ideas on backgrounding would be one where apps are explicitly backgroundable or not - this has two effects, one Apple can put greater scrutiny on them for approval. Also, backgrounding can be enabled or disabled in the iPhones pref panel. Second, a different mode could be provided so that instead of simply running all the time it can awake run and then go back to sleep periodically. Similar to how mail works. This would enable a variety of other apps without incurring a full background app penalty.

I don't know. Apple are magicians. How do you think they keep coming out with all this gear that I need?? :) At any rate, battery life is definitely a concern, but I feel like Apple's push is going to be out of reach for many small app developers. Not only for the server side resources they'll require but because of security - so now if I want an IM client I have to trust the app developer with my login and password so they can go and be logged in for me.

Just saying. :)

Well for once I wrote a bit (breathlessly) about an apple event before you did. I feel my previous long retorts to your postings give me the moral right to post my link here without it being blatant self promotion:

http://notes.sublime.org/post/87351443/iphone-3-0-apps-connecting-to-hardware-is-the-trump

Having said that - in response to your actual points:

Firstly let me wholeheartedly agree with your disappointment about the lack of a trial system. That's the one genuine disappointment I felt. Not sure what the ideal mechanism would look like, but it's definitely a weak point in the current experience.

As to backgrounding though - I still haven't seen anyone yet explain how to genuinely enable background apps without seeing everyone's battery go dead immediately.

People rush out buggy apps all the time, and with the sheer number that are being developed and installed, a whole bunch of them would surely not even bother to code for efficiency, use the CPU for something trivial (probably to irritate people with random background fart sounds), and then vast numbers of batteries would be dying all the time, calls missed, revenue lost, people sad etc. etc.

This already happens with symbian even with apps carefully developed by reputable companies because of bugs etc. We don't hear about it, because nobody cares. Also sadly, in those 80 countries, not everyone has unlimited data. A background app could therefore run up a bill for you without you knowing or as a result of a bug.

Now I know all of this this is Apple's job to solve, but they aren't actually magicians, and I haven't heard anyone else yet present a credible alternative. Palm claim that the Pre will do it, but then Microsoft claimed that ActiveX security wouldn't be a problem, and we all know how that played out.

Apple really only need to get us from here to the middle of next year, and what they have done will do that. CPU power will increase, battery life will lengthen, the cloud will get easier and cheaper to use and offline regions will continue to shrink, so these things are on their side.

My predictions (which are worth what you paid me for them) tell me to expect new hardware this year. The 3G was really just a 'bump' in Apple-land, and so we're at the 2 year point and ready for a real upgrade. Also - if you notice the 'inflexion points' on their sales graph - they point out the increased acceptance when the 3G came out, but they don't draw attention to the other inflexion point that shows slowing sales growth of the 3G - on top of that there is the usual phone replacement cycle of 2 years, and original contracts ending etc, plus their predictable machine like cycles. Of course, I am just speculating from the outside.

But if they are going to release new hardware this year, one thing you can bet is that they have tried not to leak information about it in this presentation or the 3.0 preview, so perhaps there may be some surprises in store.

Apple tries to avoid doing anything where they can't take the lead out of the door. Given how much investment they have made in video so far on the desktop, I would imagine they won't put it on the phone until it can dominate the category. We know that steve has been scrutinizing this area down to the chip level. My guess would be that at the very least they would want hardware encoding, and to pair it with higher flash capacities on the device and a better mic, rather than do something 'phone quality'. We also have the 2 camera videophone rumors - which although I'm not feeling them strongly would make a lot of sense - especially now that they have all of the infrastructure to do a seamless iChat. Working against this would be the possibility that the hardware simply isn't ready yet.

We haven't had "One More Thing" for a while now, have we?