во все стороны
12:11 | 16-06-2010 | Apple, Software | 1 Comment
хорошая статья о многозадачности в iOS:
Multitasking in iOS4 is not a magical sparkle pony. It’s a magically sparkly unicorn that is close enough to a pony to reasonably allow Apple to call it a pony for the vast majority of users, when it still has a horn on it’s head.
многие, то есть, ожидают все и сразу, но дела обстоят совсем не так, как хотелось бы:
Inside, Apple’s SVP of iPhone Software, Scott Forstall explained they looked at existing apps and distilled 7 services those apps needed to run in background, then provided them via API. According to Apple, these are:
- Background audio – Allows your app to play audio continuously. So customers can listen to your app while they surf the web, play games, and more.
- Voice over iP – Your VoIP apps can now be even better. Users can now receive VoIP calls and have conversations while using another app. Your users can even receive calls when their phones are locked in their pocket.
- Background location – Navigation apps can now continue to guide users who are listening to their iPods, or using other apps. iPhone OS 4 also provides a new and battery efficient way to monitor location when users move between cell towers. This is a great way for your social networking apps to keep track of users and their friends’ locations.
- Push notifications – Receive alerts from your remote servers even when your app isn’t running.
- Local notifications – Your app can now alert users of scheduled events and alarms in the background, no servers required.
- Task finishing – If your app is in mid-task when your customer leaves it, the app can now keep running to finish the task.
- Fast app switching – All developers should take advantage of this. This will allow users to leave your app and come right back to where they were when they left – no more having to reload the app.
есть, однако, и варианты:
The addition of one more multitasking service would solve this issue for a lot of application types: a periodic network request. Here’s how I would do it:
- The application gives the system an NSURLRequest and an ideal refresh interval, such as every 30 minutes, every few hours, or every day.
- iOS executes that request, whenever it deems that it should, and saves the response to a local file.
- Next time the application launches, iOS hands it an NSData of the most recent response.
Executing the request “whenever it deems that it should” is important. iOS can decide, for instance:
- Not to update when the battery is low, connectivity is poor, other requests are running, free memory is low, CPU usage is high, or the user is predicted to exceed their monthly data limit.
- Not to update as frequently as the app requests, or to increase the interval over time, or to dynamically adjust the interval based on how often it receives a 304 (Not Modified) response.
- Not to update at all if the requesting app has not been launched in a long time.
или немного шире:
I had a similar idea, utilizing a new type of push notification. This push notification would do nothing user-facing, but push relevant content (such as Instapaper articles) to the device. The OS stores this, and then – once the app is reawakened – informs the app of the new content and let it deal with it. Even a socket link API would do the trick for IMs, so the app doesn’t need to reconnect to it’s streaming server. The socket would be able to be left open but idle, reducing the wait time for the app to interact once the user returns.
[…] слову о разработке для мобильных платформ — вот различия […]