SnapIt – A Core Data Alternative using Ruby-like syntax | Hacker News Reader

SnapIt – A Core Data Alternative using Ruby-like syntax

github.com

22 pointszniazi13 comments

I'm not sure I'd call this a Core Data alternative, as it seems closer to a few convenience methods around SQLite.

I'd imagine that using this for presenting data in any kind of table view (a typical use for a local data store) could be extremely frustrating as it wouldn't do any of the progressive loading, caching or change notification that Core Data gives you.

Core Data can be a pain to work with, but when you do it right, it has some extremely nice features - stuff that you absolutely need in a performant, stable app that handles data at a scale of anything more than a few dozen records.

Also, looks like we've got some cat references (from the demo) in the library's own code, so I'm not sure whether the demo was created to demonstrate the library, or the library was a rushed abstraction of the cat project :)

Edit: https://github.com/zniazi/SnapIt/blob/86f1ec45e6493c3fc9fd4d...

I would absolutely not recommend this for use in any kind of real-world app. From what I can tell, there is no attempt whatsoever to sanitize or parameterize SQL statements.

You are right in that NSFetchedResultsController is a nice feature of using Core Data with TableViews, but the functionality is not difficult to write on your own. As you insert or update data, call [tableView reloadData]. You may not want to reload each cell for one insert in which case you can do something a bit more custom.

And yeah, there is a reference to catsDB. I thought people may find that funny if they ever looked into the implementation. The work is derived from a blog post I wrote a while back to demonstrate connecting to a SQL instance in Objective C.

Sanitization can be added pretty easily, but I will ask you this. Who will the user of your app be hurting if they do a SQL injection attack? They will be destroying data on their own phone.

Slightly off topic: are there any good solutions for keeping localdata and a rails back-end in sync? If the device is offline save locally, otherwise sync with the rails app.

That's the most straightforward solution. I'm working on an Android app that syncs calls and texts to a Rails back-end and I try to keep the sync workflow as simple as possible. As for sync'ing, I found the following to be a huge boon for users:

- Allow the user to set sync to happen only when connected via Wi-Fi (not sure if this is possible in iOS, but it's easy to check how an Android device is connected to the Internet).

- Give options for sync intervals. Most of our users choose once a day. Other options include sync'ing a call or text right after it's finished or received if they need their data to be up-to-date within minutes.

I would write a method to check if you have internet connection. And whenever you make a POST request to push some data to your server, check if there is internet access. If there is not, save the data locally. You can do your local save with a few lines of code using Snapit.

Firebase (YC S11) automatically syncs between local and remote. They have a free developer account that can handle a moderate amount of users.

I'm not sure what's needed for Ruby but they have good SDKs for iOS, Javascript and others. You can also use their REST API with Backbone.js and AngularJS (BackFire and AngularFire).

After using it since February, I really can't imagine going back to any other solution. I did things in Firebase the first day that took me weeks to get working in iCloud with CoreData.

Realm is also pretty neat as a core data alternative: http://realm.io/

I agree, the syntax is very clean.

Interesting. How does this play with Swift?

The code is written in Objective C. I will make a Swift implementation soon. In the meantime, if you write your application in Swift you can still use it by bridging the Objective C code inside your Swift application.

https://developer.apple.com/library/ios/documentation/swift/...

You mean an ActiveRecord-like syntax.

That's right.

Reply on news.ycombinator.com