Been wanting to post about my perspectives on Android development. This is not a Android -vs- iOS blog but just what I see as my perspective of Android development.
Android feels easy. Java feels like a well broken in shoe that slip on in the morning and can wear all day, so Android development feels easy for me. I understand the attraction of the Intents and Activities for the providing of multiple filters for handling common features (select you email, photo editors, etc), but I view this as more of a benefit for geeks rather than most consumers. What kind of support is there for uses that download apps only to be presented with selecting providers for comment activities, only to want to revert to the built in provider (yeah you can clear the selection but they need to know where).
The destruction of the activity on rotation and on config changes feels like it's un-needed but exists because of legacy issues. The save/restore of activities values are simple but feel like it's best for simpler applications where limited amounts of data are shared / passed to Activities through Intents. It feels like the rotation feature was bolted on when it was introduced into Android (Android did not handle any rotation for multiple releases).
The roots of Android was for small devices and it's been expanded and grown to handle more complex applications and devices. To me this shows in the Intent / Activities pattern use though out Android. Small data, Activities and screens that worked well for small apps with low complexity but would would cause their own complexity if expanding for much richer and complex applications. A case is the Menu and Back buttons / actions. Yeah the buttons are gone in ICS, but the behavior still exists. I can see where these were of value in small devices (like the old Palm) and apps with there operation on the Activity stack, but with full featured applications in tablets, this may have limited use. The same for the data patterns of Intents as mostly the means of passing data to/from Activities. (This pattern is good for Activities outside of your applications scope, so it's more like an API in that usage). Internally in an app this pattern may be limiting with more complex data (updating multiple activities based on external data changes, async operations, etc.).
The fragmentation is a real issue with the slow rollout of updates from carriers, the multiple screen sizes and planning of base supported API's for my apps is a real concern.
The last issue is the simulator. It's badly in need of an update. The table version is so bad it drove me back to the phone version. Not good.
My bottom line on Android? I like it, it's fun and easy but some of Androids roots need to be considered in my applications designs so as not be limited by the Intents and data handling.
On the iOS front, I'll be going over the new iOS / Xcode 4.2 storyboard feature. Looks cool.
Android feels easy. Java feels like a well broken in shoe that slip on in the morning and can wear all day, so Android development feels easy for me. I understand the attraction of the Intents and Activities for the providing of multiple filters for handling common features (select you email, photo editors, etc), but I view this as more of a benefit for geeks rather than most consumers. What kind of support is there for uses that download apps only to be presented with selecting providers for comment activities, only to want to revert to the built in provider (yeah you can clear the selection but they need to know where).
The destruction of the activity on rotation and on config changes feels like it's un-needed but exists because of legacy issues. The save/restore of activities values are simple but feel like it's best for simpler applications where limited amounts of data are shared / passed to Activities through Intents. It feels like the rotation feature was bolted on when it was introduced into Android (Android did not handle any rotation for multiple releases).
The roots of Android was for small devices and it's been expanded and grown to handle more complex applications and devices. To me this shows in the Intent / Activities pattern use though out Android. Small data, Activities and screens that worked well for small apps with low complexity but would would cause their own complexity if expanding for much richer and complex applications. A case is the Menu and Back buttons / actions. Yeah the buttons are gone in ICS, but the behavior still exists. I can see where these were of value in small devices (like the old Palm) and apps with there operation on the Activity stack, but with full featured applications in tablets, this may have limited use. The same for the data patterns of Intents as mostly the means of passing data to/from Activities. (This pattern is good for Activities outside of your applications scope, so it's more like an API in that usage). Internally in an app this pattern may be limiting with more complex data (updating multiple activities based on external data changes, async operations, etc.).
The fragmentation is a real issue with the slow rollout of updates from carriers, the multiple screen sizes and planning of base supported API's for my apps is a real concern.
The last issue is the simulator. It's badly in need of an update. The table version is so bad it drove me back to the phone version. Not good.
My bottom line on Android? I like it, it's fun and easy but some of Androids roots need to be considered in my applications designs so as not be limited by the Intents and data handling.
On the iOS front, I'll be going over the new iOS / Xcode 4.2 storyboard feature. Looks cool.
Comments
Post a Comment