You don’t need to code it: how I address common Android problems

Android is an awesome platform that enables you to impact millions of users, but, even after so many years in the market, there are still several basic problems that are still a pain to solve and haven’t been included in Android’s core Software Development Kit.

In order to solve these key problems, I’ll point some great tools and libraries – developed by the Android community – that are widely used and a breeze to work with. They  are all open source, available on GitHub and actively maintained. Now, let’s start!

1. Communicating with REST APIs

Nowadays most of our apps are connected to the Internet and exchanging data with REST APIs. Now Android doesn’t have a method set in stone, but their suggestion to do this makes me shiver. It suggests using AsyncTasks, HTTP objects and parsing the response. No way!

Fear not, young padawan – that’s why I’m writing this post. If you have been an Android Developer for a year or more, you have most likely heard or used Retrofit. But if you haven’t, stay a while and listen: Retrofit is a library that helps you communicate with a REST API in a clean and organized way.

The value of Retrofit lies in how it enables you to describe your endpoints as interface methods. These methods are all you have to worry about when defining your endpoints and HTTP verbs — whether they are GETs, POSTs and so on. Here’s an example (yeah, it’s that simple!):

@Headers("Content-Type:application/json")
@GET("v1/model/{id}")
Observable getModelFromServer(@Header("Authorization") String userKey, @Path("id") long modelId);

Retrofit is very easy to attach to your project, has a low footprint in your app and its learning curve is very low. When combined with tools like Apiary, a well-documented RESTful API (and maybe RxAndroid?) you can take care of your network assignments in a very short time. Of course, Retrofit isn’t the only option out there — but I urge you to try it if you haven’t. You won’t regret.

2. Custom Fonts

The first time I received a design with unconventional fonts used all over the app, I expected that all I needed to do was import the font file to the project and use a magical XML attribute that would enable the custom font. But then the reality hit me in the face: that magical attribute doesn’t exist.

After thinking a bit, I came with 2 options on how to apply that custom font:

1. Setting it programmatically on each view — choosing this option forced me to call each view separately and define its font, which generated a lot of duplicates in my code (or forced me to end up using a Helper method all over the app);
2. Creating a custom View and defining the magic attribute I expected it to have. Ok, this sounds like a good solution, but hum…

Now, what if the design mockups included custom fonts in all components? Which option would you go with? What about a third option? Calligraphy!

Calligraphy does what I expected Android to have implemented by default. It allows you to define a custom font as your app’s default and provides that magical attribute to every view! Now this seems like the right way to go!

It’s very easy to use Calligraphy in your project, you just need to enable it using your Application and overriding the method attachBaseContext in your Activity (I suggest using a BaseActivity for your project).

// Inside your Application

private void setDefaultFont() {
    CalligraphyConfig.initDefault(new CalligraphyConfig.Builder()
            .setDefaultFontPath(getString(R.string.roboto_regular))
            .setFontAttrId(R.attr.fontPath)
            .build());
}

// And on your Activity

@Override
protected void attachBaseContext(Context newBase) {
    // Attaches Calligraphy to the Activity
    super.attachBaseContext(CalligraphyContextWrapper.wrap(newBase));
}

That’s it! Next task!

3. Image Caching

Images! As we all know, an image is worth a thousand words — and that is true for software development as well: an image is worth a whole lot of strings words! Nowadays our apps make use of a lot of images that are dynamically retrieved from an external source, and this forces us to download them, parse them, and who knows… save it on memory?

To decrease the number of times we need to retrieve it through our requests (and prevent OutOfMemoryExceptions) we should take advantage of image caching. Obviously, Android has a bunch of features that enable you to implement your Image Caching logic — but as with this article I want to point you on how to overcome these hindrances quickly, I’ll present a great option.

Glide has a very straightforward usage: all you need to do is inform the target ImageView and the URL from where to fetch. Glide will do its magic and define whether it should fetch the image for that particular URL or use the cached version. But it doesn’t stop there: you can also define a placeholder for when your image is still loading, an error image for better UX when the fetch goes wrong, and also… wait for it… there’s GIF support!

If you have heard or used Picasso, you must probably be thinking that Glide is a Picasso rip-off, but their similarities are only in syntax: Glide has some under-the-hood modifications for better performance and optimal memory usage.

4. Databases

We can all agree that Database on Android is a pain — having to implement the SQLiteOpenHelper, writing SQL queries and all the bureaucracy that comes with it. Don’t misread me, it’s good to know all about that — but sometimes it’s a smarter choice going with a more direct approach like Realm, Requery or DBFlow.

You might have noticed that I didn’t point you to a specific library, but there’s an explanation: I still don’t have a personal favorite. All three of them are widely used by developers, and articles comparing and talking about them are widely spread on the Internet.

• DBFlow makes use of the annotation processor, which enables you to annotate your model classes defining tables and columns. Querying your data using DBFlow is really simple making use of the Builder Pattern for creating the query.
• Requery also makes use of the annotation processor for creating the database based on the models. But what makes it stand from the others is its support for Java 8 streams and RxJava’s Observables. Requery is relatively new but has been turning lots of heads towards it for its features.
• While Requery and DBFlow build an Object-Relational Mapping (ORM) on top of the SQLite of Android, Realm went beyond it and developed its own multi-platform database (supporting iOS, Javascript and Android). For your models, you must extend a RealmObject available in the library, this object makes available the CRUD methods for the model. As a plus, Realm have available a browser for reading the created database binary (.realm).

All three of them are great, but if you must know — right now I would go with Requery as my next project’s database, as I have been using RxJava a lot in my projects.

Wrapping Up

I hope this post sheds a light on a couple of easy solutions for problems you’ll encounter in most of the Android apps you’ll build. Please, share your experience with these libs and any other you think are awesome in the comments section!