The basic beliefs of Buddhism is that there is much suffering in life and much of the suffering is self inflicted. There are many things that have caused me pain and strife in my life, but I really work on not adding to the amount of strife that I'll already endure. My developing software is always a source of self-induced strife and I look for reducing my self punishment as much as possible.
If you have been in this business a long time then you have been approached by friends or associates to create some software for free. It's a hard choice sometimes, but the best answer maybe 'no'. Software takes time, the lifecycle is long (how long to maintain?) and it can distract time from your family and happiness.
Does this apply to companies as well? I would think so. Let me explain what I see is currently occurring in mobile developement.
Knowing both iOS and Android development, I've noticed a divergence of benefit to the developers and to the respective companies. iOS is only on two form factors (iPhone and iPad). Android is on a range of form factors from 3" to 10" and above, each with varying screen ratios. For the most part, the general development was the same.
You could handle the UI controls and layout in code (lowest level), create views for each screen on a screen (controller / activity) by screen basis. So far these have been the same for both platforms.
For iOS you had the option of having two different views (nib files) for each controller, one for iPhone and one for iPad. The different views could both access the same (or different) controllers for sharing code. Almost all UI could be created using the Interface Builder which is a big help. The down side was IB had a learning curve that can throw developers off the iOS platform.
For Android you basically had multiple layouts possible for each activity. This was basically the same as iOS. The main difference was that most everything with the layout was hand rolled XML with references to other XML files and resources. Lots of references and Ids to keep track of. Yes there is a UI Builder but they could use a lot of work, so I've found it's just easier to edit the layouts by hand.
Now the divergence..
Android did not handle tablets, so a new pattern was added to the mix of Activities and Layouts. These are the Fragment classes. This will work but adds to the burden of the developer and increases the complexity and permutation of activities, layouts and now fragments to try to provide workable solutions for the wide range of form factors. All this while not providing any additional tools to handle this added complexity. It's still all XML, references and resources basically by hand. So as a developer do you make a decision that all forms from 3"-7" get the phone version and the 8"+ get the tablet version, or do you try to create layouts and fragments for even more sizes to provide better screen usage? It's not looking good.
iOS on the other hand has made life easier for developers. You can still create nib files for each controller, but the preferred method is now the storyboard. Instead of multiple nib files there is now a single storyboard file for each form factor. It contains all the views, controls, segues and transitions for all the views for the complete app. This is all laid out in a single screen in Xcode for the developer to work with and provide a single screen view of the complete app. Navigation, Tab, SplitView, Modal and others UI patterns are all supported. Each view within the storyboard can then be assigned to a specific Controller with the UI controls wired up to controllers objects. For a universal app there would be one storyboard for iPhone and one for iPad, each showing the complete workflow and operation and without any code, xml, references or Ids. Apple has provided a solution that has reduced the complexity of the code and made it easier for the developer while still providing an optimal solution for the user.
Apple appears to be limiting choice, with benefits to its developers, users (better apps) and themselves, where they can continue to move forward with tools and platform without too much technical debt.
Google appears to be heading in the opposite direction. With the possible permutations from all the different form factors, increased complexity of the Activity/Fragment/Layout pattern, along with developed less likely to provide solutions for all options, a case could be made that Google is hurting themselves, their developers and users.
Which path reduces my future pain?
If you have been in this business a long time then you have been approached by friends or associates to create some software for free. It's a hard choice sometimes, but the best answer maybe 'no'. Software takes time, the lifecycle is long (how long to maintain?) and it can distract time from your family and happiness. Does this apply to companies as well? I would think so. Let me explain what I see is currently occurring in mobile developement.
Knowing both iOS and Android development, I've noticed a divergence of benefit to the developers and to the respective companies. iOS is only on two form factors (iPhone and iPad). Android is on a range of form factors from 3" to 10" and above, each with varying screen ratios. For the most part, the general development was the same.
You could handle the UI controls and layout in code (lowest level), create views for each screen on a screen (controller / activity) by screen basis. So far these have been the same for both platforms.
For iOS you had the option of having two different views (nib files) for each controller, one for iPhone and one for iPad. The different views could both access the same (or different) controllers for sharing code. Almost all UI could be created using the Interface Builder which is a big help. The down side was IB had a learning curve that can throw developers off the iOS platform.
For Android you basically had multiple layouts possible for each activity. This was basically the same as iOS. The main difference was that most everything with the layout was hand rolled XML with references to other XML files and resources. Lots of references and Ids to keep track of. Yes there is a UI Builder but they could use a lot of work, so I've found it's just easier to edit the layouts by hand.
Now the divergence..
Android did not handle tablets, so a new pattern was added to the mix of Activities and Layouts. These are the Fragment classes. This will work but adds to the burden of the developer and increases the complexity and permutation of activities, layouts and now fragments to try to provide workable solutions for the wide range of form factors. All this while not providing any additional tools to handle this added complexity. It's still all XML, references and resources basically by hand. So as a developer do you make a decision that all forms from 3"-7" get the phone version and the 8"+ get the tablet version, or do you try to create layouts and fragments for even more sizes to provide better screen usage? It's not looking good.
iOS on the other hand has made life easier for developers. You can still create nib files for each controller, but the preferred method is now the storyboard. Instead of multiple nib files there is now a single storyboard file for each form factor. It contains all the views, controls, segues and transitions for all the views for the complete app. This is all laid out in a single screen in Xcode for the developer to work with and provide a single screen view of the complete app. Navigation, Tab, SplitView, Modal and others UI patterns are all supported. Each view within the storyboard can then be assigned to a specific Controller with the UI controls wired up to controllers objects. For a universal app there would be one storyboard for iPhone and one for iPad, each showing the complete workflow and operation and without any code, xml, references or Ids. Apple has provided a solution that has reduced the complexity of the code and made it easier for the developer while still providing an optimal solution for the user.
Apple appears to be limiting choice, with benefits to its developers, users (better apps) and themselves, where they can continue to move forward with tools and platform without too much technical debt.
Google appears to be heading in the opposite direction. With the possible permutations from all the different form factors, increased complexity of the Activity/Fragment/Layout pattern, along with developed less likely to provide solutions for all options, a case could be made that Google is hurting themselves, their developers and users.
Which path reduces my future pain?
Comments
Post a Comment