That soft explanation about Android app architecture was kind of sublime, sir... Really!
Avoiding some might complex architectural concepts as Flux or Redux, for example, allows a easy compreension of our need to think what we should consider when building something.
I'd add just a detail about MVC. A lot of Android apps are just some kind of frontend component in a bigger architectural perspective, so the MVC you suggest makes sense. However, if the app purpose is to be a "single point" connected with some kind of datasource (files, databases, web services, etc.), I suppose the model can follow a Domain Driven Design, where you apply the Business Logic on your models (where you can/cannot use it to handle data, as well, or apply other kind of layer responsible for that business logic.).
Anyway, it was a refreshing way to study some of the complexity around Android app architecture.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That soft explanation about Android app architecture was kind of sublime, sir... Really!
Avoiding some might complex architectural concepts as Flux or Redux, for example, allows a easy compreension of our need to think what we should consider when building something.
I'd add just a detail about MVC. A lot of Android apps are just some kind of frontend component in a bigger architectural perspective, so the MVC you suggest makes sense. However, if the app purpose is to be a "single point" connected with some kind of datasource (files, databases, web services, etc.), I suppose the model can follow a Domain Driven Design, where you apply the Business Logic on your models (where you can/cannot use it to handle data, as well, or apply other kind of layer responsible for that business logic.).
Anyway, it was a refreshing way to study some of the complexity around Android app architecture.