Re:A Web Developer Goes Native (with Android)
by briancooley on Monday September 13, 2010 @12:28PM
(#1687076)
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]
Re:A Web Developer Goes Native (with Android)
by mbleigh on Monday September 13, 2010 @01:47PM
(#1687450)
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.
Re:A Web Developer Goes Native (with Android)
by hvs on Monday September 13, 2010 @12:53PM
(#1687173)
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.
Re:A Web Developer Goes Native (with Android)
by mbleigh on Monday September 13, 2010 @01:44PM
(#1687437)
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.
Re:A Web Developer Goes Native (with Android)
by mbleigh on Monday September 13, 2010 @01:43PM
(#1687430)
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.
Re:A Web Developer Goes Native (with Android)
by mahmud on Monday September 13, 2010 @01:52PM
(#1687471)
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.
Re:A Web Developer Goes Native (with Android)
by Someone on Monday September 13, 2010 @05:20PM
(#1688374)
"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.
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.... [2] http://developer.apple.com/library/mac/#documentation/Cocoa/... (see initWithContentsOfFile: and writeToFile:atomically:)
Seems to me that a relational DB can easily impersonate a hash, but not vice versa.
I'm not sure how to respond to this, but it strikes me as incredibly naive.
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.
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.