Apps When to use mySQL

[Girevik]

Hello everyone,

I'm new to Android development. I've written my first little "get my feet wet" ap and am looking to expand on it. One thing I would like to do it give the user more options of things they can configure and I'm wondering the best way to do that. At what point does it become worthwhile to start using mySQL vs just using string data in the prefrences? Or is there another option I've missed (maybe an xml file, but I'm not sure where that would be stored?).

In my case, I'm thinking I have fewer than 100 instances of an object (or objects) that would have 3 or 4 properties associated with them.


Thanks!

 

[wubbzy]

I think there is something missing in your explanation - 300-400 user tweakable options/preferences (thats large variation/error) ? Second android has SQLITE, not MySQL (unless you're talking about backend).

 

[Girevik]

Sorry, yeah...meant SQLLite. Must have remembered what I read on it wrong.

But yes, there could potentially be a decent amount of repeating data but 100 would be on the very high end.

Say I want to allow the user to configure his widgits, and each widget has a number of properties - say "color", "number", and "size". Maybe one person will configure 5 widgets and another might configure 25. The way I would personally set it up would be more like 20 instances, and that's probably getting up there in number. The minumum would probably be around 6 or 7.

What I'm envisioning, though, is not a big screen where you'd edit all the preferences. I'm thinking of a screen that would list all the widgets, and from there you can choose to edit, add, or delete one. If you edit or add one, it brings up the 3 or 4 properties for you to change on that one widget. So the amount of data would be dependant on how many widgets the user had to add.

 

[wubbzy]

You have quite a few options as I see it, but those would depend on your need and why you prefer to implement

• Go the preference (XML) route and have preference for each widget added to its own file.
• Use Database approach as you suggested
• Use Maps to represent and externalize object preference

Questions you need to ask yourself or maybe defined by your requirements - How many times would user actually "change/modify" perfs? Excluding first time setup. You may say "as many times as user wishes", but tell you the truth that is not an acceptable answer. Need to put a face value on it so you can drive a certain solution. Strictly speaking of customization preferences, they're not tweaked every time user hits the widget. Considering that Preferences class maybe the way to go in my opinion and given your description.

Hence performance is not going to be a factor.

Let us know what you think?

 

[Girevik]

I'm not sure what you mean by the "maps" options.

But yes, this is a situation where the configuration would most likely be set up once and rarely if ever changed, however they will need to be loaded into memory each time the ap is used.

 

[wubbzy]

maps == extend HashMap/Map with Externalize.

Question: is there really need to hold preferences in memory after they've been applied? i.e. color, once you apply it you done, until someone changes it. Yes I agree you'll need to load at startup (read once).

DB vs XML won't save you much memory. The database cursor will completely reside in memory once you read all its rows as will HashMap or XML or any other. Unless your widgets are paginated i.e. you can only show limited number of widgets per screen due to physical restriction, in that case you can load and keep stuff in memory for those widgets that are currently displayed? Going back to disk and reading prefs whether SQLite or XML maybe way to explore is physical device restrictions i.e memory becomes an issue.

I certainly could be missing a lot here, but neither am I trying to question your approach nor method but trying to evolve a way that best meets your need. Hopefully something will pop.

 

[Girevik]

Question: is there really need to hold preferences in memory after they've been applied? i.e. color, once you apply it you done, until someone changes it. Yes I agree you'll need to load at startup (read once).

Yes - the "widgets" will be used in processing each time the user performs an action. I'm not terribly concerned about the amount of memory it will take though.

Right now I'm leaning twards using prefrences, but am still not clear on what the map option would entail. I'd likely store the data in hash map internally.

 

[wubbzy]

so lets compare options:

SQLITE:
- Initial query: does not use any memory other than cursor object itself
- Iteration: fetches records from disk to memory as you iterate over cursor
- Close: you can release cursor memory but references that you hold to objects still live on as long as you keep referencing them

PREFERENCES (XML):
- Initial: read will use memory as you read objects from disk to (disadvantage over SQLITE)
- Iteration: Will not need more memory than it initially uses (advantage over SQLite in terms of performance)
- Close: GC will reclaim unused objects (@ par with SQLite)

HashMap/Table Externalize:
Hybrid approach between SQLite & Preferences.
Disadvantages: Cannot contain duplicates, needs some free space (waste of memory)
These can be resolved by implementing two stage Hash usual strong reference WeakReferences & SoftReference. The advantage is that unused options will move from strong to soft to weak reference. Once in weak reference they maybe GC'd in which case you'll have to 'reload'. Here's a dummy/skeleton for you (BTW you can also look at weakhashmap, i've excluded weakhashmap but you can certainly add it here get/put will then become three step i.e. first look in softref and then in weakref if none is found read it from disk):

public class MyPrefs<K,V> implements Externalizable {
       private final HashMap<K, SoftReference<V>> map;

       public synchronized V get(K key)   {
        SoftReference<V> ref = map.get(key);
        return ref != null ? ref.get() : null;
      }

    public synchronized V put(K key, V value) {
         map.put(key, new SoftReference<V>(value));
    }

    public void writeExternal(ObjectOutput out)  {
      /* CODE TO WRITE PREFS TO DISK */
    }

    public void readExternal(ObjectInput in) {
       /** CODE TO READ PREFS FROM DISK */
    }

}

Design point to consider:
- Use interface to design your preference; if you wanted to experiment with different strategy you can quickly change interface without changing actual business logic.
- Can the widget read preference (no matter what the implementation) when they start to perform action. Looking @ your description it would seem they fire off when they get some sort of notification/event/message etc. Once finished you can assign preference vars null (though not a good idea, but if you're worried about excess memory then it is) to be GC'd.

Hopefully this helps.

 

[Girevik]

Cool....right now I'm thinking I'll go with prefs, but will look into the hash maps. It's not like this is likely to end up on a million devices (likely it will only ever be on mine)...this is all just a learning exercise.

The action will actually fire when the user clicks a button. Interfaces are one concept I need to learn up on.