The Top 5 Practices That Make My Android Architecture More Scalable

In this video, I'll share my top 5 practices that I would recommend anyone for their Android codebase to make it more scalable.
Secure the limited testing bonus course before it's gone on July 14th and save 25% with SUMMER:
pl-coding.com/android-essenti...
25% on ALL courses and bundles:
pl-coding.com/premium-courses...
💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:
pl-coding.com/drop-table-ment...
Get my FREE PDF about 20 things you should never do in Jetpack Compose:
pl-coding.com/jetpack-compose...
Regular programming advice on my Instagram page:
/ _philipplackner_
Join my Discord server:
/ discord
00:00 Introduction
00:36 Practice 1
03:24 Practice 2
05:46 Practice 3
10:55 Practice 4
15:11 Practice 5

[@xAngel03]

1. Dependincy Injection
2. Testing
3. Modular Design
4. Avoiding In-Memory Global State
5. Packge Structure Consistency

[@tch.777]

Amazing like always, ty ❤

[@littlebitofeverything237]

Thanks!

[@shahar19971]

In case you need global state for contacts
Would you use state flow like in your example, or save that into room/datastore?

[@ren7907]

Philip, very nice video. Quick question, does it make sense to have a folder/package with only one file inside? for example, the mappers folder has only one file "DeviceNodeMapper".

[@snb_officall]

Hi philip, could you show how to make one feature? it showed in 3D the real position of the phone in space, not only rotation, but in full from height to tilt, please, I am subscribed to you

[@snb_officall]

hi Philip, I recently saw a program like crypto steps there to sell sneakers and pay for steps there they asked me for money to start and I deleted it now I can’t find a similar application, could you show me how to make one feature from there? it showed in 3D the real position of the phone in space, not only rotation, but in full from height to tilt, please, I am subscribed to you

[@Nek_12]

That feeling when you said you should avoid global state and 10 seconds ago you showed that you had a private mutable var connectedNode that had a race with other coroutines.

[@PhilippLackner]

Global state is not dangerous if it's automatically re-assigned after process death which is the case for this connected node. If the process dies and is then recreated, we'll have to re-establish the connection anyways. I've also explained that in the course.
Not sure which race condition you mean there regarding connectedNode.

[@Nek_12]

​@@PhilippLackner The wear messaging class sends messages using connectedNodeId which it will overwrite when you call connectToNode multiple times, causing messages to be sent to the wrong node. The design was supposed to observe and map the current node to a connection flow to prevent multiple clients from using it simultaneously. Your point about the local state is valid, the issue is how you manage it...

[@aamirhoda7363]

One Question though about "Consistent Package Structure" --
As we have structured packages based on features, then my question is, if my "admin_override" feature has a couple of very small features that open up different screens as follows:
1. setting "printers" config through a screen,
2. showing "system_logs" through a screen,
3. "admin_override" screen itself for setting a couple of values/settings for the app to use;
then inside "admin_override" package, should I create sub-packages called "system_logs" & "printers" which will further contain the usual "data", "domain", "presentation", "di" packages; as well as "data", "domain", "presentation", "di" packages in "admin_override" package as well ???
admin_override
|__data
|__domain
|__presentation
|__di
|__system_logs
|__data
|__domain
|__presentation
|__di
|__printers
|__data
|__domain
|__presentation
|__di
👆 For Consistency ??

[@PhilippLackner]

That quickly results in package hell :D Don't make it more complex than it needs to be. If you feel like system logs and printers are part of the admin override feature, include them in the corresponding layer packages

[@user-pn7hx7wx2k]

Global state is dangerous, I had to rewrite my code to use local preference instead. Because process death caused app crash. I was tempted to use savedInstanceState to update global state, but I just decided in the end local preference aproach.

[@jinde5566]

I was using DataStore and combine with workflow that need Global state in UseCases

[@MrPDTaylor]

Phillip, do you know Timo Boll?

[@PhilippLackner]

Legend

[@sureshsivalingam01]

Hey philipp or anybody know.
In Android essential bundle course. I need some clarification which is lifetime access and which is limited time access?

[@PhilippLackner]

@@sureshsivalingam01 they're all lifetime access

[@sureshsivalingam01]

Thank u

[@androidpc9656]

What if the globol state should not persist only live until the app closes?

[@kivan26]

All the data should be accessed the same way, trough repositories. It is a repository implementation detail whether the data is stored in DB, file, rest api, shared prefs, or even in memory...

[@TheBlackManMythLegend]

Just read job offers and learn that .
Testing , solid principle , kotlin , jet pack compose and so on.

[@MrPDTaylor]

Guten tag

[@MrPDTaylor]

Third

[@MrPDTaylor]

Ich bin ein Berliner