Blockchain Transactions: UTxO vs. Account-Based Models
Gustavo Martins | Oct 31, 2024
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!
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.
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:
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!
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.
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.
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.
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!
Driven by results, I enjoy programming and seeing the results being used and appreciated. On the spare time, I enjoy reading both books, HQ and Manga with some soccer on the side!