Jens

Thanks for these notes - extremely helpful.
I think I will kick off with Realm and see where I get too.

Peter



> On 4 Jun 2016, at 20:36, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
>> On Jun 4, 2016, at 9:51 AM, Peter Hudson <peter.hud...@me.com 
>> <mailto:peter.hud...@me.com>> wrote:
>> 
>> “If your app’s performance is suffering because of large files, then use 
>> streams instead, and try to only read the part of the file that’s necessary.”
>> Could you point me at some material about this technique ?  It sounds very 
>> interesting.
> 
> At a low level, you can use NSStream to read/write files. Or just use the C 
> standard library (fopen, fread, etc.)
> 
> At a high level, I can’t say that much since I don’t know what your file 
> format is. If it’s something like an NSArchive, there’s no alternative to 
> reading the entire file at once. If it’s an XML property list, you could use 
> NSXMLParser to stream it and pick out just the parts you need, although this 
> also gets expensive if you have to keep parsing the file over and over to 
> read different parts.
> 
>> I will check out the database approach as well.  I have steered clear of 
>> using databases as our users are mostly individuals with little or no tech 
>> support. The idea has always been to keep things simple and maintenance free.
> 
> You’re thinking of a database _server_ like MySQL or MongoDB. Those run as 
> separate processes and require administration.  The databases I mentioned are 
> embedded: they’re just libraries that you link into your app, which read and 
> write a data file (or a directory in LevelDB’s case.) To the end user it’s no 
> different than any other file format. 
> 
> Any Core Data app stores its documents this way, using SQLite by default. 
> There are also zillions more apps that use FMDB (an Objective-C wrapper 
> around SQLite) or just SQLite directly. Going with that does require that you 
> learn about relational databases and SQL syntax, though. Another option is 
> Realm, a very popular mobile database with a nice Obj-C or Swift API.
> 
> (There’s also the project I work on, Couchbase Lite, which fits in this 
> category. It has some more overhead, though, because it also performs full 
> multi-master data sync with servers or peers. This is awesome if you want 
> that feature, but if you’re just getting started with databases it adds to 
> the learning curve.)
> 
> Thinking through all the DB options, I’d suggest you look at Realm 
> (http://realm.io <http://realm.io/>). It’s very easy to understand even if 
> you don’t know databases, and the APIs are easy to use. The drawback is that 
> it will probably require that you rethink and re-implement your data model 
> layer based on its persistent object model.
> 
> If you don’t want to refactor that much, see whether there are any good Cocoa 
> wrappers around LevelDB, LMDB or RocksDB. (I’m skipping over Kyoto Cabinet 
> because I just remembered it’s GPL-licensed, and you probably want to stay 
> away from that.) They’ll provide a simple API that looks like an dictionary 
> that maps strings to binary data. Then you can break your data into small 
> bits and read and write them independently.
> 
> —Jens

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to