I am considering backing up data from an iPhone application using the Google App Engine (GAE) - I was also considering using Python to build a RESTful app to deal with incoming/outgoing data.
On the client side I am using Core Data to store the information I wish to back up, and retrieve using the GAE.
I was wondering whether there were any good tutorials/resources on carrying out the above or whether this is perhaps something that others have tried to implement.
Any advice, or pointers, would be most welcome.
An open-source implementation of a REST server for GAE-python is available here.
I know nothing about core-data, but I you could easily store the objects in GAE if you are able to serialize them as binary or xml.
Binary objects up to 1Mb can be stored as BlobProperty, and strings as TextProperty.
There is also a Blobstore API for objects up to 50 megabytes.
If you want to store your data on a server (or sync it) then you want to go through a intermediary format. I personally recommend JSON as it can be used with Core Data easily. Since you can retrieve a dictionary of all the values in an object it is trivial to convert that diction to JSON data and push it over the wire to your server. Your server can then retrieve that JSON data and translate it into whatever format the server wants to store it in.
Do you want to map your core data objects onto GAE datastore objects? If so, this could be tricky. As you say, you would have to implement the server logic with python or Java, and you r iPhone objects are in Objective-C. You would need some scheme to serialize / deserialize them.
An easier approach, if all you wanted GAE for was backup, would be to serialize the Core data objects and store them as blobs with key-value pairs in GAE.
I'm not aware of any similar approaches so I'll be keeping an eye on this post.
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 am developing iPhone app for a web application currently running online. Current web application is big and complex and uses SQL to store vital information like member details, login credentials etx. Other stuffs like info about several sections, groups, sub groups and other information related to each are saved in txt. Current system uses its own standard to keep data in files and also made custom algorithm to read and write data in it. Each txt file is below 1 mb size. There are lot of data manipulations going on.
Custom algorithm created just read those files and put all data in cache as records (same as in core data managedobjectcontext) and whenever there is a change in data the whole file is overwritten.
So while implementing the same what I want to choose for iPhone app? In apple website they said that 'SQLite is perfect for low-level relational database work' https://developer.apple.com/technologies/ios/data-management.html But in my case it is high level.
So please help me to make a decision. Do I want to manage data in files or sqlite database using core data?
I would also like to know whether it is possible to import those classes and algorithms currently in webserver to iOS, so I don't want to rewrite the same algorithm for iOS? Current server codes are in C#
In the rare case that you need to do low-level relational database work use SQLite. In the 99% other cases use Core Data. Don't ever store relational stuff into txt files. It'll just be a pain.
Your use case sounds like a good match for Core Data.
Often misunderstood, Core Data is an object store that happens to use sqlite for persistence. You don't manipulate the sqlite underneath it, Core Data manage the sqlite for you. You do not write SQL. The closest match to it in .NET is EDM and the Entity Framework in ADO.NET.
Assuming the classes and algorithm you want to import in the webserver is in C#, sadly those needed to be ported to Obj-C.
I'm prototyping a simple sports sim game for iPhone which will use Core data.
One the biggest challenges I'm facing is how to get the data into Core data in the first place.
The second biggest challenge is whether I should use core data's persistent stores or use fixed files (JSON) for pre-fixed game data.
--
Concept
The general concept is that a player can start a new game or continue an existing one.
When they start new game they would use pre-fixed data. (IE. A database which is read-only.)
When they continue game they would use a different database (the game database).
I am not sure how to deliver such a feature.
--
Prototype
Currently, I am experimenting with this prototype:
PHP Web App -> 2. API -> 3. iPhone
A local PHP web app which acts as a CMS.
A basic API which lets me expose specific data in a JSON format.
Read the JSON into Core Data using TouchJSON/other tools.
I have no intention of making the API public/online (for various reasons), so the method I have described is a only meant to ever be a one-way process.
This will of course cause a problem because I need to make the data read-only.
--
In sports sim games you will often find them using fixed files (.txt, .csv, .dat, etc) and then they read this data into memory or a database.
Therefore, using this concept I could:
Save the JSON as fixed files and read them at run-time into memory/core data.
And then whenever the player starts a new game, the existing core data store will simply be wiped.
However, having said that I've heard that you can use persistent stores as a method to overcome this problem.
Therefore I was thinking of setting up 2 persistent stores;
1) A pre-fixed read-only persistent store
2) The actual game store (which gets overwritten if you start a new game).
But which is better?
Creating JSON fixed files for consumption, or using 2 persistent stores?
I apologize if my question/concept is overly complex; but would welcome better/simpler solutions where possible.
I think you can use Core Data for applications that is going to store data on it and the database is empty when it starts but if you needed you data store to be pre-populated with data it is better to load it from fixed data like sqlite or xml files.
I am writing an application where we communicate with a web service in json. I would love to cache data from this service, so that the user always can show cached data while we are fetching updated data.
I have looked into a minor project; Core Resource that is a layer over Core Data. It converts from JSON to data objects, and it looks very promising. Since this project does not have a large community or high progression in further development, I am not sure if it is smart to use for me.
Do anyone know about a similar project? Or should I make it my self with just an JSON library and Core Data?
It is trivial to convert JSON to Core Data and backwards. I actually posted an answer here on Stack Overflow that walks through that.
JSON and Core Data on the iPhone
Other than that, using NSURLConnection to push and pull the data is all you really need. A "library" for this seems like an extra unneeded complexity.
An idea could be to use the URL-cache of NSURLConnection of the regular iPhone URL Loading System which supports caching on URL level. This will work especially in context of RESTFUL webservices. You can use the API's in-build cache or implement you own chaching strategy. (see here) If you don't want to persist your cache, you wouldn't need CoreData.
I am a newbie in Xcode. I am developing an iPhone app where I need to send and receive data from a web service. And I need to store them temporarily in my app. I don't want to use SQLite. So I wondering if I should use core data for this purpose. I read some articles but I still don't have a clear picture of How to do it, because I have used core data only with SQLite. I want to do the following things :
How to receive table data from a web service?
Have to perform certain calculations on those fields.
How to send the data back in xml format to the server?
How do I convert the xml data into int, date or any other data type? And How do I store it in managed data objects?
You want to use an XML parser to turn the XML into other objects; I tend to recommend TouchXML for that.
You can use Core Data and an in memory store if you are not going to save the data as it will then create and manage all of the data objects for you and generally give you less code to write. However that depends on your app if it is worth it or not. Personally i use Core Data in every app that works with data.
As for sending data, you can use the same library that you used to consume the XML to produce XML. Most of them now days are bi-directional.
For a specific example of fetching XML from server and then storing on the device using core data take a look at Björn Sållarp's blog post on Core Data and UITableView. A drill-down application. Note this example makes use of NSXMLParser and not TouchXML.
I have also found [coredatalibrary xcode template][2] to be quite useful in getting started with a new Core Data project.
Also if you are adding custom logic to your managed objects take a look at rentzch's [mogenerator][3] which generates 2 classes _MyEntity and its subclass MyEntity.