2

Android App with two solution for passing data between activities (No Intent Extras Please!)

public class A { 
  public static LinkedHashMap<String,String> hashStore = new LinkedHasMap<String,String>(); 

  public void doHttp(){
    //Some HTTP call and store some json value
    hashStore.put("data","jsonKeyValue"); 
  }

  public void onDestroy(){
    hashStore.remove(key);// remove data key
    hashStore.clear();
  }
  }

public class B { 
public void getHttp(){
    //Some HTTP call 
    String extra = A.hashStore.get("data"); 
  }}


    //  SharedPreference Call 
public class A{
SharedPreference hashPref ; //declaration on onCreate 
public void dohttp(){
//Some Http and Store value in SharedPreferences
hashPref.put("data","jsonkeyvalue");
hashPref.apply();
}}



 public class B{
 SharedPreference hashPref ; //declaration on onCreate
 public void getHttp(){ 
    //Some HTTP call 
    String extra = hashPref.get("data"); 
  }}
  1. Which one is better option to reduce memory leaks ?
  2. If i store more than 30-40 keys which one would be preferrable ?
  3. If i use sharedpreferences won't i eat the performance while validating and updating the keys ??
  4. Is there any alternative that i could use instead of these two solutions ? (Don't mention Intent Extras here.)
Rizvan
  • 2,335
  • 2
  • 23
  • 42

2 Answers2

2

Using your activity as an static data source, and let your other activities depend on it (and even know that this activity exists) is a bad practice, according to many principles (high cohesion, decoupling, minimice dependency, Protected Variations...), but android team has some similar approaches that you can rely on, but for the same reason they shouldnt be the first option.

What i would prefer is:

If the data has to be persistent:

  • SharedPreferences for small amount of data
  • SQLite database for a bigger amount of data

if you dont need to persit the data

  • A service that is always running and you bind to all your activities, where you have all common data an functions.
  • A helper object where you have the data.

You can find out more in this android official faq page or in this great SO answer, that is based in that faq but with some code examples

Community
  • 1
  • 1
Carlos Robles
  • 10,828
  • 3
  • 41
  • 60
  • If i use sharedPreferences , it will take time to validate and fetch and apply ?? what you say @Carlos – Rizvan Jan 03 '14 at 14:36
  • if you wonder about performance, it is supposed to be faster than sqlite for few keys, but i dont have any canonical answer. The sharedpreferences, once loaded, are kept in a static `HashMap`, see `sSharedPrefs` in (https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/ContextImpl.java), and it will remain there until the process is terminated. So it is supposed to be fast. Of course, you cannot perform searches, sort, filter, or keep colletions or related entries in an easy way, as you could in sql. Thats why its only meant to few keys. – Carlos Robles Jan 03 '14 at 15:48
  • also, keep in mind that with sqlite or sharedpreferences, you are persisting the data, so it will be there next time the user open the app, so you have to consider if you actually want this, or you have to delete all when the app is launched, or you can chose another approach that doesn't persist the data. – Carlos Robles Jan 03 '14 at 15:51
1

As stated here,

Pros and Cons of SQLite and Shared Preferences

for large groups of data > 30-40 keys I would suggest you to use SQLite. It´s more powerful than SharedPreferences and provides you the possibility to make queries based on the keys you want to search for.

In the other hand implementing SQLite it´s a little bit more complicated and longer to code than using SharedPreferences.

Having a static LinkedHashMap or any other static variable it´s never a good option for code maintenance and readability, you should use it only if there´s no other option.

Hope it helps. :)

Community
  • 1
  • 1
reixa
  • 6,903
  • 6
  • 49
  • 68