This post is not about how-to perform multi-tasking for Android and iOS, it's about my thinking related to how I handle threading issues in Android and iOS.
I've written multi-threading code for decades (in C/C++ and Java) before I got into mobile development. Threading was one of those issues that used to be a black art. You needed to handle and understand all of the semaphores, mutating and memory issues to provide a robust threaded application. It's a lot easier now in both Android and iOS. Clear examples and simplified code make threading quick and easy, but there is still complexity underlying the concept of threading for the UI.
My biggest insight when switching to mobile threads is the pattern of placing the threading inside of the activity or controller. This is a big plus for simplicity and ease of use for development. The thread is right there where it's needed and the thread has access to the Activities (or Controller's) data members for updating the UI when it's safe. Cool, very cool. Nice, neat and local to it's usage. Threading for the masses.
For most of my threading issues this is what I use. But this local pattern is not suited for all needs and is where the patterns for Android and iOS diverge.
One of my biggest issues with Android is the destruction of the Activity on rotation. Not a big deal when doing Android phone development where the user is primary expected to to use a single orientation, but tablets are more rotatable. The screen ratio is closer to not have a single preference and different uses prefer different orientation (books -vs- movies, etc.). With such a large screen to present on, it's expected that the tablets will be rotated and the app should support it and this has an impact on threading in Android.
The pattern of having the thread local in the Activity is great except when the device is rotated, the app supports it and a local Activity thread is running. The thread will still be running, but the local UI data members that need to be updated will be for the pre-rotated Activities. In short, it will not work in all cases, it's one of those timing things, sometimes it will work, sometimes it won't. The local pattern will fail as it's too tightly coupled to that instance of the Activity. For this case the thread needs to be changed to couple loosely to the Activity when updates need to occur. I'm not going to cover solutions for this (they are not very hard, just different, i.e., observer pattern) but to express my thoughts of the Android threading for Tablet applications that should be rotatable.
I view the ability of tablet apps to support rotation as important as it impacts the tablet's usage. Don't force the user to rotate the tablet when switching from reading a book to going to the App marketplace.
On iOS the threading issues for local threads inside of a Controller as much the same as Android except when the device is rotated there is no destruction of class instances and the same local thread pattern will always work. The local threading block still has access to the controllers data members for updates on completion on the Event thread. In iOS GCD (Grand Central Dispatch) the level of control other the threads is also much greater. The queue's that can be used used, the processing order (serial or parallel) allows control that does not exist (easily) in Android. I'll be using mostly the local pattern for my threads in iOS. This is switch from my non-mobile apps where the threaded tasks are contained in their own class and packages.
My bottom line is that I've switched the location and implementation of my threads to use the local pattern of placing the threads inside of the Activity and Controllers. It's just too nice of a pattern to miss out on. My exceptions are for 1) Android apps that are rotatable and 2) longer running threads that impact multiple Activities or Controllers (I use MVC notifications for those).
It's been enjoyable working with threads for mobile apps and understanding the local pattern. It makes my life easier.
I've written multi-threading code for decades (in C/C++ and Java) before I got into mobile development. Threading was one of those issues that used to be a black art. You needed to handle and understand all of the semaphores, mutating and memory issues to provide a robust threaded application. It's a lot easier now in both Android and iOS. Clear examples and simplified code make threading quick and easy, but there is still complexity underlying the concept of threading for the UI.
My biggest insight when switching to mobile threads is the pattern of placing the threading inside of the activity or controller. This is a big plus for simplicity and ease of use for development. The thread is right there where it's needed and the thread has access to the Activities (or Controller's) data members for updating the UI when it's safe. Cool, very cool. Nice, neat and local to it's usage. Threading for the masses.For most of my threading issues this is what I use. But this local pattern is not suited for all needs and is where the patterns for Android and iOS diverge.
One of my biggest issues with Android is the destruction of the Activity on rotation. Not a big deal when doing Android phone development where the user is primary expected to to use a single orientation, but tablets are more rotatable. The screen ratio is closer to not have a single preference and different uses prefer different orientation (books -vs- movies, etc.). With such a large screen to present on, it's expected that the tablets will be rotated and the app should support it and this has an impact on threading in Android.
The pattern of having the thread local in the Activity is great except when the device is rotated, the app supports it and a local Activity thread is running. The thread will still be running, but the local UI data members that need to be updated will be for the pre-rotated Activities. In short, it will not work in all cases, it's one of those timing things, sometimes it will work, sometimes it won't. The local pattern will fail as it's too tightly coupled to that instance of the Activity. For this case the thread needs to be changed to couple loosely to the Activity when updates need to occur. I'm not going to cover solutions for this (they are not very hard, just different, i.e., observer pattern) but to express my thoughts of the Android threading for Tablet applications that should be rotatable.
I view the ability of tablet apps to support rotation as important as it impacts the tablet's usage. Don't force the user to rotate the tablet when switching from reading a book to going to the App marketplace.
On iOS the threading issues for local threads inside of a Controller as much the same as Android except when the device is rotated there is no destruction of class instances and the same local thread pattern will always work. The local threading block still has access to the controllers data members for updates on completion on the Event thread. In iOS GCD (Grand Central Dispatch) the level of control other the threads is also much greater. The queue's that can be used used, the processing order (serial or parallel) allows control that does not exist (easily) in Android. I'll be using mostly the local pattern for my threads in iOS. This is switch from my non-mobile apps where the threaded tasks are contained in their own class and packages.
My bottom line is that I've switched the location and implementation of my threads to use the local pattern of placing the threads inside of the Activity and Controllers. It's just too nice of a pattern to miss out on. My exceptions are for 1) Android apps that are rotatable and 2) longer running threads that impact multiple Activities or Controllers (I use MVC notifications for those).
It's been enjoyable working with threads for mobile apps and understanding the local pattern. It makes my life easier.
Comments
Post a Comment