using MVVM or MVP should i name packages like model, viewmodel, view and put proper classes and interfaces there or is it just a logical structure that should not be visible in classes structure?
If you want to go by the book, the current "correct" way to implement MVVM in Android is the Android Architecture Components set of libraries.
Read more about it here, and try this code lab. These will also show you how to name and place your classes.
But in general, you should go with what matches your app best. For smaller apps I would recommend going with M V P folders, while for bigger, more long-term ones tend to work better with folder-per-feature structure.
Google in it's sample Android Architecture project uses Model(Data) V(views) VM(view-models) file structure
Google sample sunflower app to show architecture components
Probably that's the best approach
Additionnaly you may find this resource interesting https://overflow.buffer.com/2016/09/26/android-rethinking-package-structure/
An implementation is visible here https://github.com/SamYStudiO/beaver
I also would like to indicate watching this TUTORIAL.
This guy goes well on teaching about the Architecture MVVM and also uses the ROOM Persistence Library.
It is worth giving a look at it.
Related
I'm a self-taught android developer, I want to work as an android developer but I have some imposter syndrome. I think there should be coding conventions we should follow when we code, like:
Follow any architecture (MVP or MVVP)
Coding best practices (https://kotlinlang.org/docs/coding-conventions.html)
Using architecture components like LiveCycle, LiveData, Room, etc ...
Design with XML? (For now, I just export images and use them as design, an example: Here)
etc ...
I search on internet about coding convention and I only found this https://kotlinlang.org/docs/coding-conventions.html (Are they the only standars I need to follow ?)
I also try to look for professional android project I could read, but The only one I found on github is this one : https://github.com/Yazan98/Wintrop (And I don't know if I can take it as reference).
Can I still be hired without this knowledge**? If I need to learn them, what else should I learn to match industry standards? What information should I know about industry standards as a self-taught android developer?**
Thank you for your help!
No, standards there are several for example Modern Android App Architecture that I highly recommend you but also you can find something else like Guide to Android app modularization which is also important in the modern android applications creation.
For projects you can look at nowinandroid which is just very well done and this too it's some models that google's engineers have made for new learners it's really very well done all the standards are respected and they use the new technology in this project like jetpack compose instead of old XML, Room for local data storage, DataStore for preferences, Firebase...
I highly recommend these links
Am working on a huge android project that has more than 50 APIs request
and using the MVVM pattern, My question is:
can I add all the requests in the same app repository or I must create a repository for each service?
As others suggested in the comments you should first define the modules of your app and then create the corresponding Repositories. This way you can easily maintain and test your application.
I strongly suggest you to have a look on this https://github.com/nickbutcher/plaid and mostly this video https://youtu.be/Sy6ZdgqrQp0
A good solution to this problem is, You must not implement all your API calling code to the same repository as it will become a massive single repository class. It will also be violating design principles i.e. rule of 30 as you are saying you have at least 50 APIs to work with.
Also, it is not a good practice to modify a class, again and again, see Open Close Principle.
You can make multiple API calling classes under the same package name.
Another "which is better" question, I know these are highly subjective. My definition for better would be:
Being used by the best dev teams
Best for unit testing
Most modular / easiest to build out a prod app
What Google recommends (this is where I'm most confused)
All of the Android blueprints use package-by-feature:
https://github.com/googlesamples/android-architecture
/tasks
/addedittask
/taskdetail
and all of the architecture components samples using package by layer:
https://github.com/googlesamples/android-architecture-components
/db
/model
/ui
/persistence
I'm confused because at the bottom of the Architecture Components site, it actually has links to the Android MVP and MVVM blueprint samples, which seems to me to be contradictory.
Based on Android Architecture guide, and on Clean Architecture, I would suggest this approach
data/
model/
remote/
local/
Repository
domain/
usecases/
GetUserListUseCase
presentation/
screen1/
screen1Activity
screen1Fragment
screen1ViewModel
screen2/
screen2Activity
screen2Fragment
screen2ViewModel
core
common/
di/
More here: https://www.toptal.com/android/android-apps-mvvm-with-clean-architecture
I think it depends on project size. Also in different companies team use different approaches.
I prefer to use in a small project second type of package managing.
If you want to reuse ModelView component, just keep them in feature packages. And maybe with this type:
/db
feature1/
feature2/
/model
feature1/
feature2/
/ui
/persistence
feature1/
feature2/
I'd like to know if I'm using Clean Architecture the right way. I am trying to lay it like this diagram:
I've read that the package structure should be arranged by use case but I'm having difficulty following how that would be done.
Let's take a look at my package structure:
notice I don't know where to really put the activities in the UI folder, could you recommend ? does it matter?
In the data folder, I have my repositories I use for repository design pattern.
my retrofit network calls are on the same level as the UI folder. likewise for my dependency injection framework.
My concern comes after reading this publication I am now wondering if I did the package structure correctly?
One aspect Uncle Bob is emphasizing is that the clean architecture is screaming. That means that the top-level structure and names should express your business domain and not technical details and frameworks u use. On the second level we should separate the different circles.
In an e-commerce app things like cart, search and product catalog would shape the top-level structure. Use cases, controller and presenters would be on the second level.
I have blogged about this with more detailed example: Implementing Clean Architecture - Make it scream.
I would suggest you have a look to this repository. You can have a lot of feedback from the discussions in the issues section. I'll would read specially this discussion.
Now in orther to answer your question.
Does it matter? I would say no, it does not matter. Package structure is only a convinient way to structure your code to make it more readable and mantaiable. As long as you respect the Clean-Architecture principles it does not matter where you have your classes. Remember you can always do a refactor while you are progressing and your project is growing.
Where to put activities? If you already separate your UI package in components, you should stick to it and have an activities folder.
Recomendations: first I like to have one package or even a module for each layer (e.g. data, domain, presentation, infrastructure...) then within each package you can make your own decisions that you prefer. For example, I like to separate the presentation layer into features but the domain and data layer by components. The benefits of having one module for each layer is that if a new developer is going to contribute to the project you can enforce the clean architecture principles since they wont be able to reference a data class inside a domain usecase.
I'm working on an Android project and I would like to know any recommendations about what's a good architecture to build an android application.
I want to use dependency injection using Roboguice and I've been reading about MVVM pattern or MVC pattern (Android MVVM Design Pattern Examples).
Also I know that roboguice have a pretty cool Context-Based Event's raising and handling feature that could be very testable as the code is decoupled.
Any recommendations on a working design pattern? a testable and scalable architecture you have worked with or developed?
The Android platform provides a common set of design patterns, and with the limited hardware resources you get compared to Web-apps it is still often best to stick with using these directly in production code. There are other frameworks that sort of "wrap" the base platform; these are worth looking into if you have a specific purpose (or perhaps for prototyping/experimenting), but for the best level of support you are generally best sticking with the standard components.
This is a great resource when working on UI solutions: http://www.androidpatterns.com/
Specifically for DI: There is a Spring framework for Android, I've had a play with it and it looks quite promising. You've already mentioned Roboguice as another alternative to this. However, to avoid performance and library overhead, I still find the easiest approach is to write a simple reflection-based class that registers and injects dependencies within my own code. Similar to this approach, except I usually move the injection code into a separate singleton and reference it from there.
In my experience most of the third-party offerings are not yet mature enough to rely on right now, and don't really give you much on top of what the base platform provides. They are constantly progressing, however, so be sure to experiment with the big names from time-to-time.