froger_mcs dev blog

Time to move on

Tue, 02 Jan 2018 00:00:00 +0000

After a couple years of publishing posts here I have decided to move on to the more flexible blogging platform. frogermcs.github.io was originally created as a content-first project. The idea behind it was to setup website as fast as possible, with almost zero configuration - no HTML/CSS, no server nor domain setup. And Jekyll + Github Pages combination was the best option for it - the platform was ready to publish literally in an hour. Now I’m moving on to something a bit more complex but with much bigger flexibility. Also something even more personal. My new website will still be mostly focused on coding. But over the time I have developed a couple more areas of interest (AI, leadership, self-development) which in sum with coding will lead to something much bigger. Let’s call it “building solutions with love {❤️}”. At the end, the things we code are designed to serve people - to unlock possibilities, inspire, make something better. I hope, the experience I share will help with that.

I invite you to my new home: https://mirekstanek.online. I hope you’ll find there something interesting for you!

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Basic Android app analytics in <60min

Thu, 27 Jul 2017 00:00:00 +0000

Every big tech company today is data-driven. Products are more often built based on collected data rather than internal opinions. It’s very likely that in this moment some of apps on your device are serving you A/B test variants, checking how: new layout, text or even functionality affect your activity and engagement.
The biggest companies have dedicated Business Intelligence teams, their own data warehouses, custom analytics tools and big flat screens in conference rooms showing realtime charts.
And the most important — endless audience waiting to be analysed by pie charts or bars 📊.

So if you are member of small mobile-dev team, your app just touched the market or even won’t go out of Android Studio, you may think that data analysis isn’t your problem yet.

You can’t be more wrong. 🙂

There won’t be any analytics people in the future who will join your team just to add some data loggers here and there. Because as usual — everything starts with developers - it depends only on you how quickly you’ll make your app data-driven. Believe me, there won’t be easier than now to start collecting the data and in case you are not doing it yet, I have prepared shortlist of propositions how in less than 60 minutes make your app more friendly for data analyst in the future.

Proper abstraction, basic events

Most of mobile analytics tools are able to track basic data almost automatically. In a few lines of code you will be able to capture installation, app launch events, screen views, crashes and probably even more. Whole implementation usually takes no more than 15 minutes so most of us choose this way as a first step. But in long term perspective it has some flaws:

It’s not easy to migrate this solution. And there will be many reasons to do this in the future: too big costs of current service, too limited list of features, new data wizard in company has his own toolset and many more.
Automatically tracked data is not enough. Sooner or later you will need to log more details what in most cases means explicit implementation.
External SDK is not testable. At some point in the future you will need to guarantee that key metrics are logged properly after every app release.

So how we could make it better?

Base implementation

At the beginning just make sure that your analytics tools are available “everywhere”. At the beginning you can simply inject them into your BaseActivity class:

Now every subclass will always require screen name (getScreenNameForAnalytics() method implementation). But in return you are sure that launch event for every new screen will be always logged, no matter of used tools.

And the basic implementation of AnalyticsTools. Do you really need to use automatic tracking when this code is so simple?

And that’s it. With just 100 lines of code in two files you are able to log: screen launches (automatically), button clicks and custom events (on demand).
Now when you decide to replace Mixpanel with Flurry or Google Analytics with your custom BigQuery implementation, you will just need a few amendments in source code. Logged data will remain the same. Oh, and If you know Dependency Injection concept you probably noticed that AnalyticsTools is fully testable with unit tests (you can inject fake GoogleAnalytics and make sure that tracked events are passed to there properly).

Next steps

It completely depends on you but I would recommend those:

DRY_RUN mode — even as simple boolean flag which makes sure that your data isn’t logged in analytics services (keep logging them in LogCat) when you build your app or test it.
Async tracking — most of analytics services are pretty good in using background threads but some of them still have problems with blocking initialisation. Even 200–500ms can be critical when tools are loaded during app launch. So instead of CustomAnalyticsSDK you can inject Observable<CustomAnalyticsSDK>. Why and what for? Check my blog post.

Buttons

Logging every button click manually isn’t the most convince way. Even with our implementation you always have to look for AnalyticsTools reference in your code. If you build your apps in MVP pattern you will probably end with call chain: presenter —- calls -—> activity —- calls -—> analytics tools.
Of course only if you won’t forget to add logging to each newly added button.

Can we automate it somehow? Maybe it’s not the most elegant way but you can always build your CustomButton:

It’s not as simple as BaseActivity, but it’s still less than 100 lines of code. Let’s see:

AnalyticsTools are injected to every instance of CustomButton (you can use Dagger 2 for this — check posts on this blog for more articles about it).
In this implementation there are two attributes which will be used in button click event: CustomButton_analyticsLabel and CustomButton_analyticsScreenName. First one is mandatory and if it’s not set, Line 33 will make sure that app will crash when you open it for the first time. The second one is overridden by current Activity screen name (our getScreenNameForAnalytics() method).
Event is logged whenever user clicks on button. Current implementation logs label and screen name so it’s easy to distinguish “OK” button on main screen and the one on user settings.

To use custom attributes we need to declare them in res/values/attrs.xml:

Now all you have to do is to add your CustomButton into activity.xml file:

Property app:analyticsLabel can be both: String or String reference (good practice is to create another file: res/values/analytics_labels.xml to not mix labels with real texts in our app).

Less logic, more data

Soon or later you will need to track custom events in your app (e.g. conversions like sign-up, buy, invite a friend). There is no single way to do this, so let me give you small advice. Stick to one rule: always try to log as simple events as possible without any logic behind. Instead of building custom rules around tracked events try to log a bit more data — logic will be added later, during analysis.

So whenever some comes to you asking for: custom_event_user_signed_up_from_usa just send: custom_event_user_signed_up with additional parameter: country=”usa” instead. Otherwise you will end up explaining what are exact conditions for every custom event which is sent from app. Almost every analytics tool is really good in filtering and segmentation so let’s move some responsibility out of you. 🙂

Privacy

The last hint is for your conscience. Data-driven development is really great approach because the goal is to make user more happy with your app. But keep in mind that there is thin border between analysing and spying. Also please remember that whenever you use external analytics services, you send users data to other companies. So please, make sure that you are not sharing too much of it and respect your customers privacy.
And yes, you can always analyse anonymised data. Apple calls it Differential Privacy.

Thanks for reading! 😊

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Hello world Google Home

Fri, 12 May 2017 00:00:00 +0000

Github Actions — building first agent for Google Assistant in Java

Some time ago I published unofficial Google Actions SDK written in Java. Source code and documentation can be found on Github: Google-Actions-Java-SDK. Library can be also downloaded from Bintray jCenter:

The goal for this project is to give Android/Java developers possibility to build solutions for Google Home without learning new language (official Actions SDK is written in Node.js).

Google Assistant Action from scratch

In this post we’ll go through Google Assistant agent implementation. We’ll build simple Github client which will tell us what is the one of the hottest repositories from last days.

Source code for final project can be found here: Github Google Actions

Environment configuration

Our Github Actions agent will be built in Java and hosted on App Engine.
At the beginning we need to create new project in Google Cloud Platform dashboard.
When it’s done remember your project ID, it will be needed during configuration. In example described in this post id is: *githubactions*.

Then we need to install CLIs for Google Cloud and Google Actions:

Project init

Now let’s create our Java/gradle project (I use IntelliJ IDEA, free community edition). For better code structure, I also created module app. Final structure looks like this (some files/tries aren’t show for better readability):

When it’s done, run $ gactions init from /app directory. It should create example config file: app/actions.json:

This config file defines our agent’s Actions. It’s mostly self-describing but in case you would like to know better what is happening here, please visit official documentation.

Now let’s update it with our configuration. We would like to have an agent which is able to handle two actions/intents:

assistant.intent.action.MAIN (defined in Google Actions SDK)
Action is launched when user starts talking, but without clear intention e.g.: “Ok Google, talk to Github”. In most cases this should be used as an agent introduction.
com.frogermcs.githubactions.intent.TRENDING (defined by us)
In response to this request, our agent will find one of the hottest repositories from last days. There are a couple utterances which should fire this intent:
“Ok Google, ask Github what are the hottest repositories”
“…trending repositories”
“…hot projects”
…
and others. List of queries is defined in actions.json. Here is final configuration for our agent:

###The code

Now let’s build service to handle requests from Google Assistant. We will build simple REST server, which handles POST requests (based on configuration above, both intent requests will be sent to https://githubactions.appspot.com/).

Project configuration

Our app requires a couple dependencies defined in app/build.gradle file:

App Engine SDK
Google Actions Java SDK (my unofficial library)
Google HTTP Client Library for Java — to make calls to Github API. Not a good news for Android devs familiar with Okhttp and Retrofit — because of App Engine restrictions in threading, it’s really hard to make it working here.
Dagger 2 — Dependency injection framework to make our code a bit cleaner and easy to extend.

Final gradle files (able to build, run and deploy our GAE code) can be found here:

Servlet

Now let’s build code for processing requests from Google Assistant. At this level, it’s nothing more than just proper configuration of Google Actions Java SDK:

Build response handler. This object will be used to pass final responses to Google Assistant. Nothing really interesting, it just meets communication requirements (headers, format) Final code: AppEngineResponseHandler.
Build request handlers. Those are responsible for handling particular requests (our MAIN and TRENDING intents). Request handlers should process incoming request and generate tell/ask/permission response. In our app we’ll have only tell responses: greeting (MAIN) and randomly picked hot repository (TRENDING). In the future we’ll build more complex solutions on top of ask and permission responses. Final code for MainRequestHandler and TrendingRequestHandler (take a look at returned variable from getResponse() methods — in both cases we use ResponseBuilder.tellResponse(…).
Intents mapped to proper request handlers:

All dependencies for Assistant Actions can be found in AssistantModule class.

Final servlet code should be similar to this:

Line 15 is the place where all magic happens:

1) POST request comes from Google Assistant. It is parsed to RootRequest object (lines: 18–20) and passed to assistantActions.

2) Based on defined intents map, assistantAction passes RootRequest object to MainRequestHandler or TrendingRequestHandler.

3) Picked request handler generates tell response: RootResponse.

4) Response is passed to AppEngineResponseHandler which sends it back to Google Assistant.

Servlet Configuration

At the end you need to add App Engine servlet configuration to your project (files: web.xml and appengine-web.xml):

Their content should be self-explaining:

Now our app is ready to deploy. If the configuration is correct, all you have to do is:

$ ./gradlew app:appengineDeploy

Testing Assistant Actions

Even if you don’t have Google Home device, it’s still possible to simulate you newly created Assistant Actions. To do this you can use Google Home Web Simulator. All you need to do is:

1) $ gactions preview -action_package=app/action.json -invocation_name=Github called from project’s root directory.

2) Sign-in and start: Web Simulator

More details can be found in official guide.

And that’s all! We’ve just built our very first preview version of Actions for Google Assistant. In future publications we’ll see how to extend its functionality.

Thanks for reading! 😊

Source code

Final source code of described project can be found on Github.

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Building Google Actions with Java

Wed, 25 Jan 2017 00:00:00 +0000

Voice interfaces are definitely the future of interaction between people and the technology. Even if they won’t replace mobile apps (at least in next years), for sure they extend their possibilities. It means that for many mobile programmers, assistants like Actions on Google or Amazon Alexa will be next platforms to build their solutions.

Google Actions SDK

Currently if we want to build app for Google Home or Google Assistant we have to use Node.js library. But under the hood, Assistant Platform uses JSON-formatted HTTP requests as a communication standard. It means that it’s relatively easy to build SDK in any other language.

And so I started building unofficial Google Actions Java SDK. If you are like me — an old-fashioned Android developer who builds in Java, there is a big chance that you have a lot of great code powering your apps which can be reused in Assistant Actions. And this was the main reason for this SDK — to enable as much developers as possible to write code for Assistant Platform.

About project

Since Google Actions Java SDK is on the proof-of-concept stage and still there is a lot of work to do (including documentation and tests), working implementation is all about:

Handling RootRequest objects (incoming requests from Google Assistant)
Preparing proper RootResponse objects and sending them back to Assistant.

The rest are just better code architecture/scalability and utils (e.g. ResponseBuilder and all others not yet written).

AppEngine ActionsServlet

As a working example we have simple AppEngine app written in Java which can be used as a replacement for Node.js server, and be easily deployed on Google Cloud. I won’t describe Servlet deployment process - it’s just a mix of these tutorials:

https://developers.google.com/actions/develop/sdk/#set_up_your_environment — GActions CLI
https://cloud.google.com/sdk/downloads — Google Cloud SDK
https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine/helloworld-new-plugins — Example Gradle config for AppEngine

Our servlet is pretty simple — when user starts interaction (app receives assistant.intent.action.MAIN intent after interpreting “Talk to hello action” utterance), Assistant should ask him/her to tell something. Then next utterance (intent: assistant.intent.action.TEXT) is echoed by Assistant. And conversation is over.

From code perspective here is the whole flow:

1) ActionsServlet receives POST JSON-formatted request, which is parsed to RootRequest object.

2) Thanks to intents mapping, RequestHandler passes RootRequest to MainRequestHandler.

3) Ask response is generated and passed to ResponseHandler which sends response to Assistant.

4) 1–3 steps are repeated for next utterance which then is echoed to user.

Here you can see output from Web Simulator which additionally can shows the whole debug output for communication between Assistant and our Servlet.

Next steps

Presented example is very simple yet powerful. If you already have any rest client implemented in your Android app (e.g. Github API client) you can put this code to our example Servlet and give user possibility to access this informations via voice interface. As mentioned at the beginning — all you have to do is proper handling for RootResponse and RootRequest.

At the end I highly encourage you to contribute in Google Actions Java SDK development. Let’s enable as many developers as possible to build their brilliant ideas for Google Assistant and Home!

Thanks for reading!

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

FrameMetrics — realtime app smoothness tracking

Sat, 19 Nov 2016 00:00:00 +0000

A couple months ago, when Android Nougat was announced, among new features like Multi-window, enhanced notifications, VR support, 72 new emojis 👍 and others, there was a new addition to monitoring tools: Frame Metrics API.

On older Android versions when we would like to see graphic performance metrics we had to get them via adb shell, by calling:

$ adb shell dumpsys gfxinfo com.frogermcs.framemetrics

As a result we get:

These statistics are generated for last 120 frames for given application package (hint: this is not always last 2 seconds - frames are drawn only when Android is requested to do this e.g. when layout is changed or animated).

While this data can give us a lot of information about UI performance, accessing it from console isn’t the most convenient way, especially when we would like to use it during automatic app testing. Of course it isn’t impossible, and great example how it can be done is described in Automated Performance Testing Codelab (it’s implemented as a MonkeyRunner script).

FrameMetrics

Starting from Android SDK 24, we can have access to these informations directly from application code. There is no limit to the past 120 frames, because frame timing info for current app window is captured in realtime. Having direct access to this data means also that we are able to measure production app to know how it works on users’ devices.

FrameMetrics API documentation is pretty clear about what can be measured (chronologic order):

Metrics names are mostly self explaining but if this list looks not complete to you, take a look at FrameMetrics sources to see how each metric is calculated:

There are also great videos where Colt McAnlis explains among the others what VSYNC is or how layout is transformed to GPU commands (FrameMetrics.COMMAND_ISSUE_DURATION). So they also can shed some light on FrameMetrics fields:

Some FrameMetrics fields can be demystified by @duhroach videos: Rendering Performance on #AndroidDev https://t.co/LG3BUDK4Fs #PerfMatters
— Miroslaw Stanek (@froger_mcs) November 13, 2016

ActivityFrameMetrics

To make FrameMetrics even easier to use I created simple library called ActivityFrameMetrics. It is small 1-class library which prints janky frames warnings to Logcat:

Installation is pretty simple — you can copy ActivityFrameMetrics.java class to your project or use gradle dependency:

To use it, just register ActivityFrameMetrics as an ActivityLifecycleCallback in your Application class:

By default library prints Logcat warning for every frame which rendering took more than 17ms, and error for more than 34ms.

Default values can be changed with ActivityFrameMetrics.Builder params:

Repo for ActivityFrameMetrics library can be found on Github.

Digging deeper into FrameMetrics

If it’s still not enough and you are still curious how FrameMetrics works under the hood here are a couple hints where you could start searching.

First of all FrameMetrics is just a simple data container written in java but nothing really is measured in it. Instead this data comes as a notification from C++ code which is responsible for view rendering. Good starting point could be ThreadedRenderer class which proxies rendering to render thread. If you explore C++ code a bit more, at the end probably you’ll find JankTracker class which is responsible for filling up FrameMetrics data (and you will realise that this is exactly the same data which is presented in dumpsys gfxinfo) and FrameInfo class which is C++ data container which is in sync with FrameMetrics.java.

What else you can find there is only up to you. Just never stop searching and always be curious.

Thanks for reading!

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Activities Subcomponents Multibinding in Dagger 2

Tue, 18 Oct 2016 00:00:00 +0000

A couple months ago, during MCE³ conference, Gregory Kick in his presentation showed a new concept of providing Subcomponents (e.g. to Activities). New approach should give us a way to create ActivitySubcomponent without having AppComponent object reference (which used to be a factory for Activities Subcomponents). To make it real we had to wait for a new release of Dagger: version 2.7.

The problem

Before Dagger 2.7, to create Subcomponent (e.g. MainActivityComponent which is Subcomponent of AppComponent) we had to declare its factory in parent Component:

Thanks to this declaration Dagger knows that MainActivityComponent has access to dependencies from AppComponent.

Having this, injection in MainActivity looks similar to:

The problems with this code are:

Activity depends on AppComponent (returned by ((MyApplication) getApplication()).getComponent()) — whenever we want to create Subcomponent, we need to have access to parent Component object.
AppComponent has to have declared factories for all Subcomponents (or their builders), e.g.: MainActivityComponent plus(MainActivityComponent.ModuleImpl module);.

Modules.subcomponents

Starting from Dagger 2.7 we have new way to declare parents of Subcomponents. @Module annotation has optional subcomponents field which gets list of Subcomponents classes, which should be children of the Component in which this module is installed.

Example:

ActivityBindingModule is installed in AppComponent. It means that both: MainActivityComponent and SecondActivityComponent are Subcomponents of AppComponent.
Subcomponents declared in this way don’t have to be declared explicitly in AppComponent (like was done in first code listing in this post).

Activities Multibinding

Let’s see how we could use Modules.subcomponents to build Activities Multibinding and get rid of AppComponent object passed to Activity (it’s also explained at the end of this presentation). I’ll go only through the most important pieces in code. Whole implementation is available on Github: Dagger2Recipes-ActivitiesMultibinding.

Our app contains two simple screens: MainActivity and SecondActivity. We want to be able to provide Subcomponents to both of them without passing AppComponent object.

Let’s start from building a base interface for all Activity Components builders:

Example Subcomponent: MainActivityComponent could look like this:

Now we would like to have Map of Subcomponents builders to be able to get intended builder for each Activity class. Let’s use Multibinding feature for this:

ActivityBindingModule is installed in AppComponent. Like it was explained, thanks to this MainActivityComponent and SecondActivityComponent will be Subcomponent of AppComponent.

Now we can inject Map of Subcomponents builder (e.g. to MyApplication class):

To have additional abstraction we created HasActivitySubcomponentBuilders interface (because Map of builders doesn’t have to be injected into Application class):

And the final implementation of injection in Activity class:

It’s pretty similar to our very first implementation, but as mentioned, the most important thing is that we don’t pass ActivityComponent object to our Activities anymore.

Example of use case — instrumentation tests mocking

Besides loose coupling and fixed circular dependency (Activity <-> Application) which not always is a big issue, especially in smaller projects/teams, let’s consider the real use case where our implementation could be helpful — mocking dependencies in instrumentation testing.

Currently one of the most known way of mocking dependencies in Android Instrumentation Tests is by using DaggerMock (Github project link). While DaggerMock is powerful tool, it’s pretty hard to understand how it works under the hood. Among the others there is some reflection code which isn’t easy to trace.

Building Subcomponent directly in Activity, without accessing AppComponent class gives us a way to test every single Activity decoupled from the rest of our app.
Sounds cool, now take a look at code.

Application class used in our instrumentation tests:

Method putActivityComponentBuilder() gives us a way to replace implementation of ActivityComponentBuilder for given Activity class.

Now take a look at our example Espresso Instrumentation Test:

Step by step:

We provide Mock of MainActivityComponent.Builder and all dependencies which have to be mocked (just Utils in this case). Our mocked Builder returns custom implementation of MainActivityComponent which injects MainActivityPresenter (with mocked Utils object in it).
Then our MainActivityComponent.Builder replaces the original Builder injected in MyApplication (line 28): app.putActivityComponentBuilder(builder, MainActivity.class);
Finally test — we mock Utils.getHardcodedText() method. Injection process happens when Activity is created (line 36): activityRule.launchActivity(new Intent()); and at the and we’re just checking the results with Espresso.

And that’s all. As you can see almost everything happens in MainActivityUITest class and the code is pretty simple and understandable.

Source code

If you would like to test the implementation on your own, source code with working example showing how to create Activities Multibinding and mock dependencies in Instrumentation Tests is available on Github: Dagger2Recipes-ActivitiesMultibinding.

Thanks for reading!

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Building UserScope with Dagger2

Sun, 14 Aug 2016 00:00:00 +0000

Custom scopes in Dagger 2 can give better control on dependencies which should live unusual amount of time (different than application and screen lifetime). But to implement it properly in Android app we need to keep in mind a couple things like: scope cannot live longer than application process, process can be killed by system and restored in the middle of user flow with new objects instances and more. Today we’ll go through all of them and try to implement production ready UserScope.

In one of my blog posts about Dagger 2 I wrote about building custom scopes and Subcomponents. As an example I used UserScope which should live as long as user is logged in. Example of scopes lifetime:

While it looks pretty simple, its implementation showed in that post was far away from code which can be production ready. That’s why I’d like to go through this subject again — but more in implementation context.

Example app

We’ll build 3-screens application which will be able to get user details from Github API (let’s assume that this would be authentication event in production app).

App will have 3 scopes:

Application scope

(@Singleton) — dependencies which live as long as application.
@UserScope — dependencies which live as long as user session is active (during single application launch). Important: this scope won’t live longer than application itself. Each new app instance will create new @UserScope (even if user session was not finished between app launches).
@ActivityScope — dependencies which live as long as Activity screen.

How it works?

When app gets data from Github API for given username, new screen is opened (UserDetails). Under the hood LoginActivityPresenter asks UserManager to start session (get data from Github API). When operation succeeds, user is saved to UserDataStore and UserManager creates UserComponent.

UserManager is a singleton object so it lives as long as Application and is responsible for UserComponent which reference is kept as long as user session exists. When user decides to close session, component is removed so all objects which are @UserScope annotated should be ready for GC.

Components hierarchy

In our app all subcomponents use AppComponent as a root component. Subcomponents for screens which show user related content use UserComponent which keeps @UserScope annotated objects (one instance per user session).

Example component hierarchy for UserDetailsActivityComponent can look like this:

For UserComponent we use Subcomponent builder pattern to make our code cleaner and have possibility to inject this builder to UserModule (UserComponent.Builder is used to create component UserModule.startUserSession method showed above).

Restoring UserScope between app launches

As I mentioned earlier UserScope cannot live longer that application process. So if we assume that user session can be stored between app launches, we need to handle state restoring operation for our UserScope. And there are two scenarios which we need to keep in mind:

User launches app from scratch

This is the most common case which should be pretty straightforward to handle. User launches app from scratch (e.g. by clicking on app icon). Application object is created and then first Activity (LAUNCHER) is started. We need to provide simple logic checking if we have any saved user in our data store. If yes user is forwarded to proper screen (UserDetailsActivity in our case) where UserComponent is automatically created.

Application process was killed by the system

But there is also a case which we very often forget about. Application process can be killed by the system (e.g. because of low memory). It means that all application data is destroyed (application, activities, static fields). Unfortunately this cannot be handled nicely — we don’t have any callbacks in Application lifecycle. To complicate it even more, Android saves activities stack. What means that when user decides to launch app which was killed somewhere in the middle of flow, system will try to bring user back to this screen.

For us it means that we need to be ready to restore UserComponent from any screen in which it’s used.

Let’s consider this example:

User minimised app on UserDetailsActivity screen
Whole app is killed by the system (later I will show how to simulate it)
User opens Task Switcher, clicks on our app screen.
System creates new instance of Application. What means that also new AppComponent is created. And then instead of opening LoginActivity (which is our launcher activity) system opens UserDetailsActivity immediately.

For us it means that UserComponent has to be brought back (new instance has to be created). And this is our responsibility. Example solution to do this can look like this:

Each Activity which use UserComponent has to extend our BaseUserActivity class (setupActivityComponent() method is called in onCreate() method in BaseActivity).

UserManager is injected from AppComponent which was created with Application. Session is started in this way:

What if user doesn’t exist anymore?

So there is another case to handle — what if user was logged out (e.g. by SyncAdapter) and UserComponent cannot be created? That’s why we have those lines in our BaseUserActivity:

But if there is a chance that UserComponent cannot be created we have to remember that dependency injection won’t happen. That’s why we need to check it every time in onCreate() method to prevent from NullPointerExceptions on injected dependencies.

How to simulate application process kill by system

Open app on screen which you would like to test
Minimize app with system Home button.
In Android Studio, Android Monitor select your application and click Terminate
Now on your device open Task Switcher, find your app (you still should see preview of last visible screen).
Your app was launched, new Application instance was created and Activity was restored.

Source code

Source code with working example showing how to create and use UserComponent is available on Github: Dagger2 recipes — UserScope.

Thanks for reading!

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Inject everything - ViewHolder and Dagger 2 (with Multibinding and AutoFactory example)

Sun, 12 Jun 2016 00:00:00 +0000

The main purpose of Dependency Injection pattern which is implemented by Dagger 2 is that DI separates the creation of a client’s dependencies from the client’s behavior. In practice it means that all calls of new operator, newInstance() and others shouldn’t be invoked in places other than Dagger’s Modules.

The price of Dagger-everything

The purpose of this post is to show what we can do, not what we should do. That’s why it’s important to know what we give in return for separating creation from behavior. If you want to use Dagger 2 for almost everything in your project you will quickly see that big piece of 64k methods count limit is used by generated code for injections.

Inject everything example

Probably the best known code example of Dagger 2 shows how to inject simple object (e.g. Presenter) to Activity and looks similar to this:

When we start extending this code (let’s say we work on Activity which shows list of items) sometimes we take a shortcuts. It means that we don’t always @Inject new objects (like adapter in this case):

And with this approach we act against DI and profits given by it. Calling Adapter constructor inside Activity class means that every time when we need to change something in its implementation (new constructor argument, maybe completely new implementation which shows grid instead of list), we have to update Activity code.

Sometimes taking a shortcut like this is intended (we know that this code won’t be extended more in the future). But today we’ll try to make all adapter related code a part of dependency injection approach. As an example we’ll extend our GithubClient app - its screen which shows list of repositories for given username.

To make it more complex and closer to real apps our Adapter will have three different view types: normal, extended and featured.

The beginning

Here you can see starting code base for our example. For me this is how the first iteration of implemented Adapter looks like in most cases.

RepositoriesListActivity

RepositoriesListAdapter

Adapter injection

At the beginning we’ll inject our adapter object instead of calling its constructor in Activity class:

RepositoriesListActivity

To make this possible we have to initialize RepositoriesListAdapter object in our Activity Module:

Pretty straightforward. Now let’s do some refactoring of our RepositoriesListAdapter class. Inner static classes for ViewHolders should be moved out of Adapter code:

To do it fast in Android Studio just put cursor on class name and click F6 (Move Inner to Upper Level)

Assisted injection, Auto-factory

In the next step of our refactoring process we would like to move out construction process from onCreateViewHolder() method:

It’s not as straightforward as in previous example. As you can see our ViewHolders have mandatory argument which is View object (RecyclerView.ViewHolder class has only one constructor: public ViewHolder(View itemView)). It means that every time when we want to create new object, we need to provide view (which is created during runtime so we cannot configure this in advance in Module classes).

This problem is known as an Assisted Injection and was wider described on StackOverflow and Dagger Discuss group.

Final solution (until there is no official way of doing this in Dagger 2 framework) is to inject Factory object which takes those dependencies as an arguments and creates intended object. In mentioned StackOverflow thread you can see how to do this by hand, but also Google provides us a solution to generate those factories automatically.
AutoFactory generates factories that can be used on their own or with JSR-330-compatible dependency injectors from a simple annotation. To use it in our project we have to add new dependency in build.gradle file:

Now all we have to do is to annotate classes for which we would like to create factories:

Arguments of @AutoFactory annotation can make our Factory class extending given class or implementing given interface. In our case it will be:

After this update Adapter’s onCreateViewHolder() method looks like this:

Now our code is a bit cleaner but still we call constructors inside it.

Multibinding

Final step in our refactoring is to initialize our Factory objects in Module class to get rid of constructors calls in Adapter class. We can simply inject them as a RepositoriesListAdapter constructor parameters. But it would mean that every time when we decide to add/remove new type of ViewHolder we still would need to update Adapter code by hand.

Instead we can make use from Multibinding. Thanks to this feature Dagger allows us to bind several objects into a collection (even when the objects are bound in different modules).
Our ViewHolder factories have one thing in common: interface RepositoriesListViewHolderFactory. It means that we can inject map of Integers (type of Repository object is represented as a static final int) and RepositoriesListViewHolderFactory:

And here you can see how our map is created:

@IntoMap annotation makes those objects a part of map and puts them under keys given in @IntKey (here you can find more annotations for different types of keys):

Finally, after all of those code improvements onCreateViewHolder() method is as simple as possible:

No constructors, no if-else statements. Everything is done by proper Dagger graph configuration.

And that’s all - our adapter and its ViewHolders are now a part of Dagger 2 graph. We are another step closer to inject everything in our code. With AutoFactory and Multibinding it will be much simpler.

Thank you for reading! 🙂

Complete source code

Here you can find source code of described classes after refactoring:

Full source code of described project GithubClient is available on Github repository.

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

Async Injection in Dagger 2 with RxJava

Sat, 16 Apr 2016 00:00:00 +0000

A couple weeks ago I wrote a post about asynchronous dependency injection in Dagger 2 with Producers. Objects initialization execution on background thread(s) has one great advantage - it doesn’t block main thread which is responsible for drawing UI in real-time (60 frames per second for keeping smooth interface).

It’s worth pointing out, that slow initialization in not everyone’s issue. But even if you really care about it in your code there is always a chance that any external library does disc/network operations in constructor or any init() method. If you are not sure about it I suggest you to give a try AndroidDevMetrics - my performance metrics library for Android. It can tell you how much time was needed to show particular screens in app and (if you use Dagger 2) how much time was consumed to provide each object in you dependencies graph.

Unfortunately Producers are not designed for Android and have a couple flaws:

Use Guava as a dependency (can cause 64k methods issue and increase build time)
Aren’t extremely fast (injection mechanisms can block main thread for a few to dozens of milliseconds depending on device)
Don’t use @Inject annotation (a little more mess in code)

While we cannot do much with last two, the first one can compromise Producers in Android projects.

Async injection with RxJava

Fortunately a lot of Android devs use RxJava (and RxAndroid) for creating asynchronous code in our apps. Let’s try to use it in Dagger 2 asynchronous injection.

Async @Singleton injection

Here is our heavy object:

Now let’s create additional provide...() method which returns Observable<HeavyExternalLibrary> object, which will call this code asynchronously:

Let’s analyze it line by line:

@Singleton - it’s important to keep in mind that it will be single instance of Observable object, not HeavyExternalLibrary. Singleton also prevents from creating additional Observable object.
@Provides - because this method is also a part of @Module annotated class. Do you remember Dagger 2 API 😉?
Lazy<HeavyExternalLibrary> heavyExternalLibraryLazy object prevents from initializing HeavyExternalLibrary object internally by Dagger (otherwise in a moment of calling provideHeavyExternalLibraryObservable() object would be already created).
Observable.create(...) code - it will return heavyExternalLibrary object by calling heavyExternalLibraryLazy.get() everytime when this Observable will be subscribed.
.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread()); - by default RxJava code is executed on a thread in which Observable is created. That’s why we should move execution to background thread (Schedulers.io() in this case) and just watch for the results on main thread (AndroidSchedulers.mainThread()).

Our Observable is injected like any other object in graph. But object heavyExternalLibrary itself will be available a bit later:

Async new instance injection

Code above presented how to inject singleton objects. What if we want to inject asynchronously new instances?

Make sure that our object is not @Singleton annotated anymore:

Also our Observable<HeavyExternalLibrary> provider method should be changed a bit. We cannot use Lazy<HeavyExternalLibrary> because it creates new instance only for the first time when get() method is called (see Lazy documentation for more details).

Here is the updated code:

Our Observable<HeavyExternalLibrary> can be a singleton but everytime when we call subscribe() on it, we will get new instance of HeavyExternalLibraryin onNext() call:

Complete async injection

There is another way to do asynchronous injection in Dagger 2 with RxJava. We can just simply wrap whole injection process with Observable.

Let’s say our injection is performed in this way (code is taken from GithubClient example project):

To make it asynchronous we just need to wrap setupActivityComponent() method with Observable:

As it’s explained, all @Inject annotated objects will be injected in some time in the future. In return injection process will be asynchronous and won’t have big impact on main thread.

Of course creating Observable objects and additional threads for subscribeOn() is not completely free - it will also take some time. It’s pretty similar to impact generated by Producers code.

Thanks for reading!

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer

AndroidDevMetrics - Activity lifecycle methods tracing

Tue, 22 Mar 2016 00:00:00 +0000

AndroidDevMetrics is a performance metrics library which will help you find potential performance issues in your Android app. Thanks to it we are able to measure objects graph initialization in Dagger 2, Activities lifecycle methods timings and frame drops for each screen in app.

Since today another new feature comes to light. Without any additions in app’s source code AndroidDevMetrics lets us profile Activity lifecycle calls (onCreate(), onStart(), onResume()) with method tracing.

Methods tracing

Android itself gives us possibility to trace methods execution stack. Thanks to this we are able to get know how much time was needed to run each method (exclusively and inclusively - with all methods called inside this particular method).

We have two ways to start profiling:

Easier, less accurate directly form Android Studio. Accessed via Android Monitor tab -> CPU -> Start/Stop Method Tracing can be started and stopped by hand. Immediately after that Traceview debugger is opened with collected data. While this way is probably the easiest, in most cases it’s hard to hit start/stop in a moment which we want to measure.
A bit more complex but extremely accurate - profiling directly from source code. Android SDK provides us Debug class which has two methods: startMethodTracing() and stopMethodTracing(). Wrapping our code with them will give us very clear results. Trace file is saved in device’s storage so we can get it by calling $ adb pull {file_path}.trace. To see this file you have to just drag it to Android Studio. If you have used this method before, probably you know that there is one big disadvantage of Debug.startMethodTracing() - our code has to be recompiled and pushed to our device every time when we want to debug something new. So in more complex projects it takes ages (tens of seconds or minutes…)

With a newest version of AndroidDevMetrics (v0.4) you can schedule method tracing for Activity lifecycle methods: onCreate(), onStart(), onStop().

Profilling will take a place in the next Activity launch. You can even kill your app and open it again. In this case you will make sure that profiled Activities are created from a scratch.

What next ? If everything will be ok you should see Dialog telling you how to grab generated .tracef files from your device. And then all you have to do is just to drag those files to Android Studio to see them.

TraceView

How it works in practice? Let’s assume that in our Activity we have this piece of code:

As you can see, in onResume() app calls two methods. The 2nd one simulate any heavy operation which takes 500ms. Let’s profile it with AndroidDevMetrics:

Here you can see how TraceView looks like for capture file: SplashActivityonResume.trace

We can see clearly that most of the time is taken by SplashActivity.callHeavyMethod(). It takes about 500ms inclusive time (why only 32µs of exclusive time? Because most of it is taken by Thread.sleep() called inside this method).

Simple, right? I hope that thanks to this update we will save a lot of time which we would spend on recompiling the app code. 🙂 Now it’s your turn - let’s give a chance to AndroidDevMetrics. I would really appreciate your feedback!

Thank you for reading.

Source code

Full source code of AndroidDevMetrics project is available on Github repository.

Getting started with AndroidDevMetrics

Script below shows how to enable all available metrics.

In your build.gradle:

In your Application class:

Author

Miroslaw Stanek
Head of Mobile Development @ Azimo Money Transfer