Browsing projects by Tag(s)

Select a tag to browse associated projects and drill deeper into the tag cloud.

Showing page 1 of 1

An easy-to-use SQLite 3 library written in Objective-C for Mac OS and iOS that will build SQL statements and manage database connections, plus ORM.

0
 
  0 reviews  |  1 user  |  56,512 lines of code  |  1 current contributor  |  Analyzed about 1 year ago
 
 

Wouldn't it be nice if your Objective-C data objects just knew how to save and load themselves? It'd be nice if you could just call "save" and trust that your object would save itself properly somewhere, and that when you wanted to load it back in, you could just call a class ... [More] method to retrieve the object or objects you wanted? Well, now you can. This project uses the objective-C runtime to implement a pattern similar to ActiveRecord, but driven by the object's properties rather than the tables in the database. The objects are completely self-contained - you do not need to write SQL or even create a SQLite file. You just subclass an existing class, and your model objects inherit the ability to load and save themselves from the database. [Less]

0
 
  0 reviews  |  0 users  |  22,684 lines of code  |  0 current contributors  |  Analyzed 3 days ago
 
 

OverviewWhenever iTunes syncs with an iPhone, it creates a backup of the files on the device. This backup is stored in: ~/Library/Application Support/MobileSync/Backup It can be interesting to look at these backups, but a bit of work is necessary to get access to them. I've whipped up a ... [More] quick and dirty application to display the most common cases, iPhone Backup Slurper. mdbackup FilesThe files themselves are named with what appears to be a hex representation of a UUID with the extension "mdbackup". One of these files corresponds to a single filesytem entry on the iPhone. The file is just a standard plist, with binary encoding. You can convert this to a text file using plutil -convert -o The plist contains the following keys: Domain: The scope of the file. Options are "HomeDomain", "LibraryDomain", or a specific application bundleID. Path: The path within the domain where the file is stored on the iPhone. Data: The contents of the file. I assume that this is data-fork only, if the iPhone supports multiple forks. The file can be any arbitrary kind of file, but in practice, there are only a few different types of files that developers seem to actually be saving in the filesystem. The app reads in the plist, displays the metadata keys described above, and does some heuristics on the data to try to guess how to display it. The most common cases I found by browsing my own backup directory were: text file plist saved as a string file binary plist image zip file sqlite 3 database completion dictionary iPhone Backup Slurper will print any of these out to a descriptive file when it encounters them. If the backup contains an image, it will display the image. For a zip file, it will display the filenames embedded in the zip. It will dump the contents of an SQLite database. There are two pathological cases I found while playing with this that I couldn't figure out how to handle. First, there are some files that appear to be SQLite 3 databases – the file begins with the string "SQLite format 3". But the version of SQLite 3 included with Leopard 10.5.5 gawks when trying to read them. Second are the audio files bundled with Tap Tap Revolution. The Quicktime APIs don't recognize them as valid m4a files. Maybe they're actually something different. Manifest FilesThe backup directory also contains a plist named "Manifest.plist". This is a manifest of all of the mdbackup files in the same directory. iPhone Backup Slurper can also display the contents of this file by choosing Open Manifest from the File menu. The manifest contains the following key/value pairs: AuthVersion: The current version of this file. AuthData: The string "Forty Two" encoded as hex without a null terminator. AuthSignature: The SHA1 signature of the "Data" key. Data: The actual manifest stored as a binary plist. The manifest itself is just a listing of all of the applications on the phone, with the files for each, and a separate listing of each file's attributes. Specifically, these are the keys: Applications: A list of each application, keyed by the applications' bundle identifiers. DeviceId: The device that this manifest is intended to be used with. Files: A list of each of the files in the backup directory, keyed by the file's UUID. Each entry contains filesystem attributes for the file and a DataHash to ensure data integrity. I don't know the hash algorithm used by the data hash, but I suspect it's something tricky that uses the "Forty Two" value mentioned above as a hash seed. ConclusionI hope iPhone Backup Slurper is useful to people or just fun for exploration! If nothing else, it's a good example of using a bunch of different APIs to parse different filetypes. Finally, I'm indebted to OmniGroup for their useful OSLDatabaseController sqlite wrapper class. [Less]

0
 
  0 reviews  |  0 users  |  3,398 lines of code  |  0 current contributors  |  Analyzed 3 days ago
 
 

A library that facilitates the access to an sqlite3 database. The programmer only has to create a set of classes, extending basic classes provided by the library, reflecting the schema used in the database. These classes inherit a set of function to insert, update, select and remove rows in the database. Programmed in Objective-C.

0
 
  0 reviews  |  0 users  |  0 current contributors
 
 
 
 

Creative Commons License Copyright © 2013 Black Duck Software, Inc. and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a Creative Commons Attribution 3.0 Unported License . Ohloh ® and the Ohloh logo are trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.