4 ms·
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 use
by jws 19y ago
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.
- jsjenkins168 19y agoOr 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.
- parsifal 19y agoI 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).