OLOlogn·Jun 12, 2020
> I am learning to build apps in android. Most of the tutorials and even books I come across have quite small examples to follow, usually 2 activity files
Two activity files? That's a lot. With Jetpack Navigation, you can have substantial real world apps using one Activity.
I have programmed Android apps professionally for a number of years, from substantial, as you describe it, apps for Fortune 100 companies, to smaller apps for much smaller companies.
There are two things to consider looking for examples - one, is you want an app using modern Android architecture. That it is using coroutines would be one of the main markers of this. Also it would probably be using Navigation, View Models, and Live Data. It would be written in Kotlin, of course. The architecture being MVVM, or possibly Clean Architecture with use cases. Possibly u
Read the rest
sing Dagger for dependency injection.
You might find some older substantial, real world apps using architecture and design patterns, but they might be ones not used much any more - maybe an app written in Java that made direct non-Room access to SQLite to get and retrieve local state (or, forbid, Shared Preferences), maybe Volley to access a web API, Asynctasks to do background work, Loaders to load data - none of this is current best practice, and much of it is deprecated.
If I had the choice of a model to be a small, modern example app, or a several years old out-of-date substantial, real world app, I would choose the basis to be the smaller, more modern app.
Google has some example apps. I think this is a decent one - https://github.com/android/architecture-samples
Both the main branch, and the slightly more out of date dagger branch.
This has all the architecture you need for a bit. The main thing it is lacking is network access, but you can learn that from other Google example apps.
What is architecture in an Android app? It can be thought of as a few things. One is just a clear line from the ultimate authority of state (say a web API) to the I/O of a screen. You tap a view, it goes to a fragment, under the management of an activity and navigation - and the fragment sends data to a ViewModel, which sends data to a repository, which sends that data to a remote data source. There might be a response which filters the other way. So a clear separation of UI and state model, and a clear line of transmission between them.
Another way to look at Android architecture is in the clean sense. You have a model for state which does not change much - organization-wide (like enterprise-wide business) data models and rules which are the same across the organization. These do not change much, and have no dependencies on classes apt to change. Dependent on these organization-wide, system-wide shared data models are data models that are specific to your particular app - application specific data models and rules. Dependent on these application specific rules/models are interface adapters like presenters (or view models, or repositories). Then dependent on these interface adapters would be the UI, web API and DB layer - the framework layer.
In both of these, architecture is the protection of the platonic ideal of the critical data structures used from the flittering volatility of the input and output of UI. In the case of clean architecture, it is protection from the specific framework dependencies needed to store and retrieve data model state as well.
In terms of design patterns, you make use of them in Android when needed - from singletons ("objects" in Kotlin), to adapters (particularly for RecyclerViews and such), to observers (used for Live data).
In terms of large and substantial apps, once you break out into different teams working on different parts of the app, you will usually (although not always) have the app broken into different modules for different features of the app. As your main concern seems to be apps which have more than ten files in a project, I take it you are not talking about apps so large they cross this threshold into one with multiple modules used by different teams in an organization within one app.