3 ms·
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 (memor
by jsjenkins168 19y ago
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.
- 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).