Android: persisting data across app lifecycle

Issue

I'm working on an Android app that uses some background tasks (AsyncTasks) and I want to use best practices regarding data persistence across app lifecycle and tasks callbacks.

Up to now, I have a mix of practices regarding this:

1) I have some static fields in classes where AsyncTasks are used in the form of:

private static String str1;
private static String str2;
private static int int1;
...//=>no more than 6 static fields

2) I use a sinleton App instance with many getters/setters in the form of:

package xxx.xxx.xxx

import xxx.xxx.xxx
...

public class AppSettings {

    private static AppSettings singleton;
    private String _field1;
    ...//=>many fields

    public void setField1(String field1) { _field1 = field1; }
    public String getField1() { return _field1; }
    ...//=>many getters/setters

    private AppSettings() {}

    public AppSettings getInstance(){
        if (instance== null) {
            synchronized(AppSettings.class) {
                if (instance == null)
                    instance = new AppSettings();
            }
        }
        return instance;
    }
}

I definitely know that abusing of static fields is not good at all, so I decided to replace them all, but I'm not completely sure if my second approach -having an application instance in a singleton with many getters/setters- is considered a good way to go, and in case not, I would like to know about better alternatives.

Thank you very much.

Edit 1: Just to clarify.

In order for you to understand more clearly what I use my AppSettings singleton class for I'll give you two examples:

1) I use it to store app setting/configuration values (that's why the name) to be available anywhere. For example, font color, font size, whatever.

2) I use it to store temporary data/values. For example, my main activity creates a small video in the backgroung using "VideoHelper" class and called through an AsyncTask, and as video generation process needs some parameters from main activity, I use AppSettings getters/setters to send them through.

Edit 2: Better explanation of everything.

Thanks to @a_local_nobody I realized my "case of use" was not so clear so I'll add a few things more.

My AppSettings is not being used to store user settings, I use SharedPreferences for that, but instead app default configuration parameters.

To give an example, I store activities background color (and this is just an example) so if in the future I change my mind and decide to use another background color this setting (and many more) are centralized there. It's like a "container" for many default app settings.

Regarding the use of getters and setters in this app singleton class, I think I'll foloww @a_local_nobody suggestion related to define some static variables in each class and use them as needed instead of having a bunch of unrelated getters/setters globally.

Anyway, all comments are welcome.

Solution

Well, you are talking about persisting data across app lifecycle which, in my mind, sounds like you're looking for a ViewModel:

The ViewModel class is designed to store and manage UI-related data in a lifecycle conscious way. The ViewModel class allows data to survive configuration changes such as screen rotations.

as well as:

The purpose of the ViewModel is to acquire and keep the information that is necessary for an Activity or a Fragment. The Activity or the Fragment should be able to observe changes in the ViewModel.

ViewModels form part of the MVVM design pattern, with loads of examples available online.

For more info, have a look at the documentation

---

on a side-note, perhaps you can have a look at the google sunflower project for some ideas on how to implement the new architecture components, which includes usages of ViewModels.

---

Also worth adding, is that what you've created with your AppSettings solution, is a big dependency. Various things will depend on this single object and it will be needed throughout your application, most likely. You might consider, instead of creating it like this, to rather use dependency injection with your options, for android, probably being either Dagger 2 or Koin for kotlin (if you ever swap over to kotlin) or perhaps your own form of dependency injection without having to use these frameworks.

Hope this helps

---

Edit based on feedback from OP:

I use it to store app setting/configuration values (that's why the name) to be available anywhere. For example, font color, font size, whatever.

this sounds like a better use case for Shared preferences, especially if these are settings defined by a user, otherwise you should be savings these into strings.xml etc. and making use of localization

I use it to store temporary data/values. For example, my main activity creates a small video in the background using "VideoHelper" class and called through an AsyncTask, and as video generation process needs some parameters from main activity, I use AppSettings getters/setters to send them through.

if you have a VideoHelper class, you might be better off either creating a Builder design pattern for this object, or having static variables for this helper to change its functionality as you need to, if these are variables for your VideoHelper, then they should be located with your VideoHelper.

Things which change together should usually stay together.

Answered By - a_local_nobody