This post will focus on establishing an overview of our architecture, paying particular attention to the external libraries we use. In future posts we will dive into greater detail on several of the libraries and concepts, which are just briefly introduced here. Let’s get started!
We store data encrypted locally to create an even smoother and seamless experience for our users.
To achieve this we decided to use Realm as a local database. Realm is a powerful object database that’s very simple to use. It removes a lot of the overhead associated with Androids SQLite, which is definitely worth it.
Realm recently launched a Cloud solution that we’ve also been looking into. However, we decided to roll out our own sync model using websockets, but still based on Realm on phones.
We are still not finished with this transition, so more on this subject at a later date.
Many experienced Android developers know what a pain handling images over the network was back in the early days.😱
Thankfully, projects like Glide, which we use in our app, have made this a thing of the past. Just like Retrofit makes network calls feel like a breeze, Glide takes care of all the heavy lifting with memory management and performance when it comes to loading images.
An app can be Orchestrated in a thousand different ways. We opted for Flux, which is an architectural pattern used by Facebook that also works quite well for app’s.
Flux meets our particular requirements and strikes the right balance between decoupling the app, while remaining simple and not overly convoluted. It’s a simple concept using one-way events that fit perfectly with network heavy apps.
Rx makes orchestrating events a lot easier and therefore ties-in perfectly with Flux. There is support for Rx in both Retrofit and Realm, which is an added bonus.
Dagger2 and the use of dependency injection is a enormous topic, which I will not cover here.
We use it primarily to have self contained components, which we can then use for the different builds we make. This makes it possible to create a test version with totally different UI components for testing, without them ever slipping into an app release.
For example, we have a “debug” sliding menu that gets injected into all of our test builds. This menu offers a ton of different possibilities, from changing endpoints and users, to toggling features dynamically, or even diving into the local database, plus much more. This is an invaluable tool during development and testing, but not something we would like to have in the final release version of our app. Dagger2 makes this separation easy.
This was a brief tour around different aspects of the Lunar Way Android app, focusing on the libraries we use. Check back later for a more in depth look into some of the specific aspects above.
We’ve experienced plenty of headaches and made interesting discoveries we’d love to share with you guys.