> On Jun 4, 2016, at 9:51 AM, Peter Hudson <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). 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
