The Ultimate Package Structure Guide for Android Developers

This video will show you The Ultimate Package Structure Guide for Android Developers!
💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:
pl-coding.com/drop-table-ment...
⭐ Courses with real-life practices
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:
pl-coding.com/premium-courses...
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

[@rohittp1585]

Finally a detailed video on package structure :) Thanks Philipp!

[@amol1608]

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!

[@TheMikkelet]

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.

[@user-dt2sd3jz5h]

with large scale project with feature teams (about 30-50 developers) it's not good to have top level

[@sijanneupane]

this was must needed! thanks, philipp!

[@samuelwakoli]

Thank you sir. I have really been wanting this, and I have learnt.

[@nrg4285]

Really needed this explanation, thanks Philipp

[@pelealexandru]

Another banger. Thanks Philipp.

[@umuttekin4967]

I don't call this "Ultimate Guide" but it was informative. Thank you

[@ChrisAthanas]

Great explanation of a usually very confusing and aggressive conversations

[@user-zd2xm8bg9d]

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?

[@omrihz]

Thanks! Very appreciated!

[@SamandarSdk]

Thank you Philipp 🎉

[@henrik908]

Thank you man I appreciate it.

[@alikazemkhanloo9514]

Now this is exactly what I wanted.

[@omer.ozdemir7]

Great tutorial thank you so much.

[@maroneda1063]

Okay, I will adapt this new packaging structure 😃

[@rikonikotako]

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!

[@vsv8161]

Thank you so much for your videos Philipp, they are amazing Could you please make a video on how to create a collapsing layout?

[@Mel-bw2fn]

Great video Philipp Would it be possible to have a series of videos where you take a real world project to demonstrate each ?

[@TVHovna]

package by type at module level, then by feature - that's perfect :)

[@robertfontaine3650]

Couple of nice tidy ups in here.

[@-ECE-SOGATAKAR]

Thanks philipp

[@zakariabouchantouf5141]

Thanks philip

[@olegleonov1310]

What do you think about video with multimodal structure? With API and implementation modules, dagger 2 as di.

[@geetthakur3253]

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?

[@saifulislamsajon5641]

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.

[@mustafaammar551]

Thank you BRO

[@user-pp5ip5ht2o]

Hi Philipp, thanks for these tutorials. Are you think make advanced gradle tutorial for android?

[@Axelfromthehudjelud]

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?

[@memedom769]

fun fact : our proffesors refrence is you😂

[@DJOrangeJoe]

Then you have a good professor, as he is referring to the best.

[@bensekyondwa]

This is the same package structure I have used in my latest Android project.

[@randomtalks9891]

Philipp, your videos are incredibly informative, and I've learned a lot from them. Keep up the fantastic work! Thanks!

[@emmanuelmtera5936]

Does this apply to ios or swiftui projects too ie when you are implementing apps in kmm

[@alexandrereutola3246]

Will you ever make a video about the best package structure for a Ktor project?

[@abiodunmoses2638]

I think I prefer the hybrid way - combining both layer and feature modules.

[@LucasSilva-jd2bf]

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.

[@iAbanoubSamir]

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.

[@Katzenmuetze]

Just as an addition: This is basically domain-driven design (DDD) :)

[@ChrisAthanas]

It’s an aspect for sure, but not the only idea

[@CriticasDeCriticas]

@@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?

[@FebinAugustine]

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...😁

[@sergeykharuk5614]

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.

[@user-ut2su4vu5o]

Try to add a navigation module with bottom nav as an example please.

[@danielreinhold8475]

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?

[@dairondanilo6067]

How would you structure it for a server driven UI?

[@kambivictor]

What about if different roles exist, say some users have more privileges than others like super admin to admin, and a normal user role

[@amirrezababaei3300]

It was a good article, if possible, design and implement a VPN app.

[@MohamedAmin-wu7oj]

What is the shortcut for creating a new package in android studio ?

[@antarezaghifary9670]

this is clear arch? this is similarity with modular

[@stasleonov5196]

Philipp, someone give you great success in life and a lot of money for everything you do)

[@jackeblan]

I still prefer the old way you were organizing your packages.

[@user-sn8ep7ji3t]

I've been doing exactly like this hehe

[@thesavoyard]

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.

[@ddstudio1580]

With Module?

[@mmmdbdlov5344]

where put service or receiver ?

[@HossamQandeel]

We need a modularization tutorial video?

[@Elkasinox]

Could you do a basic testing course on yt?

[@PhilippLackner]

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

[@user-dt2sd3jz5h]

what about the gradle? it will be massive

[@sefke118]

Thank you very much for this! As a begginer, this was very helpful!

[@rishabhsaraswat1928]

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

[@jonneymendoza]

Check his sample apps

[@darshanmukadam]

What about listeners?

[@AmitJayant]

Where should the wrapper helper classes go? Like BillingHandler, GoogleLoginHandler etc.?

[@Iphonerodesdecero]

You can place these elements in a module called, for example, googleservices.

[@mathieuperroud7423]

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.

[@ozdmromer7]

What do you think about future of Android and developers. Demands will be increased for development or decreased due to rise of AI ? :)

[@seguramlk]

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

[@test9828alpha]

what is about a shared domain mode between two features

[@DJOrangeJoe]

put it into a core package as he shows at the end of the video

[@test9828alpha]

@@DJOrangeJoe no no no

[@ThePratik822]

In which package viewmodel is come? Also activity and fragment also need to create package in presentation package?

[@yeeti3700]

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.

[@jonneymendoza]

Presentation.viewmodel

[@sidbot9622]

Thanks

[@GabrieleRugani]

Hello! I purchased one of your courses but unfortunately, I've lost access to my Discord account. How can I go about recovering it?

[@sreenag1255]

How this works for 30+ featured application?

[@Jonathan-zq8vs]

Low coupling, high cohesion

[@4ytonly]

For us noobs, what is data, domain and presentation? :)

[@leonardovalle2763]

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

[@sumanshah5750]

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 KZbin.please help

[@jonneymendoza]

Okhttp

[@deviantstudio]

package name should be singular: model, usecase etc

[@_Mr_Megh_]

I am first want a heart Phillip ❤😂🎉🎉

[@user-tz4fx7dw3p]

why not by layer, than feature?

[@PhilippLackner]

Didn't I explain that?😄

[@user-tz4fx7dw3p]

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😊

[@PhilippLackner]

@@user-tz4fx7dw3p each layer is still its own module, just inside a parent feature module. Pure layered modularization pretty much breaks every principle of modularization 😄

[@user-tz4fx7dw3p]

@@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) kzbin.info/www/bejne/Z2e2qIesr6mCZqMsi=UjItnHrQfywtQI6T

[@shahar19971]

@@PhilippLackner the idea is by layer than by feature.. kzbin.info/www/bejne/Z2e2qIesr6mCZqM would like to here you opinion

[@vibovitold]

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.

[@barfyman3Six2]

Far from ultimate. I agree with some of this, but I very much dislike the package structure you are showing here.

[@MonichGPT]

UseCase, Data, Domain 🤢🤢🤢🤢🤢🤢

[@pushpak03]

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.

[@leoparda]

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.

[@midknightgamers7466]

can you make one video on the same packaging and architecture guide for KMP projects as well, waiting on your next Kotlin Multiplatform video🕥

[@PhilippLackner]

This structure is universal for all client based software 😄

[@MinhTo-lt9wy]

[@a2_50_gourav5]

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

[@omer.ozdemir7]

Did you add all annotations correctly ?

[@rishabh-more]

Did you add the @AndroidEntryPoint annotation to your MainAcitivity?

[@a2_50_gourav5]

@@rishabh-more yes i did But same error

[@a2_50_gourav5]

@@omer.ozdemir7 Yes I think so