Even though I think Android xml res/ are very powerful, sometimes I have the feeling that it could be improved. But how could it be enhanced? In an empty world where you have the full power to do whatever you want, what would you do? Here is a list of ideas that came to my mind.
One thing I miss from Sass or Less is a way to use operators.
A Sass example would be:
article {
float: left;
width: 600px / 960px * 100%;
}which would be converted to this css:
article {
float: left;
width: 62.5%;
}Operators add a lot of clarity to the code. You wouldn't like to read a piece of Java code showing a value with no additional details.
So how about you could define dimensions like that:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<dimen name="textview_margin">10dp + 5dp</dimen>
</resources>or:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<dimen name="textview_margin">@dimen/activity_margin + 5dp</dimen>
</resources>You even use that directly in a layout:
<TextView
android:layout_height="wrap_content"
android:layout_width="wrap_content"
android:textSize="@dimen/activity_margin + 5dp"/>What I find messy in xml styles is the way inheritance is handled. Say I have this style:
<style name="MyTextViewStyle">
<item name="android:textColor">#FF0000</item>
</style>
<style name="MyTextViewStyle.Big">
<item name="android:textSize">30sp</item>
</style>This is fine as long as you don't have a huge list of styles and as long as things stay organised correctly. But everyone knows it is not true in a real world and your project will quickly become a war field.
What if you could do something like that:
<style name="MyTextViewStyle">
<item name="android:textColor">#FF0000</item>
<style name="&.Big">
<item name="android:textSize">30sp</item>
</style>
</style>This way things would get more manageable and organised.
Android xml layouts are quite powerful when it comes to modularity with the tags <include/> and <merge/>. Now, why not having this feature applied to styles:
<style name="RedThing">
<item name="android:textColor">#FF0000</item>
</style>
<style name="MyTextViewStyle">
<include style="@style/RedThing"/>
</style>
<style name="MyOtherTextViewStyle">
<include style="@style/RedThing"/>
<item name="android:textSize">30sp</item>
</style>Right now, xml styles only handle inheritance and I think it's really missing composition.
Again, if you take the example of Sass and Less, this is basically a mixin.
One annoying thing about xml resources is that it doesn't accept subdirectories. So you'll have to be careful and have this kind of structure if you want to keep things tidy:
/res
/layout
activity_main.xml
activity_profile.xml
activity_search.xml
If you try to order them in subdirectories...
/res
/layout
/activity
main.xml
profile.xml
search.xml
... references in R.java won't get created.
You might like (or not) xml language but I'm pretty sure you will agree that xml can get easily messy and hard to read. Every time I have to write this kind of stuff:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<dimen name="textview_margin">10dp</dimen>
</resources>I can't help to think this would be much simpler to have something like that:
dimen textview_margin: 10dp
I don't really have a preference for one syntax over another one. I think a lot of languages would be much cleaner.
I haven't found a lot of examples trying to fix these problems apart from these two:
- HoloEverywhere is using an internal library called ResBuilder. This allows to write your resources in
ymlfiles and easily fix the modularity issue. See an example of resources there. - LessRes by Jake Wharton is a work-in-progress concept trying to provide a way to have cleaner styles with the LESS-style DSL.
The main potential limitation of any of these solutions is that it must be correctly tied to the IDEs. Android Studio are pushing the resources to another level. So bringing another language could break that features. We could imagine a plugin that would auto-compile the source resources at every file update but that would be quite a big task.
However, that kind of system would add another layer of compilation (resource pre-processing) which would have to work in any case. If it doesn't, the project is screwed. Earlier last year I've worked on a project strongly based on AndroidAnnotations. I really think this library is fabulous but every time I was encountering an issue, I wanted to shoot myself because
- you can't have control on everything in such a library (and control is power)
- you have no workaround. When the dependency is too deep, you have to deal WITH it.
Coming from a web background, I found the Android approach interesting and powerful at first but when I started looking closer to it, I could find a lot of things to improve. Now, building an alternative is surely not trivial but even then I believe there is room for a resources pre-processor in Android development. So what's next? well what do you think? I will carry on with my research an maybe try something...
My two cents: the addition I'd like to see most (and would have the biggest impact on my day-to-day development work) is layout sub-directories. The rest seem like personal preferences, but sub-dirs would be awesome and I think would be your best chance of getting widespread adoption.