Suggestion on reusable view/layouts & creating BaseActivity

[futurice]

Suggestion on reusable view/layouts & creating BaseActivity

[AizazZaidee]

#################
It's not regarding UI
#################

I am using Inheritance to release memory when my user leaves the UI. Here is what I am doing, you can hopefully get an idea of doing similar things with UI too. Please note that this approach can be drastically improved, waiting for some good suggestion 👍

I have written an Interface in my AppContext that is Inherited from Application class.
public class AppContext extends Application {
private static List memInfoList = new ArrayList<AppContext.IMemoryInfo>();
public static abstract interface IMemoryInfo {
public void goodTimeToReleaseMemory();
}

I have two static methods to register memory hungry activities.

/**
*
* @param implementor
* interested listening in memory events
*/
public static void registerMemoryListener(IMemoryInfo implementor) {
memInfoList.add(implementor);
}

public static void unregisterMemoryListener(IMemoryInfo implementor) {
    memInfoList.remove(implementor);
}

Then I have a method that is called when the user Leaves the UI, it's different than on Pause( )

@OverRide
public void onTrimMemory(int level) {
super.onTrimMemory(level);

    /*
     * Your app is running and not considered killable, but the device is running low on memory and the system is actively killing processes in the LRU cache.
     */
    if (level >= ComponentCallbacks2.TRIM_MEMORY_MODERATE) {
        try {
            // Activity at the front will get earliest than activity at the
            // back
            for (int i = memInfoList.size() - 1; i >= 0; i--) {
                try {
                    memInfoList.get(i).goodTimeToReleaseMemory();
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Then I have an activity parent

public class ActivityParent extends Activity implements AppContext.IMemoryInfo
protected ActivityParent child;

@OverRide
public void goodTimeToReleaseMemory() {
Log.w(TAG, "Low Memory, Relase Now !!!");
}

@Override
protected void onStop() {
    super.onStop();
    try {
        if (child != null)
            AppContext.unregisterMemoryListener(child);
    } catch (Exception e) {

    }
}

@Override
protected void onResume() {     
    super.onResume();       
    try {
        if (child != null)
            AppContext.registerMemoryListener(child);
    } catch (Exception e) {

    }

}

These just some code snippets for grasping the concept, I have also code here to show and hide dialog, dialog creation is expensive operation so I just keep them when I create one.

You might be interested in "Fast Rendering News Feed on Android" https://code.facebook.com/posts/879498888759525/fast-rendering-news-feed-on-android/

[tomkoptel]

@AizazAZ Why so difficult setup for memory management?

So far there is no need to such complicated means. I suggest instead of your approach to track down memory leaks. Square has invented an excellent tool for this case. Take a look on this leakcanary.

[eneim]

IMO creating a BaseActivity is a good idea. At least for migrating your code base. For example, when you don't have your BaseActivity, and implement all your Activity classes extending (for Example) ActionBarActivity, it's a headache to migrate all of them to AppCompatActivity though.

Well it's just a really sample stuff you may not mind to care. But in general, I think it's usual to have your Activity classes share some same feature (all create and setup a toolbar, etc.), so BaseActivity will be a good choice. Nevertheless, what your loss is only an extra file (if you well manage your app).

[peter-tackage]

I also highly recommend the use of Leak Canary to track down memory leaks. Our best practices document doesn't reflect this yet, as the library is relatively new, but many of our projects already use it.

As for BaseActivity, I would say that using them is inevitable when using multiple Activity app, whether it be for logging, dependency injection, session state checking, generic data subscription etc etc. Some good general advice is to use composition where possible rather than relying solely on inheritance. Encapsulate the behaviors you want into modularized classes (to faciliate testing) and then include them in the BaseActivity, rather than writing the behaviors entirely in the BaseActivity. This will make it easier to change your structure later if required. The deeper your Activity class hierarchy, the more difficult debugging and maintenance becomes.

Reuse of view/layouts is encouraged - there will less XML to maintain. Refer to the official docs for instructions: http://developer.android.com/training/improving-layouts/reusing-layouts.html