Now that we're feeling more comfortable with shared preferences,

let's introduce this new type of persistence into our application.

You'll remember in the last stage,

we introduced a couple of different ways to store files.

We then implemented a way to verify that reading, writing files worked correctly.

Whether we saved them an internal or external storage.

However, we were forced to make the modifications and then rebuild the app.

This feature might be more suited to a shared preference,

which can be modified by the user at one time.

So, the first thing we'll start with to add shared preferences in

our app is our existing meme maker application settings.

So, let's open up the file now.

This class is currently empty and

will be used as our intermediate layer for handling our shared preferences.

Let's start in here by adding a private variable for shared preferences.

So SharedPreferences, mSharedPreferences.

Again, since everything begins with a context, let's create a constructor for

this class to take in a context.

So we'll do public MemeMakerApplicationSettings passing in

context, with a context.

We don't have a reason to retain the context, so let's just for the time

being create the shared preference object we need with the context.

And save that variable off into the private member field.

So mSharedPreferences equals PreferenceManager,

like we saw before, and then getDefaultSharedPreferences.

And we pass in the context for that.

Next we need a way to get and set these SharedPreference fields.

So, let's create a get storage preference method to return string.

Let's go public String,

getStoragePreference and that will just return.

Now, instead of returning empty, let's add the necessary code to

actually access the shared preferences and get a string out of this storage key.

So, we'll go mSharedPreferences.getString and we'll call it Storage for now.

Let's reuse our storage type constants in this case for the default value.

So, we will default it in that the case has not been set yet

to StorageType.INTERNAL.

And now, we could create the associated set for this preference.

So let's do public, void, setSharedPreference

which will take a parameter of a string and which is it's storageType.

And, at this point, we'll go mSharedPreferences, and

we'll use the fluent interface we talked about before, .edit, then

.putString, and we'll pass in Storage

again here, and then the storageType that's coming in as a parameter.

Then we'll simply commit it.

Instead of using commit, we could also use .apply.

The difference between the two is, commit is synchronous.

Which means it will block execution of this line of code until it

fully saves this field out.

Apply is asynchronous, which means it will do the saving on a separate thread.

Thus allowing execution to continue and not waiting for the save to complete.

One error of caution with using commit is that if you're saving large data sets in

to saved preferences, you could potentially run into a problem where you

can get an application not responding.

So, we have the shared preferences in place at this point.

However, we're not using them in our application.

So, let's head over to the file utilities to integrate this.

If you remember getFileDirectory has a location for

choosing which file storage type to use.

It's currently using a hard-coded field to control this feature.

Let's remove this hard-coded field and

add our Settings class to control the getFileDirectory location.

So, instead of setting this field to String StorageType,

we are going to up above initialize a MemeMakerApplicationSettings.

I'm doing settings equals new MemeMakerApplicationSettings.

Passing and context semi colon.

And then, at this part right here, instead of setting

it to this hard-coded field, we will just say settings.getStoragePreferences.

So this will basically put the control of what file storage in the use of

the hands of the shared preferences.

And since we are defaulting to internal storage,

this is what the application will start using.

Let's run the app now to verify that everything is still working to

how we expected.

[BLANK_AUDIO]

Creating a separate class like we did is advantageous since it

keeps all the shared preferences in one logical unit.

This prevents the usage of a sprinkling implementation details across

the application.

Since, as you may have noticed,

there are a couple details which require consistency when using shared preferences.

Such as the name of the keys, as well as the type to expect.

We'll run into problems if we set a preference based on one name.

And then try to access that same preference but misspell it.

We also can run into problems if we set a preference based on a string.

And attempt to get that same preference based on an integer.

Keeping it in one logical unit will ensure these details are together and

easily maintained if we choose to refactor or modify how we want to use it.

This will also create a good, consistent pattern for

us to use going forward when we decide to add more functionality.