Building a scalable, modularized, testable app from scratch
Vložit
- čas přidán 1. 06. 2024
- If you're building an app from scratch or looking to update your app to follow modern Android development best practices, this talk will give you a high-level overview of all the pieces you need, and how they fit together using a real-world example: the Now in Android app. The source code for this app can be found at goo.gle/3XTxMIR
This talk also explains how we built one of the app's features and the decisions behind its design. We'll cover the app's testable, modular architecture and talk about how we built a set of reusable UI elements using Jetpack Compose and Material3.
Speaker: Don Turner
Chapters:
0:00 Introduction
1:12 Architecture overview
2:47 Data layer
5:03 UI layer overview
5:26 Creating a state holder
8:50 Creating a screen
11:34 Modularization
14:37 Testing
17:36 Creating an instrumented test
18:27 Material Design
20:03 Material component customization
20:43 Summary
Watch more:
Watch all the Android Dev Summit sessions → goo.gle/ADS-All
Watch all the Modern Android Development track sessions → goo.gle/ADS-MAD
Subscribe to Android Developers → goo.gle/AndroidDevs
#Featured #AndroidDevSummit #JetpackCompose - Věda a technologie
Wow, I think this is one of the most inspiring overviews of present day Android architecture I have seen. I've been doing Android development for 10+ years and this guide is music to my ears (I won't admit to the 3000+ line activity files from my past). If this seems like too many classes layers, for any on-trivial, multi-developer/designer project, this will save work, promote parallel development and facilitate reuse.
Thank you so much for your kind words, Steve! It warms our heart to see users so positive and so open to sharing their experiences with us. It is an honor to have you onboard 😊
😀
🔥
//Button that launches settings UI
private Button mSettingsAppButton;
private static final String RB_SETTING_APP_INTENT = "android.adservices.ui.SETTINGS";
//Does setup for button on screen that will launch settings UI to observe Topics
private void registerLauchSettingsAppButton() {
mSettingsAppButton.setOnClickListener(
new View.OnClickListener() {
@Override
public void onClick(View view) {
Context context = getApplicationContext();
Intent activity2Intent = new Intent(RB_SETTING_APP_INTENT);
activity2Intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(activity2Intent);
}
});
}
Only took ten years lol
And the 3000+ line activities were actually best practices from the early days of android
What a mess
this is the state of the art on how tutorials should be, detailed well structured and straight to the point.
its coming from the android team ... so i am not surprised.
thanks for sharing such case study
Definitely upgrade from the normal google android content (poor audio, difficult to understand and poorly structured, random unnecessary details)
Thank you for not just doing "hello world". Most real world apps are messy and complicated. It's nice to see you suggest solutions to address app scaling!
The stateless and stateful versions of screens is dope!
Respect, it saves one's sanity from thinking how you'd make things performant and testable.👍🏾
This now-in-android project is made with a lot of enthusiasm! Love the architecture. Just one thing for me, I will put the :core:domain or :core:data in each feature modules. I think it will be more scalable
That was a solid app build. Though I'm only a newer developer, the concepts were explained really well and everything is logical and straightforward to me!
We're so happy to hear this, Jordan! Glad that the video was a helpful learning experience for you 🙌
I'm a newcomer to Android app development from a Java fresh graduate background. Watching this video I feel like I understand a lot, but also don't understand a lot 😂
The video gave a great explanation on how to write apps with good architecture, but it also gave me a lot of questions such as what are how events work, what is a scope, how exactly to work with Flow and Preview and much more.
Overall, I love this overview! It give me something to aim for and topics to study ❤️
The shortest but very informative video with the necessary knowledge I have ever seen on this channel.
Glad to hear that the video was helpful to you, Eren! Thanks for sharing your feedback with us 👍
I wanted to restart Android development . I think this video is just the correct one to start with. Everything is so well explained and to the point.
I really enjoyed this session. We went from all the high level stuff to low level details. The modularisation section was really special.
Raised my standards!
One of the best videos from the Android team.
Thanks, DomonK! Your comment totally just made our day 😎
That's the concise meaningful almost all-over guide that arranges what was learned! I am thankful for it.
Awesome, I just needed this kind of video.
Thank you.
Great tutorials, so easy to understand 👍
This is exactly what I needed to get started with real world development after getting familiar with Compose and Kotlin , THANK YOU!!
I need more of these. Great video
Bro we want more like this more with jetpack compose it's really interesting and easy understanding. Thank you very much Android developers keep posting videos like this it helped me a lot.
We agree, Jetpack Compose is really awesome!
Make sure to subscribe, so you don't miss any of our future tutorials: goo.gle/AndroidDevs
@@AndroidDevelopers Hi guys, do you or any partners have any paid bootcamps, courses/certifications covering the A to Z of jetpack? (much like this guide but on a deeper way?) I've been out of app dev. for more than 6 months and the free courses cover compose quite well but theres so much more (flows, workmanager, datastore, etc). I find it easier to learn with a cross project than individual separated codelabs.
This one is totally understandable :), easily puts all the concepts nicely.
This is the best comprehensive guide to a non trivial modern Android app
Glad to hear this was so helpful, Shibasis!
With so much creative power at your fingertips, what will you design?
The sky is the limit 🌌 🌃
Insanely informative and most importantly understandable, its realy a gold in pile of various information
Wow they went all in from where to place the classes to Tests to Material Design example! Didn't expect to see all this going in.
This video is gem !
Nice work by team
Awesome! best dev experience ever
This was a very well scripted and delivered talk. Covered an awful lot of bases but was very clear.
Thanks, Darren! Comments like yours are important, because they let us know we're consistently bringing high quality informational content to our viewers-like you! We really appreciate it 😎
This sums it all up in a very good way ...
Great content, great explanation ! thanks to the dev relations team !
Great feedback, Yesid! You can also learn even more features by checking out Jetpack Compose via this link: goo.gle/3A0N7h9
Let us know how you'll use Jetpack Compose for your project or app. We're eager to hear more 🤩
Jetpack compose simplifies android development even if you come from different framework background like Swift UI, React etc.
The engineers built it based declarative ui concept.
Very clear cut concepts..
Excellent talk
Thank you a lot 🌹🧡
this video is great! thank you!!
So well explained. Thanks
Wow I really love this platform
Beautiful. I thought I was doing things wrong!
Thanks a lot.
I wished you showed the code for VersionCatalogs, plugin conventions and elaborated more on how to use them in modularization.
@@donturner1928 is there any codelab about using this build logic with version catalog?
Amazing work, Don! ❤
+1
So useful! Thank you
We've got you covered, Ihor! We've gone ahead and linked the summit event page below for your convenience. Enjoy 😄
goo.gle/3TRoB9T
Great video just confused because I'm not familiar with the kotlin syntax just Java but I was able to fill in the blanks though by cross-referenceing what you were saying with what I know about Java
I believe the link between the modules (how are they linked in code) is one of the most important things here but you didn't show, please, show in a next video
speaking of stateless\stateful decomposition, if my viewmodel contains no data from network but some text input validators, do I use the same approach to contain my viewmodel in a separate composable function?
I believe that if your viewModel doesn't create uiState then you don't need the stateful version, just pass your VM to the stateless version although if you intend to scale, then you should consider may be passing viewModel to both or reconsider your design.
If your view model _just_ contains text input validators, no state, then it's not a view model, it's a logic holder, in which case you can instantiate it as a plain class and pass it as a dependency to your Composable. There would be no need (and indeed, no possibility since your VM doesn't contain state) to create stateful and stateless Composables.
fair enough, thanks
If any can answer when we use navigation we pass the scrren with state and not with viewmodel in our composable fucntion?
A local storage layer should be added between the data layer and the UI layer.
This layer responsibility is to :
- return placeholder values when data is not yet available from the repository : managed on the UI side by the Loading... state, but how to return to loading state on refresh ?
- ensure data consistency:
1. recompute derived values like count, sum, average when items are added or removed from a list
2. acts as a barrier to send a cohérent set of values to the UI
3. prevent updating a list of items while the associated UI is in selection mode
4. act as a buffer to stack events like selection states until the "Apply" event is triggered by the user through the UI
- do data remediation on publication: ignore changing data of any item removed from the last snapshot, take care of data validation schemes from the data layer, let the user solve conflicts like addition of an item already added by another user
All those use cases are common pitfalls of user experience that are still not covered in my opinion by the View ViewModel Data layers.
Can you please make more videos on pose detection?
tbh this is more complicated! I have almost 10 years of android experience, although the lifecycle, concurrency problems are a lot better nowadays I think we are overcomplicating things nowadays with multiple repos, modules and over abstraction. from my experience I would just recommend keep the abstractions very minimal and don't be shy about creating code duplications as long as the product doesn't hits it's mature state. because often times we spend more time on abstracting things than doing actual productive work.
You spend less time implementing new features than maintaining old features, this will make things easier. Going with this clean architecture does help a lot for bigger projects where multiple people work on the same project and you can distribute work to every developer.
@@dragossusi that's the same argument for micro services and it created more problems then solutions. I think we have to step back and ask first why the freaking build time is so high, why everything is a repo even for simple async call, why everything is reactive when you can perfectly do simple synchronous call, why do I have to change everything whenever a shiny new API comes. We had doom in the 90s before 3d was a thing and we didn't have any complicated abstractions and hundreds of software layers and "clean architecture". We should strive for simplicity rather than writing things to fit a so called "clean architecture"
@@skytech2501 it depends on the feature and requirements, it's hard to keep your code as a monolith and run it on 10.000 servers across the world. For Android it's pretty hard to do AB testing without abstracting the functionality and it's pretty hard to test. Once you get used to writing this way, it will get better and develop things faster than before. It's also far easier to test and catch bugs before going to production.
In the past you could have success with simple apps like a flashlight app for Android, but now you have to have a lot of functionality for your app to gain audience.
But I agree with you for some projects, but this is the recommended way for a successful application, you just create a lot of classes like you would build your own libraries, instead of writing spaghetti code and spend hours changing some functionality (tests are the hardest to maintain).
@@dragossusi complexity is almost always a result of optimization. Let me give you an example, we have an entire set of libraries for dependency injection, I call that unnecessary abstractions, other words its solving very tiny problems for a large cost of bloated build time, dynamic coupling (leads to runtime errors), if it's property injuction then it's even hard to reason about what the component dependencies are. On the Contrary you write your own factory and constructors then all the sudden your compiler does the work for you. It's not about creating multiple classes to separate responsibility it's about inventing complexity in the name of scalability and reusability!
Yes totally agree with you. I had dealt with many source codes with unnecessary abstractions and it was a nightmare to add stuff and maintain it.
How can we provide dependencies using hilt in this modular approach mentioned in the video?
In the Now in Android project we use a convention plugin for the Hilt configuration (github.com/android/nowinandroid/blob/46deba844e43e4bfa0dc55ee08353276df16df39/build-logic/convention/src/main/kotlin/AndroidHiltConventionPlugin.kt). This can be used by any module which uses Hilt, either by applying the plugin directly in your build.gradle.kts, or by applying it inside another convention plugin which is then used by that module.
For example, the ForYou feature module (github.com/android/nowinandroid/blob/dcc23829d4cbbe800b21646dc138587b3949896d/feature/foryou/build.gradle.kts#L17) applies the `nowinandroid.android.feature` plugin, which applies the `nowinandroid.android.hilt` plugin. The assumption here is that feature modules will always use Hilt for dependency injection.
Once you have the Hilt configuration set up, you can use the Hilt annotations (e.g. @HiltViewModel in github.com/android/nowinandroid/blob/dbff140b64da33e9802206102ce3dcfd1ef15dcb/feature/foryou/src/main/java/com/google/samples/apps/nowinandroid/feature/foryou/ForYouViewModel.kt#L51-L50) as you would normally.
When DataStore exposes a cold flow, how we ensure the collector is still updated once the flow emits its last/final value? Is there a loop or backing state flow?
Great question. At @ 7:42 you can see there's a StateFlow which is used to convert the cold flow which comes from DataStore into a hot flow. The viewModelScope is specified so that when the ViewModel goes out of scope collection will stop. Collection will also stop if there are no downstream subscribers on the StateFlow (e.g. when the screen is no longer visible).
@@donturner1928 Thx for the reply 👍. I was actually rather curious about how the upstream cold flow that is exposed by DataStore( or similarly by Room or callbackFlow) is kept active, especially after they emit their last values. What I've found out is that most of such APIs use channels under the hood which is sort of a blocking queue and keep the exposed cold flow active until it's closed.
@@zekininadresi Ah I see, another great question. The internals of DataStore are here: github.com/androidx/androidx/blob/354b4bdd5395fb3de9cce96915c5aebf5bdc4abf/datastore/datastore-core/src/commonMain/kotlin/androidx/datastore/core/SingleProcessDataStore.kt#L58. It looks like DataStore uses a MutableStateFlow internally into which new values are emitted whenever a write occurs. This is how the flow is kept alive.
Hey mobile devs, are there any unified UI DSL libraries for defining UIs across both android and IOS?
I’m planning to develop mobile apps natively and share lots of business logic across the web and mobile, throwing something together to address this.
The bit that is frustrating me is achieving something similar for the UI. Even if the web UI remains a separate concern, being able to describe the mobile UI in a unified way would really help.
Any insights appreciated 👍
And yes I know about all of the usual suspects such as Flutter, Capacitor, Traui, NativeScript and so on. Won’t be using any of these 👈
Terrific!
please do tell what the syntax is doing. Some of us are still stuck with the old Java ruidmentary ways! Like this Line: data class Success(val newsResources : List) : ForYouUiState in this line what is the purpose of ForYouUiState ? Also by reading this line, I assume that the class has a constructor with the only parameter of type List
I recommend the Kotlin Koans course kotlinlang.org/docs/koans.html. It's specifically for Java developers who want to learn Kotlin.
To answer your questions though. ForYouUiState is the supertype of Success and yes, Success has a constructor which takes a List
is there java version of this series ? thank you
Awesome! I like this video! I will watch it again during my development.
Btw I didn't find the github link.
If you can share it for me, I will be grateful!
Have a good day~
It would be helpful if there was a link to a sample project which implements all that. Great video, though.
Sample projects are incredibly helpful. We've got one for this you can look at right here!
goo.gle/3tB6x8t
Thanks Google for important info
People who designed Android programming were clearly not from our world. To invent such complicated way to do simple things! I came from other programming languages, trying to learn it now and see it's just crazy over-complicated. Especially giving names to methods and variables.
It’s been one hack over hack to fix a hack since day one
A Revolution is brewing and it’s name is Compose
Android will soon just be an abstraction over a compose library
Android platform stinks
Thank you
Is the project in the github repository? The YT link does not open this project or I do not know how to look....
You can find the source at github.com/android/nowinandroid
Thanks
can anybody say @ 3:38 do we need to create custom class UserPreferences ? if yes then in that class what do we need to declare?
The UserPreferences class is autogenerated from a protobuf file which defines the fields you want to store in DataStore. You can see this here: github.com/android/nowinandroid/blob/main/core/datastore/src/main/proto/com/google/samples/apps/nowinandroid/data/user_preferences.proto
@@donturner1928 Thank you for providing the link to the autogenerated UserPreferences class. I appreciate your help in clarifying this. However, I noticed that the bookmarks map is not included in the proto file. In this case, should I use the bookmarked_news_resource_ids instead of the bookmarksMap? Additionally, do I need to create a local Map bookmarks in the LocalDataSource class for the toggleBookmark function?
@@donturner1928 Thank you for the clear answer. I appreciate your help!👍🏼👍🏼
is source code available in github? it will be helpful to newbies like us
Hi, Muhammed! You can find the source code for this app on GitHub, here: goo.gle/3XTxMIR
We hope this helps 😊
Welcome to Android Development 😊
Stay awhile and listen 🧙♂️
awesome
The modularization thing seems very complicated and there is no comprehensive documentation.
Are there any guide about build-logic from scrach? It is too hard to study
I'm new in this space
Welcome in! Grab a seat and kick up your feet, we have plenty of resources to help you get started 🎓
You can find more videos by subscribing to our channel here: goo.gle/AndroidDevs
You can also check out our guide on Building your first app here: goo.gle/3N0k5Dn
Thanks boss
who's Adam?
ดีครับคําแปลภาษาไทยดีครับ
Why don't you also do the same in flutter and compare the app ? Pro and cons
👋🏼🇨🇴🧔🏻👍🏼🤝🏻
Add feature to android
Built in Gcam
Monitor Thermal heat
Show developers option in setting
Reducing Heat engine
Accurate export files
Accurate send files in Google drive
And Google Photo
Accurate Google drive transfer files Reader
Accurate bluetooth files
พอเข้าใจเป็นอย่างแต่เข้าใจง่ายมีคําแปลภาษาด้วยดีครับ😁
15:07 we would take you more seriously if ALL the sample code coming from google did this
Lol
They never have tests and wonder why front end devs skip it
Lol
I love Java
Man .. each couple of months, Google changes all the concepts 180 degree, It's getting tiresome and frustrating keeping up to date to Android development.
you can be quite sure that anything you learn in this video can and will change in the future
instant downvote for "he/him"