It's awesome you are talking about these things. Even the seniors sometimes ask themselves is this approach good, and then there's your video to give more info and to see how someone like you does things. I love your videos because you always talk about different and very important things that many of the Android developers need. I didn't find anyone making Android videos this detailed and concise. Keep it up!
I prefer the more monolithic architecture where you have top level data/domain/presentation folders and then subfolders with files that relate. My reason being that app development can be hyper prone to chaning requirements, and needs to be super flexible with. So instead of keeping your usecase feature specific, they should be available from anywhere in the app. In my experience, apps that start out using feature-modules suffer from ever-changing reqs and usually end up moving more and more logic/UI from the feature module to the core module, thus invalidating any intent to modularize your app.
The core modules that define the functions for public use will also continue to increase as the project grows in size. As the project size gradually increases, many functions will be located in the core module. And there may come a time when we have to think about further modularization of core modules. What do you think about this?
Perfect and useful as always. Thanks Philip! Don't you think to create the second course of Bluetooth? I mean for BLE? It'll be very useful (: Thanks, have a good day!
awesome video thanks philipp just one question : database initialization and apiServices we can write in core package, its allow to use all other module commonly is that correct?
What about features referencing each other? For instance, it makes sense for the profile feature to reference the auth feature, as it needs the User model and AuthToken. In that case, would you place these in the core model and reference it in both auth and profile? I like the feature-first approach, but I am never able to achieve 100% modularity since there's always a feature that ends up depending on another feature, so now I either put everything in the shared feature or I merge both features together.
I think anything that need to be used by more than one feature is a common or shared and need to be inside core/common module. Since feature module can not depend on another feature module.
Philipp would you please give some of the resources as a reference from where I can actually relate the things you described in your video. Or I can take them as a reference of your video to deep dive into the architectural file folder structure. Thanks in advance.
Philipp, thanks for this video. I usually structure my domain and data layer firstly by types (models, usecases, etc.) and then inside those folders I group them by context (auth, user etc.). What do you think about this approach?
Just one question: Where would a Repository (interface/abstract class AND implementation class) into this structure? I would say it should be between data and domain. What would you say?
@@ChrisAthanas What happens if I need to create a UseCase that gets it's data from repositories from 2 different features? How do you decide where to put it?
In a multimodule project should we also create data, domain, and presentation packages for the app module? Because the app module is actually collects all other modules together.
Considering GoogleLoginHandler, into core/presentation or auth/login/presentation imo as it references context and deeply related to pure ui logic. Also, depending of the logic you embed into you handlers you should maybe split it into different parts.
So how is it worse if they have 3 modules and features separated by packages inside those modules? You just reversed it and lost most of the advantages of MVVM Clean. If I need a view model, I go to the presentation, then the package I want, then the packages view model. Instead, it's no longer cleanly separated by job but bloated by feature. This is the mess my last legacy project was organised by. Its terrible.
Increased for sure. Companies will say say things like: "The X AI does that in 2 hours, if you can't do that in 1 hour you're out". Unless it's cheaper to hire developers instead of paying for AI subscriptions. Unfortunately it always comes down to expenses. We're just numbers pal
can u please make a video on how are all the things put together for an app. Like we make a server using spring boot, using mongodb for storing data and many other things. If u have already main a premium course on it please share the link
Summry Of this vedio This video is about creating a package structure for Android apps. The speaker, Philipp Lackner, suggests a structure that is clear, easy to understand, and scales to the project's needs. He also mentions that it should be easy to migrate to a multi-module structure. Here are the key points from the video: * A good package structure should be: * Clear and easy to understand * Scalable to the project's needs * Easy to migrate to a multi-module structure * The speaker suggests dividing the app into features, and then creating packages for each feature. * Each feature package should contain sub-packages for the presentation layer, domain layer, and data layer. * The speaker also suggests having a root package for classes that are shared between multiple features. * He concludes by mentioning that this is just a suggestion, and that developers should be flexible with their package structure as long as it meets the criteria mentioned above.
Can you tell us how to get api call of spring boot on android jetpack compose .(RESTapi ,jwt athuntication) Because not found any video on TH-cam.please help
Your viewmodel is also included in the presentation layer. For example, LoginViewModel would be included in the Login package (presentation => login => LoginViewModel, LoginState, etc.). The same applies to Fragments / Activities.
I know that's not the main point, obviously, but please DO NOT use underscores in package names (use_cases). It's against the Kotlin convention. "Package and class naming rules in Kotlin are quite simple: Names of packages are always lowercase and do not use underscores [...]" - from the official documentation.
Not really, well having data + domain coupled to the feature might end with later need of decoupling for sharing in other feature.. Modularizing the project by Layer than feature is my favorite, because i can enjoy the cohesion of each module, and it's not coupled to the feature module Would like to hear your opinion😊
@@shaharkeisar each layer is still its own module, just inside a parent feature module. Pure layered modularization pretty much breaks every principle of modularization 😄
@@PhilippLackner would like to hear how does that breaking modularization I'm speaking about layer module that has inside feature modules Example: Data module Inside data modules by feature LoginData NotesData I took that advice from here (Google modularization guide) th-cam.com/video/16SwTvzDO0A/w-d-xo.htmlsi=UjItnHrQfywtQI6T
i don't know why your voice doesn't match your face seems like someone else is speaking . Also you open your mouth too much , i am saying this because it's too noticeable for people like me :) yup it distracts.
Hi Philip Lackner Can You help me Out Doubt From You Twitch Live Videos when i Run the App it Crash and it shows this error " java.lang.IllegalStateException: Given component holder class com.example.socialnetworkapp.MainActivity does not implement interface dagger.hilt.internal.GeneratedComponent or interface dagger.hilt.internal.GeneratedComponentManager" i think there is some issue with my gradle file versions
Finally a detailed video on package structure :) Thanks Philipp!
It's awesome you are talking about these things. Even the seniors sometimes ask themselves is this approach good, and then there's your video to give more info and to see how someone like you does things. I love your videos because you always talk about different and very important things that many of the Android developers need. I didn't find anyone making Android videos this detailed and concise. Keep it up!
I prefer the more monolithic architecture where you have top level data/domain/presentation folders and then subfolders with files that relate. My reason being that app development can be hyper prone to chaning requirements, and needs to be super flexible with. So instead of keeping your usecase feature specific, they should be available from anywhere in the app.
In my experience, apps that start out using feature-modules suffer from ever-changing reqs and usually end up moving more and more logic/UI from the feature module to the core module, thus invalidating any intent to modularize your app.
with large scale project with feature teams (about 30-50 developers) it's not good to have top level
I don't call this "Ultimate Guide" but it was informative. Thank you
The core modules that define the functions for public use will also continue to increase as the project grows in size.
As the project size gradually increases, many functions will be located in the core module.
And there may come a time when we have to think about further modularization of core modules.
What do you think about this?
this was must needed! thanks, philipp!
Perfect and useful as always. Thanks Philip!
Don't you think to create the second course of Bluetooth? I mean for BLE? It'll be very useful (:
Thanks, have a good day!
I think I prefer the hybrid way - combining both layer and feature modules.
awesome video thanks philipp
just one question : database initialization and apiServices we can write in core package, its allow to use all other module commonly
is that correct?
Great explanation of a usually very confusing and aggressive conversations
What do you think about video with multimodal structure? With API and implementation modules, dagger 2 as di.
Another banger. Thanks Philipp.
What about features referencing each other? For instance, it makes sense for the profile feature to reference the auth feature, as it needs the User model and AuthToken. In that case, would you place these in the core model and reference it in both auth and profile?
I like the feature-first approach, but I am never able to achieve 100% modularity since there's always a feature that ends up depending on another feature, so now I either put everything in the shared feature or I merge both features together.
I think anything that need to be used by more than one feature is a common or shared and need to be inside core/common module. Since feature module can not depend on another feature module.
Thank you sir. I have really been wanting this, and I have learnt.
Really needed this explanation, thanks Philipp
Philipp would you please give some of the resources as a reference from where I can actually relate the things you described in your video. Or I can take them as a reference of your video to deep dive into the architectural file folder structure. Thanks in advance.
Philipp, thanks for this video. I usually structure my domain and data layer firstly by types (models, usecases, etc.) and then inside those folders I group them by context (auth, user etc.). What do you think about this approach?
Great video Philipp
Would it be possible to have a series of videos where you take a real world project to demonstrate each ?
Thank you so much for your videos Philipp, they are amazing
Could you please make a video on how to create a collapsing layout?
Does this apply to ios or swiftui projects too ie when you are implementing apps in kmm
package by type at module level, then by feature - that's perfect :)
fun fact : our proffesors refrence is you😂
Then you have a good professor, as he is referring to the best.
Just one question: Where would a Repository (interface/abstract class AND implementation class) into this structure? I would say it should be between data and domain. What would you say?
Philipp, your videos are incredibly informative, and I've learned a lot from them. Keep up the fantastic work! Thanks!
This is the same package structure I have used in my latest Android project.
Will you ever make a video about the best package structure for a Ktor project?
Okay, I will adapt this new packaging structure 😃
Hi Philipp, thanks for these tutorials. Are you think make advanced gradle tutorial for android?
Just as an addition: This is basically domain-driven design (DDD) :)
It’s an aspect for sure, but not the only idea
@@ChrisAthanas What happens if I need to create a UseCase that gets it's data from repositories from 2 different features? How do you decide where to put it?
@@CriticasDeCriticasThat is explained here: 10:00
Yu-Gi-Oh reference
Now this is exactly what I wanted.
Waiting for: The "Ultimate" Multi Module Package Structure Guide for Android Developers
Thank you Philipp 🎉
Try to add a navigation module with bottom nav as an example please.
Couple of nice tidy ups in here.
Thanks! Very appreciated!
In a multimodule project should we also create data, domain, and presentation packages for the app module? Because the app module is actually collects all other modules together.
Where should the wrapper helper classes go? Like BillingHandler, GoogleLoginHandler etc.?
You can place these elements in a module called, for example, googleservices.
Considering GoogleLoginHandler, into core/presentation or auth/login/presentation imo as it references context and deeply related to pure ui logic.
Also, depending of the logic you embed into you handlers you should maybe split it into different parts.
What is the shortcut for creating a new package in android studio ?
So how is it worse if they have 3 modules and features separated by packages inside those modules? You just reversed it and lost most of the advantages of MVVM Clean. If I need a view model, I go to the presentation, then the package I want, then the packages view model. Instead, it's no longer cleanly separated by job but bloated by feature. This is the mess my last legacy project was organised by. Its terrible.
Expecting a video about login/ signup using firebase or mongo db. Also able to login/signup offline with local db and get updated when online...😁
It was a good article, if possible, design and implement a VPN app.
What do you think about future of Android and developers. Demands will be increased for development or decreased due to rise of AI ? :)
Increased for sure. Companies will say say things like: "The X AI does that in 2 hours, if you can't do that in 1 hour you're out". Unless it's cheaper to hire developers instead of paying for AI subscriptions.
Unfortunately it always comes down to expenses. We're just numbers pal
Thank you man I appreciate it.
this is clear arch? this is similarity with modular
Hello! I purchased one of your courses but unfortunately, I've lost access to my Discord account. How can I go about recovering it?
Great tutorial thank you so much.
How would you structure it for a server driven UI?
Philipp, someone give you great success in life and a lot of money for everything you do)
Thanks philip
what about the gradle? it will be massive
Low coupling, high cohesion
I still prefer the old way you were organizing your packages.
Thank you very much for this! As a begginer, this was very helpful!
How this works for 30+ featured application?
With Module?
can u please make a video on how are all the things put together for an app. Like we make a server using spring boot, using mongodb for storing data and many other things. If u have already main a premium course on it please share the link
Check his sample apps
Thank you BRO
where put service or receiver ?
What about if different roles exist, say some users have more privileges than others like super admin to admin, and a normal user role
Summry Of this vedio
This video is about creating a package structure for Android apps.
The speaker, Philipp Lackner, suggests a structure that is clear, easy to understand, and scales to the project's needs. He also mentions that it should be easy to migrate to a multi-module structure.
Here are the key points from the video:
* A good package structure should be:
* Clear and easy to understand
* Scalable to the project's needs
* Easy to migrate to a multi-module structure
* The speaker suggests dividing the app into features, and then creating packages for each feature.
* Each feature package should contain sub-packages for the presentation layer, domain layer, and data layer.
* The speaker also suggests having a root package for classes that are shared between multiple features.
* He concludes by mentioning that this is just a suggestion, and that developers should be flexible with their package structure as long as it meets the criteria mentioned above.
For us noobs, what is data, domain and presentation? :)
they are each layer of an app. search about Clean Architecture, it's actually a pretty simple concept you can even learn from short videos
What about listeners?
Can you tell us how to get api call of spring boot on android jetpack compose .(RESTapi ,jwt athuntication) Because not found any video on TH-cam.please help
Okhttp
In which package viewmodel is come? Also activity and fragment also need to create package in presentation package?
Your viewmodel is also included in the presentation layer. For example, LoginViewModel would be included in the Login package (presentation => login => LoginViewModel, LoginState, etc.). The same applies to Fragments / Activities.
Presentation.viewmodel
Could you do a basic testing course on yt?
I have a few videos, but proper testing is too complex to just make a "basic" course about. This one covers it all: pl-coding.com/testing
I am first want a heart Phillip ❤😂🎉🎉
I know that's not the main point, obviously, but please DO NOT use underscores in package names (use_cases).
It's against the Kotlin convention.
"Package and class naming rules in Kotlin are quite simple:
Names of packages are always lowercase and do not use underscores
[...]"
- from the official documentation.
We need a modularization tutorial video?
package name should be singular: model, usecase etc
why not by layer, than feature?
Didn't I explain that?😄
Not really, well having data + domain coupled to the feature might end with later need of decoupling for sharing in other feature..
Modularizing the project by
Layer than feature is my favorite, because i can enjoy the cohesion of each module, and it's not coupled to the feature module
Would like to hear your opinion😊
@@shaharkeisar each layer is still its own module, just inside a parent feature module. Pure layered modularization pretty much breaks every principle of modularization 😄
@@PhilippLackner would like to hear how does that breaking modularization
I'm speaking about layer module that has inside feature modules
Example:
Data module
Inside data modules by feature
LoginData
NotesData
I took that advice from here
(Google modularization guide)
th-cam.com/video/16SwTvzDO0A/w-d-xo.htmlsi=UjItnHrQfywtQI6T
@@PhilippLackner
the idea is by layer than by feature..
th-cam.com/video/16SwTvzDO0A/w-d-xo.html
would like to here you opinion
UseCase, Data, Domain 🤢🤢🤢🤢🤢🤢
Far from ultimate. I agree with some of this, but I very much dislike the package structure you are showing here.
Can you summarize what you would do differently and why?
i don't know why your voice doesn't match your face seems like someone else is speaking . Also you open your mouth too much , i am saying this because it's too noticeable for people like me :)
yup it distracts.
can you make one video on the same packaging and architecture guide for KMP projects as well, waiting on your next Kotlin Multiplatform video🕥
This structure is universal for all client based software 😄
Thanks
Hi Philip Lackner
Can You help me Out
Doubt From You Twitch Live Videos
when i Run the App it Crash and
it shows this error
" java.lang.IllegalStateException: Given component holder class com.example.socialnetworkapp.MainActivity does not implement interface dagger.hilt.internal.GeneratedComponent or interface dagger.hilt.internal.GeneratedComponentManager"
i think there is some issue with my gradle file versions
Did you add all annotations correctly ?
Did you add the @AndroidEntryPoint annotation to your MainAcitivity?
@@rishabh-more yes i did
But same error
@@omer.ozdemir7 Yes I think so
Thanks philipp