iPhone SDK And Restrictions: Some Of The Details Aren’t Great.(techcrunch.com)
techcrunch.com
iPhone SDK And Restrictions: Some Of The Details Aren’t Great.
http://www.techcrunch.com/2008/03/07/iphone-sdk-some-of-the-details-arent-great/
6 comments
The built in applications also terminate you leave them, but no one notices (except for some browser apps where you can tell). The key is just restoring the user to the same place they were when they left. Word processors have been doing this for years. It isn't much code when you are in an MVC model already.
The part about not being able to run anything when you aren't the active program is more limiting. Clearly it is possible, mail gets received even when mail isn't the program, but that is Apple. I can see their point in restricting it, a single lazy coder can degrade the entire user experience and run down the batteries, but there is a class of programs that can't be built in this model.
If I want to write a system monitoring application to keep track of my important machines, that is easy and I can be very slick. But what if I want to be notified when there is an anomalous condition back at the server farm? If my app is running I can hold a connection and monitor it for incoming alerts, but if I'm not the running application I'm completely out of luck. I suppose the server side code could send me an email telling me to run the client, but that is a sad sad way of living.
I expect they will address this in the future. I can think of a couple ways...
1) Add a program to the sandbox that runs at startup but with brutal resource limits. Implement just the bare necessities of listening as efficiently as possible.
2) Make a remote notification manager of some sort. The server can make a remote call, the app runs a call handler briefly and then exits.
3) Do a cron-like operation where it looks at a crontab-like structure in the app's directory. Again, enforce brutal resource limits to keep lazy programmers from ruining the user experience.
All of these also have the problem of how to speak to the user during another program's session. A pop-up box is probably doable, you see those for carrier issues when away from AT&T and they work ok. The ability to play an audio message would be nice, especially if it ducked any existing audio.
The part about not being able to run anything when you aren't the active program is more limiting. Clearly it is possible, mail gets received even when mail isn't the program, but that is Apple. I can see their point in restricting it, a single lazy coder can degrade the entire user experience and run down the batteries, but there is a class of programs that can't be built in this model.
If I want to write a system monitoring application to keep track of my important machines, that is easy and I can be very slick. But what if I want to be notified when there is an anomalous condition back at the server farm? If my app is running I can hold a connection and monitor it for incoming alerts, but if I'm not the running application I'm completely out of luck. I suppose the server side code could send me an email telling me to run the client, but that is a sad sad way of living.
I expect they will address this in the future. I can think of a couple ways...
1) Add a program to the sandbox that runs at startup but with brutal resource limits. Implement just the bare necessities of listening as efficiently as possible.
2) Make a remote notification manager of some sort. The server can make a remote call, the app runs a call handler briefly and then exits.
3) Do a cron-like operation where it looks at a crontab-like structure in the app's directory. Again, enforce brutal resource limits to keep lazy programmers from ruining the user experience.
All of these also have the problem of how to speak to the user during another program's session. A pop-up box is probably doable, you see those for carrier issues when away from AT&T and they work ok. The ability to play an audio message would be nice, especially if it ducked any existing audio.
Or Apple could have simply implemented something similar to the Service process used in Android. A service is scheduled and will run as long as resources (memory, battery, etc) are sufficient to keep the high priority processes (the UI currently visible, etc) running. If resources become low, Android can kill off Services as needed. And there you go, no degradation of user experience.
I am curious as to the real reason why Apple neglected to implement a Service capability. The iPhone is effectively not multi-task capable and that is a monumental shortfall. I can only guess that they had too much to implement and didnt want to take the time (at least yet) to implement the service scheduling properly. Or I give equally likely probability that they simply dont want 3rd created applications to rival what Apple can make. They seem pretty anal about maintaining tight control over their walled garden.
I am curious as to the real reason why Apple neglected to implement a Service capability. The iPhone is effectively not multi-task capable and that is a monumental shortfall. I can only guess that they had too much to implement and didnt want to take the time (at least yet) to implement the service scheduling properly. Or I give equally likely probability that they simply dont want 3rd created applications to rival what Apple can make. They seem pretty anal about maintaining tight control over their walled garden.
I wonder what the reason is. Is Apple being extremely careful, as they're new to the phone market? Are they trying to avoid mistakes they made with the Newton (this is a wild guess because I'm not very familiar with the Newton)?
It may just be system resources -- either they're too limited, or Apple wants to make sure that the currently-running application (especially if the front application is playing a video) runs smoothly
Another reason may be battery life: Maybe if there's more than one app running - especially if one of them is playing music or video, and one is using the internet - the battery drains very quickly.
I can say that on my Sidekick 3, your application can do whatever you want: constantly read off of sockets, use a bunch of CPU -- but before your application can be downloaded by users, it has to be approved by Danger (and probably T-Mobile).
It may just be system resources -- either they're too limited, or Apple wants to make sure that the currently-running application (especially if the front application is playing a video) runs smoothly
Another reason may be battery life: Maybe if there's more than one app running - especially if one of them is playing music or video, and one is using the internet - the battery drains very quickly.
I can say that on my Sidekick 3, your application can do whatever you want: constantly read off of sockets, use a bunch of CPU -- but before your application can be downloaded by users, it has to be approved by Danger (and probably T-Mobile).
While I agree with you that the lack of multitasking for third-party apps is a serious limitation, one of the scenarios you present is easily solved. A program for reading a document can easily keep track of where you leave off. As long as there is persistent storage it is pretty trivial to load back up in the same place.
PalmOS devices had many of the same restrictions on multitasking. It was definitely a detraction but many applications coped well with the limitations.
PalmOS devices had many of the same restrictions on multitasking. It was definitely a detraction but many applications coped well with the limitations.
A few other interesting restrictions, which users will probably appreciate:
Applications MUST comply with the Human Interface Guidelines.
Any image or audio capture must clearly indicate when it is in use.
Anything which transfers information out of the iPhone must provide notice, get consent, and comply with all applicable privacy laws.
You may not use the location services to spy on users without their consent.
Applications MUST comply with the Human Interface Guidelines.
Any image or audio capture must clearly indicate when it is in use.
Anything which transfers information out of the iPhone must provide notice, get consent, and comply with all applicable privacy laws.
You may not use the location services to spy on users without their consent.
Since Apple's trying to sell a zillion phones, they'd rather hear complaints like "I can't run multiple apps at once" than "How come my iPhone keeps getting slower and slower every time I open a program."
Remember the iPhone is technical enough for a geek, simple and pretty enough for your grandma, teenagers, MBAs, etc
Remember the iPhone is technical enough for a geek, simple and pretty enough for your grandma, teenagers, MBAs, etc
True enough, but I'm sure we'll still see interesting applications that don't need to break these restrictions.
I don't see these restrictions as a huge problem. Having one app running allows the app to use the full resources.
The key will be the handoffs between apps, so that you can start back where you left off and things like that.
The key will be the handoffs between apps, so that you can start back where you left off and things like that.
I lack a mac and so, I can't use the iPhone SDK.
And not being able to run anything in the background, means that my application wouldn't work well at all on the iPhone.
I guess it's Android for me.
And not being able to run anything in the background, means that my application wouldn't work well at all on the iPhone.
I guess it's Android for me.
As a developer, for me this is a Dead End. Being able to work on something, go work on something else, and come back to the first task, was a key revolution in computing -- compare DOS to Windows.
What use is instant messaging if you have to sign off to use the browser?
What if I'm reading a document and then have to take a phone call? I'll have to re-open the document and find where I was!
I have a Sidekick 3, and one of its biggest benefits is that, not only can I do IMs while I browse and take notes, I can take a phone call, and my IM session is kept alive on a server, and I can still send and receive messages, and the state is all coalesced once I hang up the phone. This is mobile computing.
I agree with jgrahamc: I'm sure we'll see interesting new applications that adapt to this environment.. I'm just not currently going to be one of them.