A lot of times, but especially when I am implementing some new logic, coding for me takes several steps:

1. Write down what I have to do as comments
2. Implement what I have written down
3. Refactor and improve what I have implemented

If you are just starting Android development or migrating from Eclipse to Android Studio, I gave a lightning talk on setting up some tools:

While we are on the subject of strings, here are more ways of dealing with them in Android Studio. We all know that we should not hardcode strings in code, right? But sometimes, we forget and tend to do code first before defining them in strings.xml.

I have been using git for about five years now, but I definitely get stumped by it a lot. It is so powerful it’s daunting. There has been a couple lot of times where I had been too careless and reliant on my fingers’ add-commit-push muscle memory that I realised I have made a mistake too late. I have always been a proponent of clean, atomic commits, and when I find my commits all messed up, I hit myself in the head.

In case you missed it, I made a blog post about updating our app to material design. In it I talk about what material design is and what we did to adopt it. I hope you enjoy reading it as much as I did writing it. :) Head on over to Domain’s tech blog for the details.

I recently had cause to use Jeff Gilfelt’s SQLite Asset Helper library. For those unfamiliar, it is a library that can help with including a pre-populated SQLite database with your Android application. It is extremely convenient with unbundling a potentially huge database you would want to ship.

Today, I ran into a weird “feature” of Android. I was working on an AutoCompleteTextView with the dropdown list having section dividers. It all works well in portrait mode, but gets all messed up in landscape.

I have recently came across this new View in the support library package that allows your app to have built-in support for pull swipe to refresh. This is pretty cool, since we don’t have to use any of the libraries out there. Admittedly, very little customization can be done, but then what else can we customize, right?

Trying to support as many devices as possible the best way possible is a very daunting task indeed. You will usually need to provide a lot of different layouts, strings, or dimensions (among others) to make your app look great whatever the user’s device is. And then you start chaining resource qualifiers and testing which resource is being loaded by the OS can become a nightmare very quickly.

There are times when using the default Android Views just doesn’t cut it and you need to create your own version of a View. So how exactly do you do that? It’s as simple as subclassing the View! But what if you want to add customizable attributes? Here’s how.