patternjavaMinor
Android app with config and customization classes
Viewed 0 times
androidappwithcustomizationconfigclassesand
Problem
I have an Android app with three different
I like this approach because it simplifies getting the
Activity classes. Each of the Activities uses and changes config and user-customization data stored in a wrapped SharedPreferences. The code could stand some refactoring, so I'm thinking that rather than have each Activity instantiate the SharedPreferences by calling PreferenceManager.getDefault... in their constructors, I can make a 'base' abstract Activity to serve as a parent class and then have each of the Activities subclass the abstract Activity and wrap the SharedPreferences in an inner class of the abstract Activity, like so:public abstract class AbstractBaseActivity extends AppCompatActivity
{
private static AppPrefs instance;
private interface PrefKeys
{
String KEY_BOOL_SETUP = "KEY_BOOL_SETUP";
String KEY_STR_USER_EMAIL = "KEY_STR_USER_EMAIL";
String KEY_LONG_LAST_EMAIL_SENT = "KEY_LONG_LAST_USE";
//...remaining keys omitted...//
}
public static class AppPrefs implements PrefKeys
{
private SharedPreferences prefs;
private String no_email;
private AppPrefs(AbstractBaseActivity activity)
{
prefs = PreferenceManager.getDefaultSharedPreferences(activity);
no_email = activity.getString(R.string.no_email);
}
public static AppPrefs getInstance(AbstractBaseActivity activity)
{
if(instance == null)
{
instance = new AppPrefs(activity);
}
return instance;
}
public String getUserEmail()
{
return prefs.getString(AppPrefs.KEY_STR_USER_EMAIL, no_email);
}
public boolean setUserEmail(String email)
{
return prefs.edit().putString(AppPrefs.KEY_STR_USER_EMAIL, email).commit();
}
//... getter/setter methods to modify the SharedPreferences ...//
}
}I like this approach because it simplifies getting the
SharedPreferences. I just callSolution
Public class, private Interface?
I'm pretty confused by this setup.
The meaning is always trying working towards the most highest object( this case interface) possible.
I'm thinking that you created this setup so having the keys as constants.
But there is nothing wrong to have those keys as
Java singleton.
I can't repeat it enough but if you want a singleton, please think
Your singleton isn't thread safe or
Abstract class root of all evil?
While I do use abstract classes, I'm always thinking also about putting the abstract methods in an interface and use that interface in the constructor.
This has multiple advantages of the abstract class.
First of all, you can create the base class final so no unexpected behavior could be implemented later on.
Then the interface you can swap at runtime (don't forget a check on
As I don't see the whole picture here I can't say it's good or not in this case.
But still, think about it, see the advantages/disadvantages and make your conclusion if it's good in this case or not.
I'm pretty confused by this setup.
The meaning is always trying working towards the most highest object( this case interface) possible.
I'm thinking that you created this setup so having the keys as constants.
But there is nothing wrong to have those keys as
private static final String in your class self.Java singleton.
I can't repeat it enough but if you want a singleton, please think
enum in stead of private constructor.Your singleton isn't thread safe or
Serializable in this case, while if you use enum it is, and it's even easier to created it.Abstract class root of all evil?
While I do use abstract classes, I'm always thinking also about putting the abstract methods in an interface and use that interface in the constructor.
This has multiple advantages of the abstract class.
First of all, you can create the base class final so no unexpected behavior could be implemented later on.
Then the interface you can swap at runtime (don't forget a check on
null) and your class behave different but still in the correct way.As I don't see the whole picture here I can't say it's good or not in this case.
But still, think about it, see the advantages/disadvantages and make your conclusion if it's good in this case or not.
Context
StackExchange Code Review Q#103971, answer score: 5
Revisions (0)
No revisions yet.