And now, let's listen to a developer

[Small White Car]

I don't write software. I get the feeling most of us around here don't. And yet we still all act like we know what we're talking about.

Sometime it's nice to just step back and listen to the real experts.

http://furbo.org/2008/03/16/brain-surgeons

This explains some thoughts that I'd been feeling were true, but couldn't really express since I don't have experience. It's nice to read ideas based on real-world experience and I thought you'd all enjoy it too.

 

[emotion]

Interesting article. Thanks for posting that.

 

[Archie-]

Wow! Thank God Steve protected us from having to recharge the phone during the day, and also from the annoying twitter epidemic. God knows I would prefer having my device fully charged and useless vs useful and doing what i want it to do!

I heard Apple is making a car. It will look like a Lamborghini Murcielago, but will be limited to 20 mph to conserve fuel, unless you go downhill, when it will go pretty fast. Also you wont be able to change the radio, as this would void the warranty, and dont even think of driving it over the border.

It will be perfect for showboating, but pretty useless for anything else. But at least the tank will always be full.

 

[emotion]

You've clearly not read the article.

Or owned an iPhone.

 

[Archie-]

You've clearly not read the article.

Or owned an iPhone.

Let me summarize the article, as SMC declined to.

Multi-tasking is bad, as background network-accessing processes cause massive battery drain, and this is a difficult process to solve, so Steve is perfectly right to preserve the long battery life of the iPhone and ban 3rd party apps from multi-tasking.

Strangely this developer does state that the iPhone as a client device can only do interesting stuff by accessing the network, yet he still rails against it.

I guess he prefers a boring fully charged iPhone vs an Iphone the users find useful and can chose for themselves whether they want to sacrifice battery life for utility, such as IM.

 

[emotion]

Let me summarize the article

No need. I'm perfectly capable of reading the short article myself.

If you eventually get an iPhone then you'll see. The controlled Apple way is one way to provide a consistent user experience (which is everything to Apple). The other approach, say Android, is completely open. It's up for debate which one is best. Both have their merits.

At the moment there's nothing like the iPhone out there. When Android arrives it may be that will change. Until then...

 

[robhedin]

Strangely this developer does state that the iPhone as a client device can only do interesting stuff by accessing the network, yet he still rails against it.

Actually, the point that he makes is that developers currently have no idea how to write for limited, mobile devices with limited resources, but are used to the (effectively) infinite resources available when programming for the desktop.

As far as network access is concerned, he specifically mentions that network access is good, but that arbitrarily using the network is probably contraindicated, and one should instead piggy-back onto the radios when your application gets the notification that the radios are on, do what you need, and get off (i.e. batch mode) in order to conserve battery life.

All in all, good points to ponder. And that's speaking as one who is writing applications for the iPhone.

rob.

 

[kdarling]

I am an engineer and programmer. Thirty years experience. The last fifteen have been with touchscreen based handhelds in field operations (think electric or phone company technicians, working outside all day. Or UPS/FedEx delivery.)

We use DOS/XP/WM/CE and Java/J2ME based devices. Some are ruggedized and customized; some are off the shelf (Blackberries and WM phones). Many of the handhelds are similar in hardware and have been for years. ARM cpu, large color touchscreen, radios, etc. Just different OS's. (Some have choices, even.)

He's right that you have to think differently, especially in respect to loss of communications (not so much nowadays) and cpu usage. But I don't think background processes need to be limited as much as he says.

It sounds to me like the iPhone OS still needs some fine-tuning. It's always been clear that the iPhone was rushed out the door, perhaps to meet some ATT contract clause. More importantly, Apple originally didn't plan on allowing third party development, and they hoped to do internal changes at their leisure.

Now they're rushed again, and the easiest way of handling potential problems is to totally avoid them by not allowing background tasks. Which is okay, as long as feeble excuses aren't made. Just say, we're not ready for it yet. That's all.

 

[emotion]

It sounds to me like the iPhone OS still needs some fine-tuning. It's always been clear that the iPhone was rushed out the door, perhaps to meet some ATT contract clause. More importantly, Apple originally didn't plan on allowing third party development, and they hoped to do internal changes at their leisure.

Now they're rushed again, and the easiest way of handling potential problems is to totally avoid them by not allowing background tasks. Which is okay, as long as feeble excuses aren't made. Just say, we're not ready for it yet. That's all.

I completely agree. The way Apple are handling some of this is alienating some of their customers. It might be a strategy that wins overall but it certainly puts me off a little (only a little though).

 

[robhedin]

I am an engineer and programmer. Thirty years experience. The last fifteen have been with touchscreen based handhelds in field operations (think electric or phone company technicians, working outside all day. Or UPS/FedEx delivery.)

We use DOS/XP/WM/CE and Java/J2ME based devices. Some are ruggedized and customized; some are off the shelf (Blackberries and WM phones). Many of the handhelds are similar in hardware and have been for years. ARM cpu, large color touchscreen, radios, etc. Just different OS's. (Some have choices, even.)

He's right that you have to think differently, especially in respect to loss of communications (not so much nowadays) and cpu usage. But I don't think background processes need to be limited as much as he says.

Sounds like we have a similar background, excepting I was doing embedded systems work in the 80's and ended up shifting to java on the server side over the past 10 years or so...

While I agree with pretty much everything you said, I also suspect there's some concern over the fact that with 100's of thousands of (potential)neophytes playing with their new toys, Apple is really concerned with making sure that newbie programmers don't end up giving the platform a black eye due to a lack of understanding of the issues involved.

rob.

 

[kdarling]

While I agree with pretty much everything you said, I also suspect there's some concern over the fact that with 100's of thousands of (potential)neophytes playing with their new toys, Apple is really concerned with making sure that newbie programmers don't end up giving the platform a black eye due to a lack of understanding of the issues involved.

I think you're completely correct. And like I said, it's okay at first.

But it might backfire on them in this way: apps will either have to save their state, or go back on the web to retrieve data again when they restart.

The former could be complex (e.g. graphing of a complicated equation). The latter wastes power to run the radios. (Actually both waste power.)

Even now, if I get interrupted and later go back to YouTube (aka restart it), I believe it goes back out to get the info again. And people wonder where their battery goes. The more you switch between some apps, the more battery you use up, just to get back to where you were.

 

[rayward]

If you eventually get an iPhone then you'll see. The controlled Apple way is one way to provide a consistent user experience (which is everything to Apple). The other approach, say Android, is completely open. It's up for debate which one is best. Both have their merits.

Controlled is Apple's approach, open is Microsoft's. I know which one I prefer.

 

[72930]

Controlled is Apple's approach, open is Microsoft's. I know which one I prefer.

BS. Open is Google's approach, MS's is a badly implemented half way point.

 

[Archie-]

BS. Open is Google's approach, MS's is a badly implemented half way point.

Actually, when it comes to apps, Android apps will run in a sandbox, whereas WM apps run natively with full access. From the developer POV, MS's WM is more open.

 

[dejo]

God knows I would prefer having my device fully charged and useless vs useful and doing what i want it to do!

When the battery is dead on your device, it also becomes useless.

 

[Aydo]

I don't mean to steal your thread, but roughlydrafted mag also wrote in depth about this issue as well. Here's a link for anyone interested:

http://www.roughlydrafted.com/2008/03/13/iphone-20-sdk-the-no-multitasking-myth/

 

[Small White Car]

I guess he prefers a boring fully charged iPhone vs an Iphone the users find useful and can chose for themselves whether they want to sacrifice battery life for utility, such as IM.

AOL's iPhone IM app works without runnnig in the background.

So even though the app you want exists in the current "no-background-apps" world, you STILL want a version that will drain the battery?

Why the obsession with draining the battery for no reason whatsoever?

 

[Archie-]

AOL's iPhone IM app works without runnnig in the background.

So even though the app you want exists in the current "no-background-apps" world, you STILL want a version that will drain the battery?

Why the obsession with draining the battery for no reason whatsoever?

How do you receive IM's when the app is not running in the background and you are doing something else (e.g. browsing the web)? Fairy dust magic?

Or are you meant to sit there and stare at the screen when your friend says BRB?

 

[JPyre]

More importantly, Apple originally didn't plan on allowing third party development, and they hoped to do internal changes at their leisure.

Now they're rushed again, and the easiest way of handling potential problems is to totally avoid them by not allowing background tasks.

You were kinda making a little sense until you said this.

1) Do you forget that Yahoo, Google, and Youtube all have embedded features on the iPhone from Day 1.

2) They always intended to have 3rd party apps for download from iTunes, they've done it for every other iPod out, why wouldn't they have planned for the iPhone. That'd be like saying "We have the best internet distribution system out, but lets not use it to make money on our new products"

3) I (and the majority of others) don't want any backround task running except e-mail, PERIOD. If I want to chat on AIM I'll log in and then log out, If I want to check anything else out I'll take the 2 seconds to log in as well. I don't see how this is an issue for anyone or any app, It's not hard to press login every once in awhile.

I don't want backround apps taking my battery, I already intentionlly log out Apollo everytime, and I don't want 3G either, my city (and 90% of the US) doesn't have it anyway.

 

[Small White Car]

How do you receive IM's when the app is not running in the background and you are doing something else (e.g. browsing the web)? Fairy dust magic?

You switch to the app and it gathers any IMs you missed while you weren't looking at it.

So it does everything EXCEPT "ding" when you get a new message. That's it. The only difference between using iPhone AIM and desktop AIM.

No, it's not perfect, but neither is a phone that dies after 4 hours WITHOUT making any phone calls or using the iPod at all. That's hardly a solution.

 

[kdarling]

I don't want backround apps taking my battery, I already intentionlly log out Apollo everytime, and I don't want 3G either, my city (and 90% of the US) doesn't have it anyway.

I'd rather have more advanced technology, but each to their own.

90% of the US by area might not have 3G, but large population areas do. Over 100 million live in just 34,000 square miles.

Why not buy a ten year old dumb phone without lots of RAM, WiFi, big screen, EDGE, etc? All those things use battery. Better yet, get one with a replaceable battery.

Background apps don't have to take up much power when communicating, if the OS is done right. When not comm'ing, of course they take up no power.

 

[JPyre]

I'd rather have more advanced technology, but each to their own.

The 3G thing was a little bit of sarcasm mixed with reality, I'd like to have 3G as well, IF my city had it, and IF it isn't a separate chip on the board draining power, whci I'm sure the next ver will be.

90% of the US by area might not have 3G, but large population areas do. Over 100 million live in just 34,000 square miles.

Um, I wasn't referring to 90% land, I was referring to 90% of cities dont. Yes, cities, not even talking about towns.

Why not buy a ten year old dumb phone without lots of RAM, WiFi, big screen, EDGE, etc? All those things use battery. Better yet, get one with a replaceable battery.

Umm... seeing as how i came from using a long line of WM PPCs that dont last a day... I'll keep my iPhone thank you very much, it lasts 2 days if I don't leave IM running, and I've been making pretty good progress in Final Fantasy V and Zelda, I don't need mobile chat on all the time, that what phone calls and text messaging are for.

Background apps don't have to take up much power when communicating, if the OS is done right. When not comm'ing, of course they take up no power.

What does the OS have to do with an IM app running all day long until you shut it off? It's not like Apollo only checks every 1 min, it uses the radio constantly. Nothing in the OS will help an IM app drain less, except turning it off, or periodicly checking for new msgs. What AOL and/or Apple and/or 3rd parties should do is create a push IM app, that will solve the problem.

 

[Archie-]

You switch to the app and it gathers any IMs you missed while you weren't looking at it.

So it does everything EXCEPT "ding" when you get a new message. That's it. The only difference between using iPhone AIM and desktop AIM.

No, it's not perfect, but neither is a phone that dies after 4 hours WITHOUT making any phone calls or using the iPod at all. That's hardly a solution.

Thats positively primitive. Imagine if your phone worked like that. You might as well be using e-mail. SMS would be more reliable at reaching the other person.

And you are endorsing this? You are willing to put up with a lot, arnt you.

 

[zetsurin]

You switch to the app and it gathers any IMs you missed while you weren't looking at it.

So it does everything EXCEPT "ding" when you get a new message. That's it. The only difference between using iPhone AIM and desktop AIM.

No, it's not perfect, but neither is a phone that dies after 4 hours WITHOUT making any phone calls or using the iPod at all. That's hardly a solution.

That's backward and well behind functionality provided by competing platforms. If we are going to start polling for things, why don't we start polling for SMS and even phone calls. Heck, if we go and use 2 tin cans and a piece of string that will sort out all the battery woes. There must be a way to programatically find out when the mail service is about to poll for new mail, and do the polling then.

Basically arguing *for* Apple-imposed limitations is where all the iProduct and zealotry stereotypes stem from. There's no reason that Apple can't stipulate that apps not run in the background by default yet have an option to do so if relevant. The app should show a warning to say that this can have an effect on battery life and the choice can be made at the owner's discretion. If an app doesn't obey this rule, THEN apple should deny it. I personally don't need you nor Steve Jobs deciding for me how long my phone's battery life lasts.

 

[emotion]

I personally don't need you nor Steve Jobs deciding for me how long my phone's battery life lasts.

Kinda difficult to avoid that really given Steve runs Apple and you don't.

As explained above there are a few reasons why Apple might impose limitations at this stage. It's not an elegant solution to have battery warnings popping up all the time. Very un-Apple.

It's pointless moaning on at this stage. Wait until the software that's being developed lands. Then, by all means, complain (or if you are a dev, then think of a clever way around it).