Last Updated on

Ever since Google started developing their own IDE, we, as an Android community, were thrilled with that idea. The idea that ditches Eclipse as a main Android Development tool and actually uses the best IDE base out there, IntelliJ Idea. Although the progress of developing Android Studio is shrouded with mystery and often desperation from developers, we have no other choice than using its potential as much as we can.

Table of contents:

  1. Basics
  2.  Libraries
    Debugging / Logging
  3. UI
  4. Deployment


One of fantastic features is, of course, plugin support. Let’s use it to our advantage, in particular ADB Idea is a terrific companion which obsoletes your adb scripts.

Now if you are as lazy as I am, I reckon you will consider  this plugin handy — it easily, almost effortlessly, converts SVGs to Android Vector Drawable.

I recently bumped to fantastic extension to the Android Studio that probes your code for potential vulnerabilities, . It works as a lint based task underlining portions of code that may cause security issues, offers a brief explanation of that particular issue and often even quick fix for that issue.

Last plugin I absolutely adore is CodeGlance, it allows you to see mini-map of your code and most importantly wider scrolling area for your mouse pointer to hit :).

With the Studio set up you will probably write new code in Kotlin. You also probably read this reference guide. And I would love to appeal to you with this: Please never, ever use !!. Instead, use safe calls ?. or ?:, use default values or return from function, whatever makes you happy. Thank me later. 😉



Although Android architecture is overly complicated and not up to current standards and needs it’s there and we have to use it (or we don’t?). There is certainly need, from developers anyways, for newer, more modern framework because what happens in the current MVP superstructure is that you cleaned your View (activities, fragments…) from all the logic and you have your Presenter filled with it.

I’m not, however, saying it’s necessarily a bad thing. Until we have some arch up to that task we decided to use Nucleus framework. It’s really simple, adheres to the KISS Principle, and really does all the hard work for you. What is really not ideal about it and I hear colleagues complaining about that (Hi!), is that it communicates with UI through RxJava. This solution doesn’t comply with a burst (short running) tasks and often leaves dialogs (or other UI components hanging really) hanging.

I’ve personally experimented with Android Architecture Components library since it removes Presenter dependency and returns back to filling up your activities (fragments respectively).


Now if you are expecting me to tell you that Volley is perfect and we use it on day-to-day basis, you must be so much working at Google… We obviously chose the easier and more extensible variant we had on hand, Retrofit. Although Volley can be literally milliseconds faster than Retrofit (when it uses OkHttp3), its interface is not worth it. Since we use RxJava (2) extensively in our projects, there is no way in hell we would use Volley just for this reason alone.

We pair Retrofit with OkHttp3 since, you know, network interceptors are cool!


If you are into software development, you are probably lazy. No offense meant there, it’s fantastic to be lazy as a developer! So are we by the way… I mean not fantastic, hmm, yes, we are fantastic, but… lazy! We like things that are done for us automagically and we are happy for things that are effortless. SPG – never ever get annoyed by Shared Preferences any more.

Speaking of getting annoyed, there is the Dagger. Declare once, use forever. The convenience of simply injecting whatever you just need is priceless. I know, I know. The sample Google provides is way too complicated to understand for newcomers, to you I’d say: “Create sample project, include Dagger to it and play with it. That’s literally the only way you are gonna get how it works.”

I’d say experienced developer has to know how to use RxKotlin (yes, we do not use Java anymore). Reactive programming is entirely based on working with streams, although I find it extremely convenient to write and read in any multi-threaded workload.

In case you are familiar with Kotlin, the language has extensions like a map which changes the return type of List based on your choice — so does Rx!
It effortlessly switches between threads, you can even create “custom” thread and other fabulous stuff ^^.

We actually use Rx as Event bus as well! It’s pretty exciting — we use standard flow to deliver Events to subscribers (instead of annotation based consumers). This approach is a bit better for us since you can unsubscribe from these event streams any time. 🙂

Recently we started using KTX, Kotlin — Android specific extensions. Common project of Google and developer community! Google is actually encouraging developers to create pull requests if you see some potential improvement to this library! Feel free to create one too.

We have swiftly adopted a new database tool, Room. It has been now a year (at the time of writing) since this library was publicly announced and the stable release is yet to come. That obviously haven’t stopped us since it’s way more seamless than other, competitive, implementations. It still uses SQLite as a base, but it provides extended utility and simplifications over it.

Honorable mention goes to Realm. It always throws exceptions on me, but I still think is a cool concept of a database!

Debugging / Logging

Honestly default debugging and logging tools in Android (Studio) are sufficient for regular use and there’s no need for anything else. But yet we are lazy and getting annoyed pretty easily, so we use several libraries that make our road way less bumpy.

First off all I have to make a shout-out to Twitter that initially developed Fabric and then made, hopefully, a great decision and sold the Fabric team to Google. Now we have Fabric integrated with Firebase and that’s probably the one thing you won’t want to use. Google’s habit is destroying everything good about acquired services and make them as bad and as paid as possible, so expect this here. Otherwise Fabric is absolutely my favorite debugging tool ever — it gives you live statistics, collects crashes and dumps alongside the way.

Then you get your testers up and running and asking them to look what’s in a specific field or logs can be difficult. No, it’s literally impossible. Here Stetho comes into play, just teach your monkeys (lol, don’t use monkeys, please) to type chrome://inspect to their browser and you are done. It really doesn’t work for developers all the time, since it’s limited in infinite number of ways, but the convenience is there and we appreciate it!

Another annoying thing is the logging itself. You see, there is really no need for you to write Log.d(TAG, message) that’s annoying for sure. Timber provides a small utility (and API) over the standard Log class. Of course you can customize it via planting your own tree (how poetic, isn’t it?) and instantly trash the standard Log class and use Logger instead.
Logger provides increased readability of your logs in logcat. You can let Logger print stack of where was the log called from, show thread info — it’s a really powerful logging tool!


With Kotlin there comes the Android Extensions plugin. It works as a kind of extension for View based objects. This is actually very important since keeping references to views is not a great practice. It helps developers to develop good habits and it’s not as annoying as fetching, setting and removing view references one by one.

Every app has to show images at some point, right? Every app of ours does for sure, so we opted for Glide to make our job way easier. Of course, somebody likes to keep their bitmap compression algorithms instead of using a whole new library to do the same thing, but yet — we don’t like to waste our time ;). I personally like Fresco more for it’s pipelines and customizable flow, however since it requires its own special View others may see it rather as a burden.

If you follow Android devs on Twitter you may have stumbled upon their feedback surveys. Man, I love these surveys, every time you’ve got the opportunity to tell them what’s wrong and they absolutely don’t listen to your feedback whatsoever and make something as painful as permissions system. Okay, it’s beneficial for users, but is it pleasant for developers to implement? Hell no. Since Google is incapable of fixing this, another developer (group) rushed in to help and made library, which, you guessed it, requests permission and has one, yes one, callback. Dexter.

We have been waiting for the major performance improvements since base View! It has come in form of Constraint Layout which is, ugh not much of a performance improvement for us; It’s definitely a pleasant thing to work with nonetheless. It provides tools for basic set of animations with your views and significantly flattens your view hierarchy, unless there have to be backgrounds under some portions of your layout which Google engineers didn’t think of. Duh. To be fair, it has a lot to offer and at least deserves to be tried out.

To my last breath I’d like to express that Google provides set of AppCompat tools — like Views AppCompatImageView , AppCompatTextView and more — which provide significant utility improvement over standard Views, unifying architectural changes to native Views so every View in each of previous platforms can use features introduced in the latest. Please use it mindlessly. Seriously.


First and foremost, we try to hold on to Semantic Versioning principle. Which means versions like 0.0.4598 is nothing uncommon as long as you made 4597 patches before it and made 0 functionality additions. (Which should obviously be only in the initial development stage, lol)

We have no local git server, because you know… you can never be too safe. power goes down => no backup => we're screwed type of scenario is eliminated by having projects hosted in the cloud. In our case, it’s Bitbucket. Atlassian yeeey. We don’t use any other functionality accompanied with Bitbucket as far as I know, but(!) we have our own build server so we don’t need that anyways :).

For git itself, I don’t think we have many rules in place except feature-branching. Immediate changes are often accepted to master branch, however features should be branched out. Contributors to these features are urged to merge their changes to master and after all, features planned for the next release are merged the last commit is flagged with release type and version.

Unlike Netflix, who are well known for deploying several times a day, we deploy only a few times a week.

      • Alpha — are the most frequent and used for internal testing
      • Beta — which is used by clients or external testers
      • Release — app is released to users/public

However the releases do not have the same package name. Unless it’s a public release it has a suffix which corresponds to the build type. Distribution is naturally split in those respective apps and every release is distributed though Google Play (unpublished apps with Alpha testing).

Wrap up

Thanks for reading and have fantastic coding sessions!

Viktor De Pasquale