Android Legacy. Part 2
In the first part of our article we started to look at a template we can use for Android legacy projects. Let’s continue our discussion on the issue.
Related articles
Other articles
How to do Indexing in MongoDB with Elastic Search? Part 2
How to do Indexing in MongoDB with Elastic Search? Part 1
How to store data on browser using NoSQL IndexedDB?
How to Apply MBTI in HR: Motivation for every day. Groups of People & their Motivations
Check out our new courses
How to query time increase in Impala?
How to Apply MBTI in HR: Motivation for every day
Object-relational Mapping Using JPA, Hibernate and Spring Data JPA. Comparing the performance of persisting entities
How to implement Matrix Multiplication using Map-Reduce?
Object-relational Mapping Using JPA, Hibernate and Spring Data JPA. Comparing the approaches of persisting entities
In the first part of our article we started to look at a template we can use for Android legacy projects. Let’s continue our discussion on the issue.
Add Frameworks as Needed
Go easy on refactoring, isolate
Sometimes it’s easy to come to terms with the real world: don’t refactor what is working – just isolate, provide a wrapper if needed, and build around what is really required.
It can be very easily done in Android:
Respect Android Framework
First of all, respect the Android framework. If contains only 5 main components to build the work of the entire application:
Use components so that they can “host” your control/data objects, with an eye on the life cycle, how long this or that Android component must/can live.
We praise the daring of all bold dreamers
I think legacy projects are excellent grounds for learning and mastering your skills. It’s a gold-mine of illustrative examples of how various approaches can lead to problems. Every Android developer must, sooner or later, unravel the “classical Android tangle” of Activity, AsyncTask, absent DataLayer, etc.
Ivan Alyakskin
Android Legacy
Add Frameworks as Needed
- Dagger can help to manage the dependency graph
- RxJava is good for complex sequence and asynchronous operations
- MVC/MVP/MVVM for easy keeping the code in order and simple testing
Go easy on refactoring, isolate
Sometimes it’s easy to come to terms with the real world: don’t refactor what is working – just isolate, provide a wrapper if needed, and build around what is really required.
It can be very easily done in Android:
- Use stand-alone Activity/Fragment
- Use separately run IntentService
Respect Android Framework
First of all, respect the Android framework. If contains only 5 main components to build the work of the entire application:
- Activity – for creating the UI and getting user actions
- Service – for long-living components used on different screens
- ContentProvider – for data handling in the style of “REST”
- BroadcastReceiver – for getting events (one should be very careful with them)
- Application – a global context, “a friend who will always be with you.”
Use components so that they can “host” your control/data objects, with an eye on the life cycle, how long this or that Android component must/can live.
We praise the daring of all bold dreamers
I think legacy projects are excellent grounds for learning and mastering your skills. It’s a gold-mine of illustrative examples of how various approaches can lead to problems. Every Android developer must, sooner or later, unravel the “classical Android tangle” of Activity, AsyncTask, absent DataLayer, etc.
Ivan Alyakskin
Android Legacy