Is it a good idea/practice to put static shared preferences editor in a utility class so I can call it whenever needed? The method in the utility class would look like this:
public static SharedPreferences.Editor editor (Context context){
final SharedPreferences sharedPrefs = PreferenceManager.getDefaultSharedPreferences(context);
return sharedPrefs.edit();
}
and use it like this in different classes:
Utility.editor(mContext).putBoolean(categoryId, true);
Utility.editor(mContext).apply();
At least I would't say it's a bad idea.
But here is an even better idea: abstract away the Android specific details and create a clean, readable interface for storage access that fits your domain.
e.g:
interface UserSettings {
void setAutoReloadEnabled(boolean enabled);
boolean isAutoReloadEnabled();
...
}
and then implement it using SharedPreferences
class SharedPreferencesUserSettings implements UserSettings {
final SharedPreferences sharedPrefs;
public SharedPreferencesUserSettings(Context ctx) {
sharedPrefs = ...;
}
#Override void setAutoReloadEnabled(boolean enabled) {
sharedPrefs.editor().putBoolean("...", enabled).commit();
}
...
}
This gives you more readable code and you can actually provide a stub/mock implementation in your tests! If the API of SharedPreferences should change (or when you want to move from using commit to apply or vice-versa, or changing the Tags you used for the preferences) you only have to change it in one File, not everywhere in your code.
But there is more: if you should later decide that SharedPreferences were actually a bad choice, you can switch the implementation to use e.g. a . SQLite Database or ObjectBox instead. Again, without changing the rest of the code.
Needless to say that this might be overkill (aka over-engineering) in certain situations, but in bigger projects this pays out pretty fast.
Its not necessarily a bad idea and it will clean up the code. But it will slow your app down.
Not by a noticeable amount but nonetheless - if time is an issue in your project do not do this. If not, then go ahead.
Related
I am coding an app that requires the ability to save data so the next time a user enters the app their progress will be saved. I am thinking an array with values that will be updated as the user makes choices would be the easiest way to implement this. My first thought was to make a class file with a read and write method so all activities can update and read data from the array but I don't think the array would be permanent when the app closes or I release an update. What is the best to make sure my save array is permanent between app closures and future updates?
You can do it in several ways.
Using SharePreferences
//To add or update a data
SharedPreferences sharedPref;
sharedPref = getSharedPreferences("AnyNameForSharedPref", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putString("name", name);
editor.putString("email", email);
editor.putString("phone", phone);
editor.putString("gender", gender);
editor.apply();
//To get the data
final SharedPreferences sharedPref = getSharedPreferences("AnyNameForSharedPref", Context.MODE_PRIVATE);
sharedPref.getString("name", "Default text if it is not present"));
Using ROOM
Since Room is based on the SQLite database, you can avoid it if don't have lots of data to store. To use ROOM, add these dependencies:
dependencies {
def room_version = "2.2.5"
implementation "androidx.room:room-runtime:$room_version"
annotationProcessor "androidx.room:room-compiler:$room_version" // For Kotlin use kapt instead of annotationProcessor
// optional - Kotlin Extensions and Coroutines support for Room
implementation "androidx.room:room-ktx:$room_version"
// optional - RxJava support for Room
implementation "androidx.room:room-rxjava2:$room_version"
// optional - Guava support for Room, including Optional and ListenableFuture
implementation "androidx.room:room-guava:$room_version"
// Test helpers
testImplementation "androidx.room:room-testing:$room_version"
}
Here's the official documentation for ROOM with example.
Android ROOM
you have many options to do this job.
Firstly, you can use SQLite Database (if I were you I would use this).
Create class which extends SQLiteOpenHelper for example:
public class DBHelper extends SQLiteOpenHelper {
public DBHelper(Context context) {
super(context, DATABASE_NAME, null, 1);
}
public void onCreate(SQLiteDatabase db) {}
public void onDestroy(SQLiteDatabase database, int oldVersion, int newVersion) {}
}
Here is one example how to create and use SQLiteDatabase: https://www.tutorialspoint.com/android/android_sqlite_database.htm
Secondly, you can use SharedPreferences. Maybe, this i simpler way if you have no additional data except your array.
If you want to save your data online you can use Firebase. This is useful when you want to multiple users share data. Here is an example how to use Firebase:
https://blog.mindorks.com/firebase-realtime-database-android-tutorial
Coming from a non-Java background, I find myself writing a lot of View classes with extensive functionality (in an effort to be portable), that don't necessarily fit nicely into the Android FW setup as far as maintenance - for example, I might have a widget that does something on a interval that I want to stop and clean up when an Activity is paused/stopped/destroyed. Generally I can manage this by just calling a public method on the widget from the containing Activity, but A) sometimes this gets pretty deep, and having to create a public method to access a child in every parent can get ugly, and B) requires extra (uneeded?) attention.
I'm considering using an approach like a global delegate to manage this kind of thing, but have read a lot of warnings about this sort of approach - would something like the class that follows have any inherent flaws that I might be missing?
import java.util.HashMap;
import java.util.HashSet;
public class ActiveRegistry {
private static final ActiveRegistry instance = new ActiveRegistry();
public static ActiveRegistry getInstance(){
return instance;
}
private HashMap<String, HashSet<Runnable>> registry = new HashMap<String, HashSet<Runnable>>();
private ActiveRegistry(){
}
public void register(String key, Runnable runnable){
if(!registry.containsKey(key)){
HashSet<Runnable> list = new HashSet<Runnable>();
registry.put(key, list);
}
HashSet<Runnable> list = registry.get(key);
list.add(runnable);
}
public void execute(String key){
if(registry.containsKey(key)){
HashSet<Runnable> list = registry.get(key);
for(Runnable runnable : list){
runnable.run();
}
}
}
}
Use might be something like...
A View has something that needs to be cleaned up. On instantiation, register it... ActiveRegistry.getInstance().register("paused", someRunnableThatCleansUpStuff)
Extend Activity so that onPause calls ActiveRegistry.getInstance().execute("paused");
You are doing way more work than you need to. Using Fragments (from the support package, if you want to ensure backwards compatibility with older versions of android), will make your life a whole lot easier. Each fragment is embedded in an activity and has a lifecycle that is directly linked with its host activity's lifecycle. Using them should significantly reduce the complexity of your code, as most of what you are currently worrying about will be managed by the system instead.
I'm creating a music player for Android and it's mostly working. The problem is that when I turn the device horizontally I lose all the variables from the Activity (which makes sense because it is destroyed and re-created).
I've tried using bundles to store the state of the player with onSaveInstanceState & onRestoreInstanceState but I still can't access the media player. Is there a way to pass objects like the MediaPlayer in bundles? Should I be using a database instead?
Thanks
You should use a Service to Provides "background" audio playback capabilities, allowing the
user to switch between activities or Rotate device without stopping playback.
Check out android_packages_apps_Music which is opensource by CM on github , It use MediaPlaybackService extends Service to do this , checkout MediaPlaybackService.java
For objects you couldn't pass via a bundle, I would suggest you to use the simple SharedPreference to store objects.
Here you have a simple implementation:
public class Data {
private SharedPreferences preferences;
private int test;
public Data (Context context)
{
preferences = context.getSharedPreferences("Data", 0);
test = preferences.getInt("test", 0);
}
public int getTest()
{
return test;
}
public void setTest(int input)
{
this.test = input;
SharedPreferences.Editor editor = preferences.edit();
editor.putInt("Test", input);
editor.commit();
}
}
You have just to initialize the variable in the onCreate():
Data mydata = new Data(this);
And you can use set/get with mydata to store/retrieve your persistent data.
Edit: It is maybe not suitable for MediaPlayer objects, but for other classical types (int, string, boolean...).
Both of the methods below would allow you to keep your mediaplayer object through the rotation, but neither use bundles.
You could persist your media player by using onRetainNonConfigurationInstance() to save the variable and getLastNonConfigurationInstance() to retrieve it after the rotation, but this method isn't necessarily the best as it is not always called
-See this SO post for more info https://stackoverflow.com/a/3916068/655822
Or you could persist your media player by extending your application class and storing it in there
below info copied from the linked SO answer for the purpose of making this answer quicker to read
You can pass data around in a Global Singleton if it is going to be used a lot.
public class YourApplication extends Application
{
public SomeDataClass data = new SomeDataClass();
}
Then call it in any activity by:
YourApplication appState = ((YourApplication)this.getApplication());
appState.data.UseAGetterOrSetterHere(); // Do whatever you need to with the data here.
-See this SO post for more info on that https://stackoverflow.com/a/4208947/655822
Another way would be to :
In your AndroidManifest.xml, find your entry for your activity and add the following attribute and value:
android:configChanges="orientation|screenSize"
This will stop your activity from being destroyed and recreated on orientation.
I'm not sure if I actually need this right now but if my app ever expands I could see the possibility. I basically have a wrapper around SharedPreferences that pulls a few values out of SharedPreferences and bundles them into an object. It also takes an object and uses it to update preferences. I wanted to make it thread-safe, but I wanted to try it with a Semaphore. My SharedPreferences wrapper will get a reference to the class below from getSyncedPrefManager(). It will then call aquireLock() followed by getPref(), do its work and then call releaseLock(). Does this look like something that would work or am I way off base?
public class SyncedPreferenceManager {
private final static SyncedPreferenceManager me =
new SyncedPreferenceManager();
private SharedPreferences prefs;
private static Semaphore mutex;
public static SyncedPreferenceManager getSyncedPrefManager(){
return me;
}
private SyncedPreferenceManager(){
mutex = new Semaphore(1, true);
}
public SharedPreferences getPref(Context caller){
if(prefs == null)
prefs = PreferenceManager.getDefaultSharedPreferences(caller);
return prefs;
}
public boolean aquireLock(){
try {
mutex.acquire();
} catch (InterruptedException e) {
return false;
}
return true;
}
public boolean releaseLock(){
mutex.release();
return true;
}
}
You might not like this answer.
You are not using the right system here. SharedPreferences is for storing simple preferences. Just because you can do this does not mean you should. You're basically trying to make SharedPreferences into something its not. You can add all this fancy locking but it won't stop someone from coming in underneath this later and accidentally blowing it up.
If you find yourself needing these feature in earnest, you should look at just using sqlite directly. There is little doubt you could add synchronization to SharedPreferences (and I am sure it is safe to some degree as it is already designed with a transaction/commit model) but it seems to me like reinventing the wheel.
Syncronized sections shall be enough for this purpose. Usually there are no performance concerns in saving / loading values from preferences (there are not that many of values in there).
And I also doubt, that you need it at all. Preferences are usually loaded on activity startup or saved on pause ( which is kind of songle threaded anyway, only one of activities in your application is being started or stopped at the time )
In my apöications preferecens are read eagerly, and saved only when dedicated settings activity is paused. I do not need any mutual exclusionin this case.
I also developed small wrapper library, which allows easy marshalling / unmarshalling preferences into object properties:
https://github.com/ko5tik/andject
You can always make your changes in the SharedPreferences.Editor and use apply() to apply the changes atomically.
editor.apply() is available from API level 9.
Documentation here: http://developer.android.com/reference/android/content/SharedPreferences.Editor.html#apply()
I've created a few minor apps for Android while learning. Being a PHP developer, it's a challenge to get used to it.
I'm especially wondering how I could define a couple of "general" functions in a separate class. Eg I have a function that checks if network connection is available, and if not, shows a dialog saying that the user should enable it. Currently, that function exists in several of my activities. Of course that seems strange - I suppose it would be more logical to define it once and include it in the activites where needed.
I tried putting it in a new class, and included that class in the original activity. But that failed since eg getBaseContext() is not accepted anymore.
I'm wondering how to go ahead. What should I be Google-ing for ? What is this mechanism called?
You need to create class with static methods. Like this
public class HelperUtils {
public static void checkNetworkConnection(Context ctx) {...}
}
Then you can call it from any place like this:
HelperUtils.checkNetworkConnection(this.getContext());
Assuming current class has Context.
You should read books on general OOP concepts where different type of methods are explained.
You can for example create a class - let's call it NetworkUtils. In this class you can create static method boolean isNetworkConnectionAvailable() and return true if is available and false otherwise. In this class you can create another static method void showNoConnectionDialog(Activity activity) - and in this method you create dialog starting with
public static void showNoConnectionDialog(Activity activity) {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
//setting message, listener etc. and finally
builder.create().show();
}
In your activity, where you want to check and handle network connection you should call:
if (!NetworkUtils.isConnectionAvailable(getApplicationContext())) {
NetworkUtils.showNoConnectionDialog(YourActivityClassName.this)
}
I guess this should work.