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.

Ivan Alyakskin
Android Legacy