The Brickx mobile WMS project is quite big. There are a lot of features that need to be implemented and my educated guess tells me that I will likely not be able to finish implementing all of those features within the span of my internship.

Instead I should focus on laying out a strong foundation for the rest of the app to be built upon. The first thing required for that is to choose an architecture for the project.

Before this I had used a very simple and conventional way to make an Android app. All of the code would be put in the activity and some sub-classes. That includes all the logic, networking and threading. This is one of the fastest ways to quickly implement a new screen however it is also short sighted as code will quickly become near impossible to read and maintain.

Last semester I used a new architecture I hadn't seen before. That architecture is called MVP (Model, View, Presenter). This architecture splits the activity code into a view that handles all the UI related tasks. A presenter that handles all out/incoming communication and logic. Lastly a package with models is made. Interfaces are also used to link presenters and views together.

This allowed me to keep a clear structure in my code while maintaining the possibility of a large code base.

Furthermore I need to sync up data and instances between activities. Rather than passing the view over every time and risking security I will instead use Dagger2 to inject the context and parts of other modules into any presenter. This took me a while to figure but in the end the result is robust and clean, needing only one line of code to link up a data getter or the context into activities and presenters.

Speaking of data getters, I need an asynchronous way of getting data from the API. After some digger I found out that I could simply use an AsyncTask but I don't want to deal with all the extra work needed to manage the threads so I looked a bit further and found out about RetroFit. This plugin basically does all the work required for an asynchronous task on its own and I only need to write a couple lines of code to use it. Nice.

Great, now that I've determined a base structure and how I want to link individual parts of it together, it's time to think about data. Normally you could just add any data getters for API's or databases in the presenter but then it would be harder to change out the data getters at a later stage. Instead we will be making two more modules. A domain module and a data module. The data module will handle all the data transmissions between the program, the API and the databases while the domain module will serve as an interface between the data and the presentation layer.

Separating the project in there three layers will further improve maintainability and future expansion capabilities.