

A Web Developer Goes Native (with Android) - renaebair
http://intridea.com/2010/9/13/a-web-developer-goes-native-with-android

======
briancooley
_I know that it's the go-to solution for small, simple storage, but why on
earth do mobile platforms have schema-driven data stores by default?_

There are a few other easy ways to store data[1] on Android. For example, you
could use SharedPreferences for lightweight data. You could write anything
that implements the Serializable interface to a file on internal or external
storage. I don't know much about Redis, but if all you want to do is persist a
key-value store, create a HashMap in your app and write to and read from disk.

You can do something similar with an NSDictionary or NSArray in iOS. [2]

[1] [http://developer.android.com/guide/topics/data/data-
storage....](http://developer.android.com/guide/topics/data/data-storage.html)
[2]
[http://developer.apple.com/library/mac/#documentation/Cocoa/...](http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSDictionary_Class/Reference/Reference.html)
(see initWithContentsOfFile: and writeToFile:atomically:)

~~~
mbleigh
I am aware of SharedPreferences, and serialization is certainly an option, but
ultimately these don't solve the main problem I've experienced. Serialization
requires a lot of manual work and it may not scale particularly well for
middle-weight and up. I just think that the kinds of data stored in mobile
applications lend themselves more to some of the various NoSQL patterns than
something like SQLite.

~~~
asher
Can't you treat SQLite as a key-value store? Create a table with two columns:
key and value. Blobs can be pretty big.

Seems to me that a relational DB can easily impersonate a hash, but not vice
versa.

------
hvs
_Since I'm ultimately more interested in ideas and solving the big-picture
puzzles of applications than the low-level implementation details, web is
still the place to be for me (for now)._

I'm not sure how to respond to this, but it strikes me as incredibly naive.

~~~
mbleigh
How so? Web frameworks offer the luxury of interpreted, high level languages
and frameworks that abstract away many of the implementation details and let a
developer concentrate on the bigger picture. I think mobile will get there
someday, too, but it's not there yet.

------
mahmud
Wondering why Redis isn't the default builtin storage on Android is just a
non-engineer question, and the only blemish in a fairly accurate article.

~~~
mbleigh
I don't mean specifically Redis, the in-memory key-value store. Obviously
mobile has huge restrictions on memory that would make this difficult and
unwieldy. I mean more the approach of Redis than the implementation. Storing
simple data structures in a quickly retrievable format without the need for
up-front configuration and schema creation.

~~~
mahmud
Every Unix has shipped with dbm since 1979. Since then you have BerkeleyDB,
and most recently there has been TokyoCabinet.

However, Sqlite is clean, fast, small, well tested and just plain solid.
Android standardized on it for in-device relational store because more
applications can benefit from it. If it's not good enough for your purposes,
you have the whole gamut of Java serialization libraries to chose from.

~~~
Someone
"Android standardized on it for in-device relational store because more
applications can benefit from it."

They also have to supply some SQL store in order to support HTML5 databases.
SQLite then is a natural choice; it has a compatible license, is small enough
for mobile use, and is solid. Since it is solid, it makes sense to include it
in the public API.

