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.
Related
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 am really confused on what the Core Data actually is. Or I guess my question is, when dealing with a database, would you use Core Data? Like if I wanted access values from a database would I be using Core Data to access those values? How would I approach this problem?
Thank you so much for the help.
Core Data is an framework that does the work of "object persistence". In other words, it's code you can use that takes care of saving a collection of objects to disk and loading them again later. It does a lot of work to allow you to store lots of data and load only the objects you need at a time, and unload ones when memory is tight.
Core Data can use a database to accomplish this, but that's it's business, not yours. When you use Core Data, it is a black box. You tell it to save the data and then step out of the way.
If you want to interact with an existing database, such as a MySQL database on a web server, that's a completely different matter. You might use Core Data to store local copies of objects on your device, but in that case Core Data won't care that the objects are copies from some other database. It doesn't care.
It is a convenient, native means of storing data in your iOS applications. Don't think of it as sqlite although you can view the files it creates with various sqlite tools. Instead think of it as a tool for manipulating an object graph of information important to your app.
I've used it in two main ways. First to store a bunch of static data that is important to an app, in one case that was a large amount of location data for an indoor mapping application. What arrived as a massive CSV file of waypoints was converted to core data. Core Data was incredibly useful for this because it allowed preparing a sqlite file which was shipped with the application containing all the infomation. Updates from a web service arrive as more CSV that is added to the Core Data to keep information current. At runtime the location information object (the waypoint a user is at) is retrieved with a predicate (i.e. the point they tapped on) and that object, through its Core Data relationships, indicates where it is possible to go from that point. Core Data provided the information necessary to perform A* routing through the indoor map.
Second it is great when you have a bunch of objects arriving as JSON and you want to be able to store and access those objects later. Let's say you have a typical app where you have a User and some information about the User, let's call it Thing. Users have Things. When you want to know something about a User you retrieve the Core Data record using a predicate - typically "name" or similar - and you get all the information you stored about the User back. Again you can make use of relationships to explore the user's connections and make displaying information easy. Perhaps the User has many Things, then you can say "user.things" and you get a NSSet of NSManagedObjects representing those Things.
You use it like a database. Its utility is that it is easy to access from anywhere in your iOS code, it is easy to store and easy to retrieve information also. Faulting lets you retrieve one object and navigate to any object connected through relationships by following the relationships. Because you define the attributes and relationships yourself in the data model editor it is easily customized for what you need to store. To me it is one of the most used and most useful parts of iOS.
When you want to automate display of information from Core Data you can use a NSFetchedResultsController to initiate a fetch and to respond through delegate methods to changes to the underlying data. If you set up a UITableView to use a NSFetchedResultsController as data source, you can have the table automatically update whenever the objects displayed in the cells changed. Very useful for apps where you periodically update information and want what is displayed to be kept current.
When your object model changes it is possible to maintain all of your existing information and migrate it to the new model. Core Data manages automatic (lightweight migration) when it can, or if you have made more radical changes you can supply rules to handle the migration.
The limitation of Core Data is that it is not great for storing binaries. If you have images that you need to store, far better to store a path to the location of the image than trying to store the actual data.
Yes, if you want a local database on your device, Core Data is the appropriate technology. It probably makes sense to start your research with the Core Data Programming Guide.
You can alternatively use SQLite (which Core Data uses in the backend), but Core Data offers some material advantages and is the preferred database interface for iOS. If you decide to pursue SQLite for any reason, though, I'd suggest you contemplate using the FMDB Objective-C SQLite wrapper.
But Core Data is generally the way to go.
I want to build an app that uses core data, but all the tutorials I found in the net didn't show if I can store a data without using the code it self.
Is there anyway to do it?
For example, i want to make a row of name and put there couple of names.
I've just read the book "Pro Core Data for iOS" from APRESS it covers Core Data very well. I recommend this by heart.
You can try Core Data Editor. But it's not cheap.
You can use SQLite directly without Core Data; there you'd have your SQLs in your own hands. Your can use Core Data and debug SQLs issued by the framework, of course if using SQLite as the store.
Core Data works also with binary and XML format (the latter not available on iPhone): passing following argument to the application:
-com.apple.CoreData.SQLDebug 1
Other than that, you could probably use SQL to access Core Data SQLite store, since it is all SQL, but it is not recommended.
Unfortunately Core Data is all code. However, CoreData is an api that helps you create, save, load data from the database, it uses SQLLite in an easier fashion.
If you need very complex data storage then by all means use SQLLite directly. But, if it's just simple data storage of names, emails, booleans, etc, then i would recommend CoreData.
I'll give you a link that it helped me greatly when i wanted to integrate CoreData for my app.
CoreData Tutorial
Good Luck.
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.
I am new to the iphone platform and am creating an app that retrievals a rss feed and displays it in a UITableView. I have gotten this working perfectly (or rather, the way I wanted). What I was thinking was I would store the current feed items on the phone so that it would initally load the old items it has stored while it got the new feed, then parse the new feed and add the new items and refresh the TableView. I was going to use Core Data to store it the old feed items because it would be a good way of learning Core Data and it would be an appropriate use of Core Data. However, I am having a difficult time learning how to use Core Data and connecting it with the Table/Array.
I have already googled and looked on stackoverflow for tutorials but have yet to find anything that explains it in a way I really understand. Any explanation of the overall steps that it takes to add Core Data to an existing app would be greatly appreciated. Full-blown detail are not necessary (but would also be useful). I'm just not very experienced with SQL or storing of data in such a manner and am having trouble wrapping my head around how the whole concept of Core Data works and how it connects to everything.
Also, any better method of doing what I'm trying to accomplish would also be appreciated.
There exist Xcode templates for Core Data-based applications; these are a great start to getting Core Data off the ground. However, it sounds like you want to integrate Core Data into your existing app, so you'll need to...
Add three main Core Data objects: the managed object context (MOC), the managed object model (MOM), and the persistent store coordinator (PSC). These need to be accessible wherever you want Core Data available, so either in your app delegate or, more preferably, in the controller or data source for your table view.
Create a MOM in Xcode. This will be a file of type .xcdatamodel, and it's an object graph that defines all the Core Data entities you want in your app.
Use NSFetchedResultsController (as suggested by Louis Gerbarg) to get data out of Core Data and display it into your table view.
Add code in your existing RSS-fetching-and-parsing routines to store new Core Data objects back into the store, when appropriate.
A good way to start is just to create a new Core Data application and play around with it a bit; you can also look at Apple's fantastic resources on the subject, like the Core Data Programming Guide and the sample apps Recipes and Locations. (Developer registration may be required.)
One last thing to note is that for the most part, a lot of the Core Data code you need to add can be ripped straight out of one of the Xcode template apps and pasted into your program (this holds especially true for the accessors for the three Core Data objects you need). Be careful not to use code you don't understand, though.
If you are using CoreData to populate a UITableView you really want to use NSFetchedResultsController as opposed to trying to populate and sync array yourself. The documentation for NSFetchedResultsController includes links to several CoreData tutorials, including onces that populate table views.
NSFetchedResultsController is still a bit buggy and requires fragile workarounds. I would start with the simpler iPhone Core Data "location" tutorial before moving on to the Books tutorial.
Also, any better method of doing what I'm trying to accomplish would also be appreciate
yes, it sounds like Core Data might be overkill for your application. Assuming your feed items are stored in a collection object you can easily use OSX's built in serializaition.
Been noted in other Stack-Overflow posts, but I can highly recommend the Prag Prog book "Core Data: Apple's API for Persisting Data on Mac OS X" - most is also relevant to iPhone Core Data apps; there is a whole chapter on creating an iPhone app too.
http://pragprog.com/titles/mzcd/core-data