Just finished - very good job. It is tough to explain the different data mappers, multiple product lists and relational tables but you did well sticking with it to the end and demonstrated a full MVVM approach.
Yes indeed it is tough but in a real world app you also have to deal with a lot of different data objects that need to be managed in a clean way without creating a mess. That's why I made this example even tho it consumes a lot of time only for data mapping. A classic note app example with one single data entity would be of course more fun :D Btw your navigation comment is totally right. There lambda functions would be better the different screens don't need to know about the other screens!
This is like hidden gem, this relation data models are worthy watching without another part of video. Maybe you could show us picture in MySqlWorkbench or somehow visualize database. Thanks for making these videos !!!
Thank you ! Well I first thought about showing an entity relation diagram but the video is already quiet long .. You can try to model it on your own with some graphic editor its not that hard. You have deliverer-order 1:n , deliverer-product 1:n and order-product n:m. The last one results in an additional table
Hey since this is a MVVM architecture tutorial, consider NOT passing the NavController into the individual Screens. The Screens should not need to know about other Screens and the navigation details since that violates the Single Source of Truth. Imagine trying to reuse one of the Screens; you can't if it is hardwired to navigate to certain destinations. It is better to hoist the ""goToOrders" buttonClick back up to your Navigation class, where all the nav details are known and orchestrated.
Yes of course I will do this in the future. This application has already multi module structure the only thing that's left is to apply it to real modules but the video would be too long then ..
@@kapps7407 True. Yes thats great. In a multi module structure each feature is at the top level and has it's own source tree (data/ domain / presentation), Gradle build (build.gradle.kts) and is linked with the 'implementation(project(":core")) / implementation(project(":deliverer-feature")) in the 'dependencies' in the that features 'build.gradle.kts'. Android studio has a "add module" feature that was really pushed by Uber. It works really well for us.
Very helpful video, that is what i needed. If i need function to get and save new oauth token in almost every feature's repository, should i repeat the same code everywhere or create one repository for this in the core package? Or maybe should i create abstract class with this logic in the core package and then extend all repositories with this class?
My dear, great video. I like how you put together the folder structure for the proposed architecture. I've worked on an application with modules, and I had a core module where it had no relation to the framework Android. Here, in your case, I believe that the proposal is different, and I like to see other architectural perspectives in this sense, and you do this very well. I would like to see something similar, but consuming an API, it would be interesting. I'll stick to your channel rsrsrs, because I want to learn more from you, you're very good!!!
Thank you very much, appreciated ! Of course you can also make an Android independent module which you can then use in all your projects! Like date calculation stuff or something for example which you need in almost every project, this is also great! This application can be easy converted to an API consuming one, we just need to exchange the underlying data logic from Room to Retrofit for example and stick to the DTO-Objects we have there instead of all the entities. Maybe I will do this next time but with another application use case :-)
Thank you for this tutorial, by the way i have a question , if for example I want to add a deleverer to the list of Deliverer selection , do I have to create another AddDelivererViewModel or use the existing OrderChooseDelivererViewModel ? thank you.
Cool app - just started! Too late now but is "Vendor" the better entity name than "Deliverer"? Deliverer is someone like "UPS" or "FedEx" or "Postal Service". Vendor is like "Amazon", "BestBuy", etc. I think you are using it like a vendor. Names are important.
My dear, let's say that in this same architecture I have an implementation of PagingSource. Could I create a paging package in the core layer or create a package for each class that inherits from PagingSource in its certain feature?
Just finished - very good job. It is tough to explain the different data mappers, multiple product lists and relational tables but you did well sticking with it to the end and demonstrated a full MVVM approach.
Yes indeed it is tough but in a real world app you also have to deal with a lot of different data objects that need to be managed in a clean way without creating a mess. That's why I made this example even tho it consumes a lot of time only for data mapping. A classic note app example with one single data entity would be of course more fun :D Btw your navigation comment is totally right. There lambda functions would be better the different screens don't need to know about the other screens!
This is like hidden gem, this relation data models are worthy watching without another part of video. Maybe you could show us picture in MySqlWorkbench or somehow visualize database.
Thanks for making these videos !!!
Thank you ! Well I first thought about showing an entity relation diagram but the video is already quiet long .. You can try to model it on your own with some graphic editor its not that hard. You have deliverer-order 1:n , deliverer-product 1:n and order-product n:m. The last one results in an additional table
Hey since this is a MVVM architecture tutorial, consider NOT passing the NavController into the individual Screens. The Screens should not need to know about other Screens and the navigation details since that violates the Single Source of Truth. Imagine trying to reuse one of the Screens; you can't if it is hardwired to navigate to certain destinations. It is better to hoist the ""goToOrders" buttonClick back up to your Navigation class, where all the nav details are known and orchestrated.
This is great. Maybe in the future you would show how to do this in a multi-module project .. Thanks!
Yes of course I will do this in the future. This application has already multi module structure the only thing that's left is to apply it to real modules but the video would be too long then ..
@@kapps7407 True. Yes thats great. In a multi module structure each feature is at the top level and has it's own source tree (data/ domain / presentation), Gradle build (build.gradle.kts) and is linked with the 'implementation(project(":core")) / implementation(project(":deliverer-feature")) in the 'dependencies' in the that features 'build.gradle.kts'. Android studio has a "add module" feature that was really pushed by Uber. It works really well for us.
Very helpful video, that is what i needed. If i need function to get and save new oauth token in almost every feature's repository, should i repeat the same code everywhere or create one repository for this in the core package? Or maybe should i create abstract class with this logic in the core package and then extend all repositories with this class?
My dear, great video.
I like how you put together the folder structure for the proposed architecture.
I've worked on an application with modules, and I had a core module where it had no relation to the framework Android.
Here, in your case, I believe that the proposal is different, and I like to see other architectural perspectives in this sense, and you do this very well.
I would like to see something similar, but consuming an API, it would be interesting.
I'll stick to your channel rsrsrs, because I want to learn more from you, you're very good!!!
Thank you very much, appreciated ! Of course you can also make an Android independent module which you can then use in all your projects! Like date calculation stuff or something for example which you need in almost every project, this is also great!
This application can be easy converted to an API consuming one, we just need to exchange the underlying data logic from Room to Retrofit for example and stick to the DTO-Objects we have there instead of all the entities. Maybe I will do this next time but with another application use case :-)
@@kapps7407 Perfect my dear!
With another use case of an application would be great =)
A big hug!
German dev TH-camrs unite 💪
Haha yeah 💪 But you are the grandmaster 😛
Thank you for this tutorial, by the way i have a question , if for example I want to add a deleverer to the list of Deliverer selection , do I have to create another AddDelivererViewModel or use the existing OrderChooseDelivererViewModel ? thank you.
Cool app - just started! Too late now but is "Vendor" the better entity name than "Deliverer"? Deliverer is someone like "UPS" or "FedEx" or "Postal Service". Vendor is like "Amazon", "BestBuy", etc. I think you are using it like a vendor. Names are important.
Yes Mike you are right, thank you
Great video
great job man
Thank you ❤
Thank you 🙏
Sir why you stopped making videos please make
My dear, let's say that in this same architecture I have an implementation of PagingSource. Could I create a paging package in the core layer or create a package for each class that inherits from PagingSource in its certain feature?
What exactly is this PagingSources Responsibility? Give me a little bit more context please :)
Please give the correct name - Entity part is totally confusing like deliverer
dang how does one get this good? crazy stuff just started learning compose but good vid
Thank you mate, keep going!
Please explain whats the deliverer entity?
Vendor oder supplier would be a better name here.