| > XML is parsed on the device wasting CPU time and battery It was my understanding the XML was compiled into a binary format for faster parsing on device, am I wrong on that? EDIT:
http://en.wikipedia.org/wiki/Android_application_package "resources.arsc: a file containing precompiled resources, such as binary XML for example." Ah yes, I think it does. > Most of all, it allows no code reuse. If we are talking code reuse in terms of having one common bit of layout that is used across several different layouts, actually you can: http://developer.android.com/training/improving-layouts/reus... Also, the Android view system as it stands is incredible flexible. You can provide different layouts and style rules for different screensizes and device configs - an kinda equivalent to the webs responsive design using CSS media queries. Also, every view component is just a Java class. As well as allowing you to create your own class from scratch that you can just use as part of a view, you can also extend an existing view class and just change one bit of it's behaviour. I don't especially mean to have a go at Anko - sorry. It's just that I think the Android views are actually pretty good, and certainly when I'm working on Android apps this isn't one of the major problems I have! |
Interesting point - the resource table still has references to the XML files for configuration-resolving purposes, but they are only strings. E.g. getString(R.layout.main) will actually work and return "res/layout/main.xml" or "res/layout-land/main.xml" depending on the device configuration (and assuming one has the layout-land version). Vice-versa, if you have a string resource with the value "res/layout/main.xml" and say, name foo, then calling setContentView(R.string.foo) actually works.