1. Home
2. Blog
3. 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.

 

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.