Back when I was a Windows developer, I learned all sorts of arcane things about the platform. I felt I had to in order to be a good developer, and much of it was necessary to support customers running into problems.
Four years ago I bought a Mac, and three years ago I ditched Windows entirely and started learning Android development on my Mac.
I decided I really didn’t want to learn all the innards of the Mac. I never liked dealing with all that on Windows, and since I wasn’t a Mac developer I figured I could skip it.
Which means, of course, that I’m totally useless with the command line. Terminal? No thanks. Bash? Forget it. Git? I’ll use SourceTree instead. If it doesn’t have a GUI, I don’t want to touch it.
Sure, there are probably a ton of cool things I could do from the command line. But I’m happier not feeling I need to know all that stuff.
I often run across Android layouts which use hard-coded margins, padding, and font sizes, like this:
Doing this often leads to inconsistency. Different layouts end up hard-coding different font sizes and margins, making the app appear less polished.
To avoid this, I recommend defining the sizes in values.xml like this:
And then referring to these sizes in your layouts like this:
If every layout uses only the sizes defined in values.xml, then not only will your app appear more consistent but it will also make it much easier to adjust sizes application-wide.
Making a ListView scroll smoothly is a bit of a black art for Android developers, but there are a few simple rules:
- Use the View Holder pattern
- Do as little work as possible in getView()
- Reduce unnecessary overdraw
- Flatten the view hierarchy
The View Holder pattern is well known, but that second rule often gets ignored despite having the biggest impact.
Because getView() is called every time a cell is drawn, any extra work done there will slow things down. Things like formatting dates, manipulating bitmaps, querying SQLite, or loading image resources should be moved out of getView() and instead computed and cached prior to the list being populated.
Unnecessary overdraw can be caused when one view covers another one. If both views have a background, both backgrounds will be drawn even if the first is completely covered. The simplest way to find overdraw issues is to enable “Show GPU Overdraw” in the device’s developer options. If you see dark red blocks behind your ListView text after enabling that option, it’s time to work on overdraw. Simply getting rid of unnecessary background colors/drawables can make a huge difference. If you have an activity whose background is completely covered by another view, you may be able to get rid of one layer of overdraw by calling getWindow().setBackgroundDrawable(null) after setContentView() in the activity’s creation.
Flattening the view hierarchy in your layouts not only helps reduces overdraw but also means less work has to be done when the layout is inflated and drawn. When I create an XML layout, I’ll often use a ton of parent views (RelativeLayouts, LinearLayouts, etc.), to make it easier to group things and move them around. But once I’m happy with the layout, I try to remove as many of those parent views as possible.