Note: please read this short post before continuing forward.

A common issue in Android development is backwards compatibility. How can we add cool new features from the most recent Android API while still ensuring that it runs correctly on devices running older versions of Android? This post discusses the problem by means of a simple example, and proposes a scalable, well-designed solution.

As with most areas in software engineering, debugging is a crucial aspect of Android development. Properly setting up your application for debugging can save you hours of work and frustration. Unfortunately, in my experience not many beginners learn how to properly make use of the utility classes provided in the Android SDK. Unless you are an experienced developer, it is my personal belief that Android debugging should follow a pattern. This will prove beneficial for a couple reasons:

With Android 3.0 came the introduction of the LoaderManager class, an abstract class associated with an Activity or Fragment for managing one or more Loader instances. The LoaderManager class is one of my favorite additions to the Android framework for a number of reasons, but mostly because it significantly reduces code complexity and makes your application run a lot smoother. Implementing data loaders with the LoaderManager is simple to implement, and takes care of everything about lifecycle management so are much less error prone.

I recently came across an interesting question on StackOverflow regarding Fragment instantiation:

What is the difference between new MyFragment() and MyFragment.newInstance()? Should I prefer one over the other?

Good question. The answer, as the title of this blog suggests, is a matter of proper design. In this case, the newInstance() method is a “static factory method,” allowing us to initialize and setup a new Fragment without having to call its constructor and additional setter methods. Providing static factory methods for your fragments is good practice because it encapsulates and abstracts the steps required to setup the object from the client. For example, consider the following code:

One thing that I’ve noticed other Android developers having trouble with is properly setting up their SQLiteDatabase. Often times, I come across questions on StackOverflow asking about error messages such as,

E/Database(234): Leak found
E/Database(234): Caused by: java.lang.IllegalStateException: SQLiteDatabase created and never closed

As you have probably figured out, this exception is thrown when you have opened more SQLiteDatabase instances than you have closed. Managing the database can be complicated when first starting out with Android development, especially to those who are just beginning to understand the Activity lifecycle. The easiest solution is to make your database instance a singleton instance across the entire application’s lifecycle. This will ensure that no leaks occur, and will make your life a lot easier since it eliminates the possibility of forgetting to close your database as you code.