When Apple first announced the External Accessory Framework with IOS 3 there was a great deal of excitement, it was thought that the new framework would open the iphone up to a host of new third party devices which could be attached via the dock connector, camera adaptor , USB and even bluetooth.
But along with the new Framework came new rules and limitations that tempered those early expectations.
For one the new framework required enrollment in the Made for Ipod program or MFI (which can be interpreted nowadays as Made for Iphone or whatever "I" device you care to postfix the "I" with. MFI membership is pretty much limited to OEMs that have a clear vision of a real product and can prove that to Apple.
USB and Bluetooth framworks were restriced to only MFI members.
Also the new framework emphasized one of the biggest complaints with IOS , the lack of mult-tasking.
prior to IOS version 4 the lifecycle of an application was not very complicated.
.The app is started by calling application:didFinishLaunchingWithOptions which starts the event loop, When the user quits the application, the whole app is closed and the method applicationWillTerminate is called. The next time the user opens the application, the method application:didFinishLaunchingWithOptions: is called again.
This Presented a Problem for Apple which they have been incrementally addressing since IOS 4.0.
Apple was not about to allow the wholesale multitasking of the kind available on Android. Android multitasking can be a headache for some applications. i.e. streaming IPTV which may have need to maintain large buffers for audio and video, On iphone the applications are free to grab all the memory they can but on Android, the OS provides only for limited amount of memory and the app "lives" in fear of the OS killing it at any time for higher priority tasks.
But No Multi-tasking is equally a problem.
Lets take as a scenario a External Heart Monitoring accessory such as provided by Wahoo Fitness and a Iphone with 2 applications .
HealthMonitor which is attached to the accessory via ANT protocol.
Pandora Radio, for those tunes you just must listen to while you exercise.
Prior to OS 4 whenever the user switched between Pandora Radio and HealthMonitor the former application had to completely quit and the application in the foreground had to completely reinitialize itself. Developers were required to implement there own protocols for fast restarts by caching data locally. The connection to the monitor would be servered and have to be reopended when the monitor was forground again. Not a happy lifecycle for a application that needed realtime sensor data.
Once more Bluetooth allows for multiple socket connections and multiple devices but the lack of multitaking meant that there could be a "single connection" to a "single accessory" only.
With IOS 4 Apple attempted to address these limitiations in a number of ways.
First "fast task switching" gave the os the ability to save enough of the state of the application to quickly restore it upon resumption of the application.
iOS4 introduces a more complicated lifecyle, when the user quits the app, it enters the background and method application:didEnterBackground is called. The application remains in the background for some determinied time period depending on what the application was doing before it entered background usually not exceeding 10 minutes, this allows time for the application to complete whatever task it was doing before entering a suspended state . If the application is still in the middle of some long task it may "request" additional time from the os in small increments to complete whatever task it was doing. Then the application enters the suspended state.
An IOS application can be in one of 5 states
- Not running - the app has been terminated or has not been launched.
- Inactive - the app is in the foreground but not receiving events (for example, the user has locked the device with the app active)
- Active - the normal state of "in use" for an app
- Background - the app is no longer on-screen but is still executing code
- Suspended - the app is still resident in memory but is not executing code
Apple Also defined a set of elite tasks type which are allowed to run in the background.
|
- Background audio - allows apllications to play audio continuously.
- Voice over IP - Users can now receive VoIP calls and have conversations while using another app. - Background location - Navigation apps continue to guide users who are using other apps - Push notifications - Receive alerts from your remote servers even when your app isn't running. - Local notifications - Applications can alert users of scheduled events and alarms in the background. - Task finishing - If your app is in mid-task, the app can now keep running to finish the task. - Fast app switching - Quick restore between swapping applications |
Recall we said Apple was making incremental tweaks to multitasking. IOS 5 added 2 additons to this list.
- Newsstand apps that are downloading new content.
- Apps that receive continuous updates from an external accessory in the Background.
A New notification was added to the acessory protocol that allowed an accessory to launch an application when it had updated data.
Considering now are heart Monitor example.
The user launches HealthMonitor which opens an NSStream to the heart monitoring accessory and begins a brisk Juant. While running she switches to the Pandora Application which causes the HealthMonitor app to enter into a background state. Because HealthMonitor has indicated in its plist that it is one of the Apple's blessed background types with the key "external-accessory" the application continues to collect the data stream from the accessory. The user is free to switch back and forth between the apps , forcing each in turn to swap states.
To Make it interesting lets add a third application, HealthShare, which logs the users heart rate and makes it available to facebook. HealthShare also accesses the accessory. The heart monitor accessory can only handle a single serial connection at a time. So when the HealthShare accessory is started it forces HealthMonitor into the background, HealthMonitor is still connected to the accessory but get an NSStreamEcounteredEnd event because HealthShare now has the connection to the stream. This handing off of streams can be repeated as needed.
The new lifecycle is an improvement over the previous but still has flaws, for instance the user must physically bring each application back to the foreground state. Apple did provide Accessories with the abililty to send a launch notification, but the programming for most accessories is embedded into firmware, and in most cases needs to physically flashed with new programming. For some OEMs this can be a simple process of providing the user with an over the air update but for others it can involve a tedius trip by the customer to a dealer or actually having to wait for a new model, which can be several months or even years down the road.
Having to manually switch applications can be especially troublesome for In-Car infotainment or management systems because of the implications of having to physically handle the device causing a driver distraction. This would be a problem with many a state legislature.
In the next segment we will discuss a way of switching between applications without the user having to intervene.
Comments