Building for scale at d.light Solar, our Android Journey [Part 1]

Building for scale at d.light Solar, our Android Journey [Part 1]

Seven months ago, I joined d.light Solar to join the Platform Team, to specifically work on our Android Apps. They had a vision to go head on on Mobile Solutions, and Android was the favourite.

d.light has sold over 20 million solar lamps improving the lives of over 95 million people in over 65 countries, and the business wanted to build various mobile solutions to help them scale even more.

The challenge was building 6 different apps, each with different requirements, and varying across 35 markets. As the mobile team, this meant us building 6 apps as part of our version 4, dubbed Atlas, in around 8-12 months.

Whaaaat! This is ridiculous…

Like most Android Apps developers, the idea was to build these apps as 6 different apps, but this meant we had to build common modules many times in the process, not forgetting common things like tests and deployments setup.

So I had to think of a better and simpler option, like building all these features as one monolith app. But this would mean having one bulky APK, which would not be favourable especially during updates. I had to look for a better engineering solution to our problem.

Introducing App Modularization

In Google I/O 2018, Android App Bundles (aab) were introduced. One of the benefits was dynamic delivery, automatic multi-APK distribution, smaller APK size and dynamic feature modules. This opened way to modularization on Android Apps, and this looked like our solution. Building the 6 apps as dynamic modules , but how?👀

The solution was to leverage Dynamic App Modules, to only build one APK, with each of the 6 apps built in as a feature module inside it, and called it Atlas. So lets explore app modularization and what it meant for us at d.light

Modular programming is a software design technique to separate functionality into independent, interchangeable modules, so that each contains everything necessary to execute a specific functionality.

For us, this was easy. Each of the 6 apps had it’s own specific functional requirements, and we used these as different modules for the app.

What language and why?

The next big question was which language to use, good old Java or the new shinny Kotlin. The answer was simple, Kotlin.

Kotlin is more modern, and offers a lot of new features which include lambdas, extension functions, less boilerplate code, more conscience and is more safe than Java. Coroutines also mean we can write asynchronous code. Aside from this, Google made it a first class language in Android development!

Application Architecture

The app will primary use the MVVM Architecture, which is the Model-View-View-Model. This is one of the most efficient architectures in Android development. It provides loose coupling of the components, and offer two important components, the View Model and LiveData.

  • The ViewModel holds the data across lifecycle changes, improving the app performance greatly
  • The LiveData provides a reactive way of getting data from the database, without user initiated refreshes.

The app also leverages Data Binding a lot, so data is binded to the UI at the layout level. The advantage is with new changes, we only change the layout and the data source, without any other change on the app code. This results in faster development time.

Communication

With the current number of modules, and the growing needs of the business, I had to think of an efficient way to handle communication between existing modules and the new modules we had to build in the near future, the result an event driven communication style.

By leveraging the event-driven architecture, communication between modules becomes easy, and more decoupled, resulting in better, cleaner and more testable code. The preferred option was Eventbus, due do to its robust nature and simplicity

Conclusion

Most of this was inspired by Plaid, which is a very nice starting point and offered a lot of reference points for me. This first part was mainly introducing the technologies, just to give an overall overview about the problem and the technologies I picked to tackle them. In the next part, I will deep dive into Android Modularization, and how we leverage it to build at d.light.

Remember to share and leave comments 🙂

Happy Coding!

8 Replies to “Building for scale at d.light Solar, our Android Journey [Part 1]”

  1. Great article Juma. Just a quick question how can I view the applications?
    Thanks for your response in advance.

    1. Hi Tonny,

      In the next articles, I will be building a demo app, to show what we are building since I cannot share internal company code on my personal blog.

      Make sure you are subscribed 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.