Android Architecture: Difference between revisions
Jump to navigation
Jump to search
Line 25: | Line 25: | ||
==Clean Architecture== | ==Clean Architecture== | ||
[[File:Android Clean Arch.png|800px]] | [[File:Android Clean Arch.png|800px]] | ||
=Application Tidy Up = | |||
==Step 1== | |||
* Created TrackerActivity which extends AppCompatActivity and will be now good for other activities | |||
* Move Tracker to its own class and implement the Lifecycle Observer interface | |||
*When using lifecycle observer we need to remote it on destory | |||
<syntaxhighlight lang="java"> | |||
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY) | |||
public void trackOnDestroy() { | |||
Log.d(TAG, "trackOnDestroy called"); | |||
((AppCompatActivity) con).getLifecycle().removeObserver(this); | |||
// mQueue.add(generateTrackingStringRequest("destroy")); | |||
} | |||
</syntaxhighlight> |
Revision as of 14:06, 20 December 2020
Architecture
Typical Android apps look like this
And this
Here is an overview of the app prior to looking at it
Looking at this I am building an app with the architecture of
The was discussion on god class which I had not heard before
- Contains a high number of components
- Components are coupled
- Lengthy class
Avoid a all costs or don't cos I like getting rid of them
Design Patterns
Just a reminder of the design patterns but with maybe a more Android flare.
MVC
MVP
MVVM
Summary
Clean Architecture
Application Tidy Up
Step 1
- Created TrackerActivity which extends AppCompatActivity and will be now good for other activities
- Move Tracker to its own class and implement the Lifecycle Observer interface
- When using lifecycle observer we need to remote it on destory
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void trackOnDestroy() {
Log.d(TAG, "trackOnDestroy called");
((AppCompatActivity) con).getLifecycle().removeObserver(this);
// mQueue.add(generateTrackingStringRequest("destroy"));
}