Android App Dev "structure"

SOURCE UNKNOWN:

OK, so the way we usually do any sort of app development, is to have a dedicated server, which would expose a RESTful API to the app (could be GraphQL too, but REST is just a bit simpler for some quick projects).

Your app would access the database, authentication and any sort of processing through API endpoints, optionally with some queries. This is the "proper" approach, especially when REST is replaced by the GraphQL. However, again, GraphQL requires a bit of extra work to get it down right.

Now, a mobile/frontend developer usually doesn't have time to develop app + backend (this is also true for teams of developers), so we need a solution that provides the backend for us.

So far the best such service is Firebase. I've used it on countless occasions, this thing provides everything you need. It's good enough to kickstart the development. If you need additional functionalities later, you will begin working on your own backend.

We will use Firebase for authentication and database.

Because applications need to work offline as well (although Firebase does keep a local cache of some sort), we need some way to temporarily store the data from the remote API to our device for offline access. Let's say your user turns on the device while being offline: are you gonna display him what, an empty app?

On Android, such database is SQLite. There are two ways of using it: (1) hardcode SQL queries or (2) use Room library for abstraction.

We will use Room, because it simplifies CRUD operation with annotations. You can still write SQL queries, but Room makes sure everything works fine, instead of letting the developer handle SQLite. From personal experience, you **only** use Room.

This brings us to app architecture. Google is pushing Kotlin-first development, so majority of "new" features work best with Kotlin, not Java. Because we will be working on not-so-complex project, we can allow ourselves a combination of Java and Kotlin (I'll handle Kotlin for now).

Architectural patterns commonly used are MVC, MVP, MVVM or MVI. We will use MVVM.

MVVM (Model-View-ViewModel) is a pattern pushed forward by Google, and libraries such as Room actually expect you to use MVVM. Other Android Jetpack libraries are also MVVM-tailored. Some extra: Android Compose is apparently the new "top shit" thing, so we might consider using it once you get the Kotlin code down.

MVVM works best with the repository pattern. Basically, what that means is the following: your repository is the so-called **single source of truth** of data for your app: it provides data from remote and local data sources to ViewModels, which updates the View. This means that we're relying on observer pattern: someone needs to observe changes in the repository and send updates to View.

For this we use LiveData or write custom implementation in RxJava/RxKotlin. We will rely on LiveData, because it survives lifecycle changes of activities/fragment (let's say the user rotates the screen, or exists the app suddently, or maybe runs out of battery/internet connection..).

Now, this means that there might be multiple ViewModels connected to the same repository, and there might be a View using multiple ViewModels... This thing is a goddamn mess.

Now this is where dependency injection (DI) comes into place. With dependency injection you delegate the responsibility of creating objects "to someone else", in this case, to the DI framework. This way you make sure that a given View has no insight into the operation of a particular ViewModel, because this ViewModel was created by the DI framework.

On Android, the "big player" of DI frameworks is Dagger, but it's kinda bloated for what we need, so we will use Koin. Now Koin is lightweight, but it's made for Kotlin. We will get to it once the app is finished. So don't worry about it yet, I'm just mentioning the whole thing for the future.