{"id":2818,"date":"2016-05-20T20:34:56","date_gmt":"2016-05-20T20:34:56","guid":{"rendered":"http:\/\/www.ckl.io\/?p=2818"},"modified":"2022-07-01T17:57:16","modified_gmt":"2022-07-01T17:57:16","slug":"how-to-address-common-android-problems","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/how-to-address-common-android-problems\/","title":{"rendered":"You don’t need to code it: how I address common Android problems"},"content":{"rendered":"

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.<\/p>\n

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

<\/p>\n

\"Come1. Communicating with REST APIs<\/h2>\n

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

Fear not, young padawan \u2013 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<\/a>. 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.<\/p>\n

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!):<\/p>\n

\n@Headers(\"Content-Type:application\/json\")\n@GET(\"v1\/model\/{id}\")\nObservable getModelFromServer(@Header(\"Authorization\") String userKey, @Path(\"id\") long modelId);\n<\/code><\/pre>\n
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> a well-documented RESTful API (and maybe RxAndroid<\/a>?) 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.<\/p>\n
2. Custom Fonts<\/h2>\n
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.<\/p>\n
After thinking a bit, I came with 2 options on how to apply that custom font:<\/p>\n
    \n
  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);<\/li>\n
  2. Creating a custom View and defining the magic attribute I expected it to have. Ok, this sounds like a good solution, but hum…<\/li>\n<\/ol>\n
    \"Nope\"<\/p>\n
    Now, what if the design mockups included custom fonts in all components? Which option would you go with? What about a third option? Calligraphy<\/a>!<\/p>\n
    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!<\/p>\n
    It’s very easy to use Calligraphy in your project, you just need to enable it using your Application and overriding the method attachBaseContext<\/a> in your Activity (I suggest using a BaseActivity for your project).<\/p>\n
    \n\/\/ Inside your Application\n\nprivate void setDefaultFont() {\n    CalligraphyConfig.initDefault(new CalligraphyConfig.Builder()\n            .setDefaultFontPath(getString(R.string.roboto_regular))\n            .setFontAttrId(R.attr.fontPath)\n            .build());\n}\n\n\/\/ And on your Activity\n\n@Override\nprotected void attachBaseContext(Context newBase) {\n    \/\/ Attaches Calligraphy to the Activity\n    super.attachBaseContext(CalligraphyContextWrapper.wrap(newBase));\n}\n<\/code><\/pre>\n
    That’s it! Next task!<\/p>\n
    3. Image Caching<\/h2>\n
    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<\/del> 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?<\/p>\n
    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.
    \n\"Alladin
    \n    Glide<\/a> 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!<\/p>\n
    If you have heard or used Picasso<\/a>, 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.<\/p>\n
    4. Databases<\/h2>\n
    We can all agree that Database<\/a> on Android is a pain — having to implement the SQLiteOpenHelper<\/a>, writing SQL<\/a> 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<\/a>, Requery<\/a> or DBFlow<\/a>.<\/p>\n
    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.<\/p>\n