I'm working on an app that uses Core Data, and I'd like to be able to code it in a way that it can use a local SQLite store or a web-based store (with an XML or JSON response schema).
Is it possible to use the exact same code for the Core Data stuff and just select the appropriate persistence store based on a user's preference?
Look at the WWDC video "Building a server-driven user experience".
You can connect to a remote store via a URL but that doesn't sound like what you want as that would support only one store for every remote user.
Really, all you need to do is setup a regular SQLite store and then add a little code to send changes to the server via the chosen method. Then you could turn the server connection on and off as needed.
That would be simplest as long as you don't have a requirement that no data be persisted on the device itself.
In theory, yes. However you would probably wanna cache the data locally in case of network issues etc.
Take a look at this project https://github.com/AFNetworking/AFIncrementalStore which doesn't really implement a Web Service backed NSPersistenceStore, but it does try to achieve what you have in mind.
Related
There are several apps that I use on my Mac that store their data in core data. I can see the data I want in CoreDataPro. I want that data - specifically I want to send changes in that to some remote end points (such as Zapier, or some other REST service).
I was thinking of piggybacking something like RestKit - such that I provide a configuration file saying where the app is and what end points the data needs sending to. I need only to scrape the data and send to REST, not a two-way sync.
I'd prefer a utility that I could configure rather than having to code a Mac application.
I noted http://nshipster.com/core-data-libraries-and-utilities/ - RestKit still seemed the most capable, but in https://github.com/RestKit/RestKit/issues/1748 I was advised that coredata projects should only be opened by a single application at a time, and really RestKit is designed for baking into the source app (rather than for database scraping and sending).
What approach would you take?
I also noted:
http://www.raywenderlich.com/15916/how-to-synchronize-core-data-with-a-web-service-part-1
Thanks, Martin.
First, Core Data is an object store in memory. What is written to disk from Core Data can be in one of several formats. One of those formats happens to be SQLite. If the application is writing to SQLite then it is possible to sample that same file and push it somewhere else.
However, each application will have its own data structure so you would need to be flexible in the structure you are handling.
RestKit has no value in this situation as you are just translating objects into JSON and pushing them to a server. The built in frameworks do that just fine.
There is no utility to do this at this time. You would need to write it yourself or hire someone to write it.
If I were going to do something like this, I would write it using Core Data itself interrogate the model from the application that wrote the data in the first place and then translate the database into JSON and push it. You won't be able to tell what is new vs. old so the server will need to sort that out.
Another option, since you can't diff anyway, is to just push the sqlite file to the server and let the server parse through it.
Other answers might include:
use a middleware platform e.g. using rssbus.com (only) sqlite connections are free to send the events
as my target system (http://easy-insight.com) actually has a transmitter that sends new records it sees from MySQL abd PostgreSQL, I could https://dba.stackexchange.com/questions/2510/tools-to-migrate-from-sqlite-to-postgresql or use an ETL such as http://www.easyfrom.net (I did ask the vendor for SQLite support a long time ago, but SQLite is just not a priority for them).
I'm wondering whether a good answer (where good excludes Objective-C and includes languages that I do know, such as - to a limited extent - Ruby) is to use MacRuby and its Core Data libraries.
Core Data seemingly can be exposed as an Active Record. https://www.google.com/search?q=macruby+coredata , notably http://www.spacevatican.org/2012/1/26/seeding-coredata-databases-with-ruby/
However, MacRuby seems to have faded - https://github.com/MacRuby/MacRuby/issues/231 - it won't even compile on Mavericks.
I already have a django application and am trying to develop an iPhone app. I'm using mysql as the database for the django app.
Here are some questions I was having :
Is it necessary to use Core Data for anything?
Can I create a rest api to interact with the mysql database?
If so, would there be any advantage, at any place or reason, to use Core Data in addition to mysql. For example, for an app like Pinterest, Tumblr, Facebook, etc. are they using Core Data at all? If so, why and how?
Core Data is one way to give you a local database on the phone. With only MySQL on the server, the app cannot access any data when offline. Even in an online-only app, a local cache of some of the data can be useful to speed things up.
Similar to Django,where it has and database-abstraction API that lets you create, retrieve, update and delete objects, iOS has an CoreData. What under-lies is still SQL. From the django end, you need to create an api that returns the class of objects or something. On the iOS side, you have to call this api and parse the data and save it locally using CoreData.
Hope this helps..
I have a rather simple idea for an iPhone app. What I need to accomplish:
Allow login of users (which means I'll have to store usernames, passwords, and other account info).
Allow users to submit strings that other users can view.
Attributes attached to each string that must be tracked (i.e. "votes, views, comments, etc.).
As such, I assume I'll need to start learning about databases and working between a server and client. I've gotten my feet wet in OSX/iOS programming (specifically Objective-C) before. I want to learn how one can accomplish a data-based application and the needs I listed above.
I've done some light research and discovered something called SQLite (free and open-source is always good). Is this the right path to achieve what I want to do? I'm a total "noob" when it comes to this field of server/client/data "stuff".
Your help is greatly appreciated.
SQLLite is more like a local database. Really, the database that you will use is unimportant. It sounds like a project with webservices. Inside your webservices, you might connect to a Microsoft SQL Server or anything you want.
I think you should study how to setup a webservice that can be accessed in your code. Webservices is not an Objective-C topic, it applies to any platform. Your project is more like a web development project.
You can save user's credentials in keychain.
#Kinderchocolate is right about introducing database into your project.
It hears about a app which need transmitting data among clients.It means your need server database and local database.
For server database,I recommend you to use Parse.Parse is a platform which provide a convenient way to use their server database with Objective-c in your app.This tool will save many times and energy(it's not necessary to learn PHP,Apache,Mysql).Parse is not free of course,but it has a free period and enough for you to examine your idea.
Here's Parse!.
For local database,I recommend you to use Core Data,Which is provided by XCode.Core data is so strong to meet your need.You can find a way to use Core Data in many books.
Go try Firebase for database in the cloud. (On the server). In Swift 4 there is complete support for Firebase and SQLite
I have implemented an App which uses SQLite database, now if I run the App on a device then the database exist in that device only, now I want to use the same data on more than one device, can I do that?
You could use iCloud to copy your DB between devices. There are three ways you could do this.
Implement all the file presenter coordination code by hand. This would be difficult, but your existing read/write code would stay the same.
Wrap your DB in a UIDocument. This would be much easier, but your existing code to save and load your sqlite file would need to change. Conflicts would be resolved at a per-database level.
Port your DB code to use Core Data and use a UIManagedDocument. Your entire codebase would change, but conflicts would be resolved at a much lower level.
I heartily recommend Ray Wenderlich's tutorial series on iCloud, Beginning iCloud and iCloud and UIDocument: Beyond the basics
You need a Database Server to store your data & a Web service which should have the logic to store/fetch data from the Database-Server & Back to Database-Server. You can communicate between the DataBase Server & the Android Device using that Web Service.
On Android side you can use KSoap to consume the web service. See this example here.
I'm about to start an iOS project that requires pulling user's data from an SQL Database and viewing it within the App. Before I begin I'm looking for conformation that I'm taking the right (best) route.
My Plan:
App starts on login page (app will display data from another service)
App uses AFNetworking to post request to web service
Web service gets user data from SQL Database and sends back JSON
App uses JSONKit to parse the feed and load into Core-Data
App uses info from core-data to populate UI
Does this seem like an appropriate way to get the info into Core-Data from SQL? Any suggestions for doing things differently?
Thanks.
Are you receiving the response from the web server in JSON? If so, the fact that the server is using an SQL database is immaterial. What you need to know is how to parse JSON for inclusion in a core data store. Cocoa is my Girlfriend has a pretty good tutorial up.
Part 1
Part 2
To answer your comment, here's what I've done.
Display a login screen. The login credentials should be stored in the keychain for security. I've used SSKeychain for this.
To handle sending and receiving data from a web request your best option is to use a pre-built library. I've always used ASIHTTPRequest, but since it is no longer under active development, you should probably look around a bit before you commit to anything. I'm sure there are nicer and cleaner libraries out there.
You need to parse the JSON responses. I'm a fan of JSONKit. It's very fast, very easy to use, very robust.
Pulling data out of the core data store and displaying it in the interface will be no problem for you. If you create a new project in Xcode most of the setup will be done for you.
Now, there are a lot of projects out there that attempt to combine web requests, json parsing and core data loading into one framework. I've tried to use a few of these and haven't had much luck. The ones I've tried haven't been robust and very difficult to debug. Setting up your own request/parse/load code is not difficult at all, just a bit time consuming.
I am sure that there are a lot os ways to make implement this problem. Your solution is one of the popular solutions I guess but you could connect to the DB via a socket and talk with the database directly e.g. Going over a port 80 web site has the advantage that the possibility of some kind of firewall blocking the communication is very low. I would solve this kind of problem the same way I guess.