Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Sneak peek of the Android Report: the Platform, the Framework, and the Way of Life

android report teaser header

Some say that time flies like a banana. While I don’t have any soft yellow fruit near me to test that theory, it sure does feel like time passes by at an alarming rate. We are already in October and I’m happy to say that we are almost ready to publish the next RebelLabs report — look out for it hitting the streets next week!

This time the topic of the report is the Android platform and everything you ever wanted to know about it. Both the Android platform and its ecosystem are too big to cover in one report, so naturally we had to be selective with the topics. Having looked on the interwebs and talked to Android developers, we concluded that everyone is interested in following best practices. The only problem is, there aren’t any guides out there that explains them in an informative, yet beautiful manner!

There are many resources available, some of them created by the excellent Android team at Google, but in this ocean of information we could not find a cohesive picture. So that’s why we created this report.

We hope the report will build a solid foundation for anyone who intends getting into Android development seriously or perhaps just test the water. In this teaser blog post, we’re going to just cover the intros into the following topics.

  • Android Devices and platform considerations for your application.
  • Performance — how not to make your application crawl.
  • Clean code patterns — dependency injection, clean architecture, parallelization models and a reactive approach to creating applications.
  • Good ways to approach and improve QA in your project.
  • Tools and technologies that help developers the most: emulators, libraries and much more.

We’re going to tease you with a bit of content straight from the report which looks at Dependency Injection and why it is important on Android, just as it is in core Java.

Dependency injection

If you want the canonical definition, you can always check the canonical definition on Martin Fowler’s blog or this other link (you know you really shouldn’t click links with such a lame description). If you want the knee-deep-in-the-mud-trenches definition, keep reading and bookmark the previous links for later.

Dependency Injection can be used with or without changes you might make to separate your business logic to your Android layers. That being said, the two are certainly related, as we will see when we consider the next few scenarios.

Ponder the following, let’s call it scenario 1: you have had an amazing idea for an app, you begin to get deeper in your coding and all of a sudden you have lost all your focus — you are worried about the wiring details. Java is pretty verbose by itself, but the Android Framework just turned the dial all the way to 11!

Let’s take a look at a different case, scenario 2: you have just finished adding a new feature to your app. Now you notice that some parts of your code look like they will be needed in other places. You know you want to put that code somewhere else, but you start wondering where to store it.

And finally, scenario 3: Don’t get us started on testing! How would you prefer to write your tests? Would you like them to take forever to complete because you can only test it once the whole app has been built — including UI, persistence and so on? Perhaps you would rather write a tiny test that is only focused on the small part you actually want to test, ignoring the rest of the application? As a seasoned developer, you might have experience with a different language/platform, one where you have lived happily ever after knowing about the benefits of Dependency Injection (DI). But let’s take a look at it, for those who have not used it before.

Dependency Injection is just a fancy way of saying: hey runtime, could you please create and pass me an instance of blah as a field or parameter so that I can use it to do my task, with regards, me. You are essentially delegating the creation of those objects to a managed service (i.e. all the calls to a constructor will be in one place rather than scattered across your code).

We are going to leave the different ways we could apply this principle for another time. Here we focus more on how to use Dagger, the “de facto” standard of DI in Android. Dagger follows the Java Specification Request (JSR) for DI and you can begin by annotating the fields you want Dagger to inject for you as shown below:

public interface ForecastRepository{}

public class SyncService extends Service {
  //SyncService needs ForecastRepository
  ForecastRepository forecastRepository;

@Module(injects = SyncService.class)
public class AppModule {

  //Here we specify which implementation of the interface needs to be injected when requested
  public ForecastRepository providesForecastRepository(final SQLiteRepository forecastRepository) {
    return forecastRepository;

All right, we bored you with all the details on how to use DI and we have not even told you what you can do with it yet! Fair enough. Remember the three scenarios we discussed before? They all have the same solution, DI!

In scenario 1 you can inject your classes, which means you can worry about wiring them up later. This means you can keep your flow, or train of thought while you are developing a new feature.

In scenario 2 — where you have decided to extract some of your code into a separate class — you can inject that extracted code which makes the creation of that object an implicit task. You can choose to create a new one every time and perhaps change it later to a singleton by adding a simple annotation. What about scenario 3 with its  I-need-to-create-the-whole-world-before-I-can-test-anything situation?

Well, you will be injecting a fake version of the rest of the world that does nothing and test what needs to be tested — not the whole world. How is that for a life-changing insight? Yeah, we’re the best!

Not convinced? Here’s another snippet from this outstanding report. This section is taken straight out of our Android tooling section.

android report JRebel For Android Card

There’s a magnificent productivity enhancement that you should try called JRebel for Android. Yep, this one has been developed by ZeroTurnaround! (Shameless plug, we know, but you must have seen that coming, right?).

Anyway, JRebel for Android allows you to develop your Android applications in real time. All the changes made to your code are automatically propagated into the running application. You do not have to build, install or run your application every time you make a code change. Code or resource file changes can be changed to see the changes on the device or emulator immediately, without even changing the state of your application in the runtime.

The JRebel for Android plugin integrates with Android Studio. The plugin adds a new launch option that will instrument your application with a small agent app, which will in turn incrementally pick up changes to your code base and reload them within the running application process. If the changes are in the callback methods that Android framework is full of, the agent will quickly re-execute them. This means that the changed code will have the full impact even if the application has already started and the code in the onCreate() or onCreateView() methods has been executed already.

Amazing, right? You can find a bit more details in this blogpost on the internals of JRebel for Android.

That’s all we’ll show you for now, but check back next week for the full report. Are you excited? Good, we sure are!

So, keep an eye out for the report, follow us on Twitter to see the announcements (@ZeroTurnaround) or just subscribe to our email and we’ll send you the report as a beautiful pdf.



Read next: