My two cents on how to deal with wrapped json objects by using Retrofit converters

I’m sure everyone has had the joy of dealing with wrapped objects in json. The best part of them is that you get to check for errors 3 times: IOException, isSuccessful, and the response’s custom result code, if you were to use the default Call<> object provided by Retrofit 2.

What is a view? Why would I create my own? and…how does it work?

If you don’t know whether you need a custom view or not, you probably don’t. Most UI elements can be easily expressed using the elements of the Android framework, the support library, or the Google design library.

If you still did not find what you were looking for try GitHub first. Especially for Android there are thousands of libraries, some of them might do what you want. And now that you still didn’t find anything that you can or want to use, because your usecase is very special in some way…Now I have to admit: You probably need a custom view.

You might have heard: Firebase is the new thing. It is here, it is awesome, and I believe it will make all of our lives somewhat easier.

If you decide to switch to Firebase you will end up using analytics within your app. The default reports alone are worth the few steps it takes to set it all up. Tracking events has never been easier and I am hooked, although, to me, Firebase Analytics seems more like something that I want to use in addition to Google Analytics. While Firebase helps me to get my app up and running, Google Analytics still shares some valuable insights.

Dagger 2 can be confusing. This shall shed some light on the key concepts and highlight their proper use. You could start by reading the User’s Guide to acquire the general and official knowledge, and once you have brewed your coffee, pray, continue.

This is going to be a short post because I’ve seen a lot of custom implementations to provide the well known a few minutes ago labels, which are often hard to maintain and rarely properly localized.

There already is an implementation for this—no, it’s not JodaTime.

There are many opportunities where the usage of a custom drawable will lead to nice, clean, and reusable results. If you need to display changing text inside an icon or introduce a custom progress indicator like in Modifying the resource image of Progress Bar on Stack Overflow, you can easily do so with custom drawables.

Testing is important, and you should be testing.

Testing on Android is still a big issue. Whether you feel that your app isn’t big or popular enough, or just don’t know how to start, there are many reasons why you won’t get involved with tests. But I find that writing testable code (and actual tests) can lead to far better, scalable, and maintainable software.

Just a quick update to my last post on a little thing I missed out: Animations.