Intial #1
Intial #1
Conversation
There was a problem hiding this comment.
- Overall I think everything is very good. Good job! I liked the
blink22_boilerplatename BTW. - I believe the sample followed is not that much organized. This might be reflected in that it somewhat has a few stars on github and a few claps on its related medium articles:
- I believe other highly starred samples are more organized. Check
- Mindorks
- Bourbon
- Google Todo
At the end of the day, having different point of views doesn't mean that someone is right and the other is wrong. But it will lead us to have a better decision. We may discuss more in the next meeting. CC @engmonsh
| @@ -0,0 +1,10 @@ | |||
| *.iml | |||
There was a problem hiding this comment.
Sure we can modify it and this file is really helpful we can use it as a Ref
|
|
||
| // Dependencies Section | ||
|
|
||
| libraries = [ |
There was a problem hiding this comment.
good point and we can work on that to make it look more understandable but I have one comment regarding this link as you see there are many dependence repeated I know this is for the sake of modularization but I don't know if this is good or not we can discuss that further more
| import com.tapadoo.alerter.Alerter; | ||
| import com.tapadoo.alerter.OnHideAlertListener; | ||
|
|
||
| public abstract class BaseActivity extends AppCompatActivity implements BaseView{ |
There was a problem hiding this comment.
@mhemdan I think we can use IcePick in the base activity and all the extending ones won't suffer from having the state parameters nulled once the activity destroyed. Check the library Readme file
| - core : contains almost all app logic pure java -> presenters - api client - models | ||
|
|
||
| ## Code Standards | ||
| [Code Style](.github/CodeStyle.md) |
There was a problem hiding this comment.
this code style was only for unifying naming conventions but for sure we can use this plugin too as it has many stars.
| @@ -0,0 +1 @@ | |||
| /build | |||
There was a problem hiding this comment.
@mhemdan Although I totally agree with distributing the code among different modules, I believe we can categorize code in modules in a more arranged way. I believe it may be more organized to have a module handling the model & presentation code and another one handling the view code.
Check the attached screenshot from this project
| import dagger.Provides; | ||
|
|
||
| @Module | ||
| public class ExampleModule { |
There was a problem hiding this comment.
@mhemdan I believe the DI classes, e.g Modules & Components, need to be in a separate package rather than being distributed among different packages. I found many projects, Google Todo, Mindorks, and Bourbon doing this. Check the attached screenshot from this project
|
Nice work Hemdan. |
No description provided.