Develop Reference

Android : SharedPreferences and MVC pattern

I'm developping my app using the MVC pattern. To store/access data, my controllers use a class named "DataStorage", and for now this class allows to store/access simple parameters about my app (username, data storage path, ...). In other words, I want to call a few methods like "getParameter(String key)" or "setParameter(String key, String value)".
I think SharedPreferences would be the most convenient way to store these parameters, so my get/setParameters use this class.
In all the examples I have seen, SharedPreferences is called from an Activity and there is no problem to call methods such as "getSharedPreferences" or "getApplicationContext"/"getContext". Because my DataStorage class is not an activity, for now I ask my first activity to give its context when creating a new DataStorage instance, and it works well to store my parameters. My problem : I want to be able to remove parameters from another activity using clear + commit methods. But it doesn't work (parameters are still there), and I think the reason is I give the 2nd activity context when creating another instance of DataStorage. The problem might be something else though, I've been practicing Android for only 2 days now...
To summarize how my app works :
Activity 1 creates a DataStorage class and provides its context to the DataStorage constructor. The DataStorage might store a parameter into a SharedPreferences file (or not...)
When I run my app again, if a particular parameter is set in the SharedPreferences file, then I start Activity 2 instead of Activity 1. Using the menu on Activity 2, I want to be able to clear the SharedPreferences file (in order to get Activity 1 again when I restart the app), so I create another DataStorage instance (and I provide Activity 2 context) and I call the method to clear all parameters.
As I said, first part works well (I can store parameters), but clear & commit do nothing to my SharedPreferences file.
I don't want to put a piece of code for this directly in my activities.
Can you help me with this ? What am I doing wrong in the way I use SharedPreferences ?
Thank you for your help !
Edit :
public class DataStorage {
private Context context;
private String settingsFilename;
private SharedPreferences settings;
public DataStorage(Context activityContext, String filename) {
context = activityContext;
settingsFilename = filename;
settings = context.getSharedPreferences(settingsFilename, Context.MODE_PRIVATE);
}
public void newSharedPreference(String key, String value) {
settings.edit().putString(key, value).apply();
settings.edit().commit();
}
public String getSharedPreference(String key) {
return settings.getString(key, null);
}
public void clearPreferences() {
settings.edit().clear();
settings.edit().commit();
Toast.makeText(context,settings.toString(), Toast.LENGTH_LONG).show();
}
}
In my first activity (the code is part of onCreate method) :
DataStorage storage = new DataStorage(this, getResources().getString(R.string.sharedPreferencesFile));
username = storage.getSharedPreference("username");
Toast.makeText(this, username, Toast.LENGTH_LONG).show();
if (username != null) {
Intent nextActivity = new Intent(this, ActivityMainMenu.class);
startActivity(nextActivity);
} else {
setContentView(R.layout.activity_name);
}
In my 2nd activity :
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
switch(id) {
case R.id.action_clearSharedPref :
storage.clearPreferences();
break;
case R.id.action_leave :
System.exit(RESULT_OK);
}
return super.onOptionsItemSelected(item);
}
(Storage is constructed exactly as I did in my first Activity)
I tried to replace "this" by getApplicationContext() in DataStorage constructor, but it didn't work.

From Editor Class Overview
Interface used for modifying values in a SharedPreferences object. All changes you make in an editor are batched, and not copied back to the original SharedPreferences until you call commit() or apply().
You need to update to change methods at your DataStorage
public void newSharedPreference(String key, String value) {
settings.edit().putString(key, value).apply();
}
and
public void clearPreferences() {
settings.edit().clear().apply();
Toast.makeText(context,settings.toString(), Toast.LENGTH_LONG).show();
}
Reason of issue is next
settings.edit().clear(); // clear is ok, but it won't be saved because
settings.edit().commit(); // create new editor and commit nothing

Custom font for Preferences

I used the code posted in this answer to try and set my preferences a different style (namely the font typeface and size), and it does indeed set the font properly. The problem with this code is, it extends the base Preference class, so I cannot create specific preferences (ListPreference, CheckboxPreference, etc.) and I'm stuck with basic preference objects, which I don't even know whether they have any proper use in terms of user interaction.
Now I could extend every Preference class I use to include the code in CustomPreference, but that seems like bad practice to me. Since there's no multiple inheritance in Java, is there any solution (perhaps any OO workaround) that can add this styling functionality to my CheckBoxPreferences, ListPreferences, PreferenceScreen, etc.?

You could use a Util-type class with public static methods. You'd have to extend each preference class you use still, but you could defer things like setStyleAlarmed to the Utils class instead of having the same code in each custom preference class.
public class PreferenceUtils {
public static void onBindView(View view) {
switch (style) {
case STYLE_ALARMED:
setStyleAlarmed(view);
break;
case STYLE_NORMAL:
setStyleNormal(view);
break;
case STYLE_WARNING:
setStyleWarning(view);
break;
//...
}
}
// Move other methods here, e.g. setStyleAlarmed().
}
public class CustomPreference extends Preference implements PreferenceStyle {
#Override
protected void onBindView(View view) {
super.onBindView(view);
PreferenceUtils.onBindView(view);
}
}

How to desing a reusable DialogFragment

There is some questions already close to this question but they haven't been very helpful for me. So here comes a new one.
I have an Activity which has two tabs. Each tab contains a ListFragment (SherlockListFragment to be exact). One tab shows a list of shopping list objects and the other shows a list of recipe objects. Now I want to create a DialogFragment for renaming a list or a recipe or any other object I might later add to the application.
The solution provided here sounded promising but because ListFragment can not be registered to listen clicks from the dialog I should make my Activity to listen them which is not ideal because then my Fragments would not be independent.
How to get data out of a general-purpose dialog class
Ideally I would like to have my rename dialog as independent and reusable as possible. This far I have invented just one way to do this. Sending the objects className and id to the dialog and then using switch case to fetch the correct object from the database. This way the dialog would be able to update the objects name by itself (if the object has rename method). But the requery to the database sounds just dump because the ListFragment has the object already. And then the dialog would need a new case in the switch for each new kind of object.
Any ideas?

I actually just created a similar sort of dialog fragment to what you're asking about. I was for a fairly large app and it was getting kind of ridiculous the amount of dialog listeners our main activity was extending just to listen for the results of a single dialog.
In order to make something a bit more flexible I turned to using ListenableFuture from Google's Guava concurrent library.
I created the following abstract class to use:
public abstract class ListenableDialogFragment<T> extends DialogFragment implements ListenableFuture<T> {
private SettableFuture<T> _settableFuture;
public ListenableDialogFragment() {
_settableFuture = SettableFuture.create();
}
#Override
public void addListener(Runnable runnable, Executor executor) {
_settableFuture.addListener(runnable, executor);
}
#Override
public boolean cancel(boolean mayInterruptIfRunning) {
return _settableFuture.cancel(mayInterruptIfRunning);
}
#Override
public boolean isCancelled() {
return _settableFuture.isCancelled();
}
#Override
public boolean isDone() {
return _settableFuture.isDone();
}
#Override
public T get() throws InterruptedException, ExecutionException {
return _settableFuture.get();
}
#Override
public T get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException {
return _settableFuture.get(timeout, unit);
}
public void set(T value) {
_settableFuture.set(value);
}
public void setException(Throwable throwable) {
_settableFuture.setException(throwable);
}
// Resets the Future so that it can be provided to another call back
public void reset() {
_settableFuture = SettableFuture.create();
}
#Override
public void onDismiss(DialogInterface dialog) {
// Cancel the future here in case the user cancels our of the dialog
cancel(true);
super.onDismiss(dialog);
}
Using this class I'm able to create my own custom dialog fragments and use them like this:
ListenableDialogFragment<int> dialog = GetIdDialog.newInstance(provider.getIds());
Futures.addCallback(dialog, new FutureCallback<int>() {
#Override
public void onSuccess(int id) {
processId(id);
}
#Override
public void onFailure(Throwable throwable) {
if (throwable instanceof CancellationException) {
// Task was cancelled
}
processException(throwable);
}
});
This is where GetIdDialog is a custom instance of a ListenableDialogFragment. I can reuse this same dialog instance if needs be by simply calling dialog.reset in the onSuccess and onFailure methods to ensure that the internal Future gets reloaded for adding back to a callback.
I hope this helps you out.
Edit: Sorry forgot to add, in your dialog you can implement an on click listener that does something like this to trigger the future:
private class SingleChoiceListener implements DialogInterface.OnClickListener {
#Override
public void onClick(DialogInterface dialog, int item) {
int id = _ids[item];
// This call will trigger the future to fire
set(id);
dismiss();
}
}

I would maybe just using a static factory pattern of some variation to allow dynamic initialization of the DialogFragment.
private enum Operation {ADD, EDIT, DELETE}
private String title;
private Operation operation;
public static MyDialogFragment newInstance(String title, Operation operation)
{
MyDialogFragment dialogFragment = new DialogFragment();
dialogFragment.title = title; // Dynamic title
dialogFragment.operation = operation;
return dialogFragment;
}
Or.. and I would recommend this more, have a static factory method for each type of operation you will use it for. This allows different dynamic variations to be more concrete and ensures that everything works together. This also allows for informative constructors.
Eg.
public static MyDialogFragment newAddItemInstance(String title)
{
MyDialogFragment dialogFragment = new DialogFragment();
dialogFragment.title = title; // Dynamic title
return dialogFragment;
}
public static MyDialogFragment newEditItemInstance(String title)
{
MyDialogFragment dialogFragment = new DialogFragment();
dialogFragment.title = title; // Dynamic title
return dialogFragment;
}
And then of course create an interface that every calling Activity / Fragment (in which case you need to set this Fragment as the targetFragment and get reference to that target Fragment in your DialogFragment) so that the implementation is taken care of in the target Fragment and nothing to do with the DialogFragment.
Summary: There are various ways of going about this, for simplicity, I would stick with some form of static factory pattern and make clever use of interfaces to separate any the logic from the DialogFragment hence making it more reusable
EDIT: From your comment I would suggest you look at two things:
Target Fragments (See the comment I made on your question). You can invoke methods in your ListFragment from your DialogFragment.
Strategy Pattern. How does the Strategy Pattern work?. This allows you to perform the same operation (with various tailored implementation for each type) on different objects. Very useful pattern.

Cannot save Shared preferences, it crashes because the context is null, fragment already replaced

The app was first made with activities, but because of an issue, I have to use 2 fragments with an FragmentManager instead. Now, because of this I had to refactor a lot of code.
So my 2 fragments are an videoplayerfragment and videoRecorderFragment.
Sometimes I send an request to get via a JSON, the list of videos in the videoPlayer, and if I want to make a video, I change the fragment. Now if the response is late, I will get the OnSuccess of the request, trying to save the credentials, but the context of the videoplayer is null, because I have replaced the fragment.
This is part of the UserCredentialsPersistence class:
private static SharedPreferences obtainSharedPreferences(Context context) {
return context.getSharedPreferences(USER_CREDENTIALS_KEY,
Context.MODE_PRIVATE);
}
public static boolean saveToDownloadCount(Context context,
int download_count) {
Editor e = context.getSharedPreferences(USER_CREDENTIALS_KEY,
Context.MODE_PRIVATE).edit();
e.putInt(USER_TO_DL_COUNT_KEY, download_count);
return e.commit();
}
This is the important part of the VideoPlayerFragment:
videoRequest.requestNotification = new RequestNotification() {
#Override
public void onSuccess(Object sender) {
Log.d("#VideoPlayerActivity", "success");
playHideUpAnimation();
new_videos = new ArrayList<VideoData>(VideoDataManager.getInstance().getNewVideos());
UserCredentialsPersistence.saveToDownloadCount(getActivity(), UserCredentialsPersistence.restoreToDownloadCount(getActivity()) + new_videos.size());
all_videos = videodb.getTotalVideoListFromDB();
Here it crashes because the getActivity is null when calling any method from UserCredentialsPersistence.
I have also tried to call it from the FragmentManager:
OnSuccess at the requestNotification calling:
((VideoHolderActivity) getActivity()).saveToDLCount(new_videos.size());
And this being:
public void saveToDLCount(Integer size){
UserCredentialsPersistence.saveToDownloadCount(VideoHolderActivity.this, UserCredentialsPersistence.restoreToDownloadCount(VideoHolderActivity.this) + size);
}
But still, the context is null. Any idea how I can get past this?

I created a BaseFragment class. All my Fragments extend this class. And in this class I have a
interface, which is implemented by my FragmentNavigator.
Then i simply call from the fragments the functions that i need from the FragmentManager. Here i have put all the functions that need context. And after getting the response from them, i send it back into the fragments, by doing a cast to the current fragment i use.

Managing activity from DialogFragment

How can I call finish() and other non static methods from a DialogFragment in the activity that created it? I have tried passing messages from the OnClickLisener in the DialogFragment, to no avail.
I have a really simple app, conssting of a MainActivity and DialogFragment:
public class MainActivity extends Activity {
#Override
protected void onCreate(Bundle arg0) {
super.onCreate(arg0);
setContentView(R.layout.activity);
showDialog();
}
public void showDialog() {
DialogFragment newFragment = new ConfirmDialog();
newFragment.show(getFragmentManager(), "dialog");
}
}
And the Dialog is again very simple:
public class ConfirmDialog extends DialogFragment {
#Override
public AlertDialog onCreateDialog(Bundle savedInstanceState) {
// Use the Builder class for convenient dialog construction
AlertDialog.Builder builder = new AlertDialog.Builder(getActivity());
builder.setMessage("Confirm you want to continue?")
.setPositiveButton("Yes.", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
//finish() MainActvity
}
})
.setNegativeButton("No.", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
//Do nothing in MainActity
}
});
// Create the AlertDialog object and return it
return builder.create();
}
}

There are many options. One of them is define an interface with a single method inside.
Have the dialog caller implement that interface.
Keep a global variable pointing to the caller.
Set the variable in the onAttach(Activity activity) method.
Null that variable in the onDetach() method.
Call the variable (interface member) method in the onClick.
Example:
public class MainActivity extends Activity implements MyInterface {
// ...
#Override
public void onChoose() { finish(); }
}
And inside ConfirmDialog:
public static interface MyInterface {
public void onChoose();
}
private MyInterface mListener;
#Override
public void onAttach(Activity activity) {
mListener = (MyInterface) activity;
super.onAttach(activity);
}
#Override
public void onDetach() {
mListener = null;
super.onDetach();
}
And then call mListener.onChoose() anywhere inside your class.
I know this has been marked as accepted, but I figured I could provide more feedback to the discussion.
A note about using or not interfaces. Andy's answer works just as right as mine, hence why I said "There are many options. One of them is...".
However, the reason why I prefer interfaces for this particular problem is because most of the times you're going to extend and reuse simple/common confirmation dialogs like that. hey are too generic to be "wasted" (or worse: duplicated if different event actions arise).
Unless you are deadly sure that you are going to use that only once, for one purpose (finishing), you generally should avoid hardwiring (and simplifying) the implementation details of the Activity in your dialog class. Flexibility, abstraction and efficiency. Less code to maintain.
And yes, there is a telltale that you may need that: the public keyword that you're using, especially if it's in a self-contained class file, which begs for reuse (too). Otherwise, you should be hiding that class inside your main Activity, since the implementation details (would) relate only to that one. Also, you would be removing the public keyword.
Yes, you could use for more than one Activity, but you'd be limited to finish()ing. The interface will give you flexibility to do whatever you want in each Activity. In other words, it's up to the implementer to define how it should itself behave for that event. You self-contain implementation details.
As a sidenote, what I do is create a package with all dialogs I may need for my application. For confirmation dialogs like that, I reuse for different messages and buttons. I provide defaults, but also allow for change using setArguments. And I keep the interfaces related so I don't need to create one interface for each dialog. The implementer responds according to which dialog triggered the "dialogs callback". Flexibility, abstraction and efficiency, all while avoiding things humorously called Hydra and Royal Family. So. In the end, like I said, many options. Don't over-engineer, but don't simplify too much too early (leave room for graceful expansion).
It's more important to understand advantages and pitfalls than choosing this or the other answer.

Even though the amount of work involved to make the interface is small, I don't see why you need to call finish() from the Activity that created it. Calling finish() from within the DialogFragment itself will suffice. If you need to send info back with it as well for some reason, you could always call getActivity() and chain a method that exists in the Activity. Ultimately no matter where you call finish, it will detach the Fragment and destroy it.
Just to clarify how to call a method from your Activity in your Fragment
((YourActivity)getActivity()).someMethod(param);
You MUST caste it because Java doesn't know that Activity has whatever method you wanna call. Which ever way you decide to go with, good luck :)
cheers
EDIT
I appreciate your clarification David. In general you are correct. But to be honest in this instance, you are incorrect because of the nature of Fragments and their relationships with the Activity. Again, you will essentially be creating a listener in order to be called by a Fragment that already has an extremely close relationship with the Activity class it is being held by. Any benefits provided by not hardwiring anything through listeners is lost in this case. You will still be rewriting custom code for every Dialog. While in my method you can write a method in the Activity class in such a general way that you only ever have to write it once.
There are only two reasons I see a need to use a Listener:
1. If you are writing code that other people will be using. So you provide an easy way to give info while maintaining a certain structure (like Androids DatePickerDialog).
2. If there is no connection between two parts you are trying to maintain connected (like GUI's in Java).
So I am not trying to say that David is wrong in saying this, and I am grateful he is bringing it up because it is important for people to understand when to use them. But again, in this case the benefits he mentions are non-existent due to the connection between Fragments and the Activity class. Just wanted to clarify why I believe listeners are not necessary here.

Instead of:
.setPositiveButton("Yes.", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
//finish() MainActvity
}
})
Use:
.setPositiveButton("Yes.", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
// this gets the current activity.
Activity currentActivity = getActivity();
// this finish() method ends the current activity.
currentActivity.finish();
}
})