I am creating a Questions and answers app for iphone which allows user to answer the questions displayed.
Currently I am invoking a web service to store the users answers. But I am slightly worried what if the web service goes down. I need to store the users answers locally and then invoke the web service when it is up and running.
How can I store the users answers when the web service is down. Is Sqllite a good option for this?
Please suggest.
Thanks,
Is Sqllite a good option for this?
Yes, SQLite is decidedly a good option. The other choice would be Core Data.
Use CoreData or SQLite on iPhone?
It depends on the complexity of your data model. I've looked into something like this recently and here is what I learnt. The most popular data storage methods in the iPhone are:
plist
Good for small quantities (hundreds of Ks) of hierarchical data.
Bad if relationships or queries are complex (since you have to write the code).
Very easy to learn.
Supports array, dict, string, data, date, integer, real, boolean elements.
You can store it as XML, which is editable and portable, or as binary files, which is faster.
Core Data
It's a object graph manager with searching and persistent functionality.
You need a good few hours of learning.
Easy to use once you set it up.
Better than a plist because it lets you manage object graphs, grow your object model, write queries, undo/redo, migrations to modified data models, memory management, and handle concurrent access.
Better than SQLite because:
The performance is similar and the speed of development is faster.
Creating objects is faster.
When the objects are in memory, executing queries doesn't require a search in the backend (which usually is either memory or SQLite).
SQLite
A database.
Better than Core Data when the operation doesn't require you to bring objects to memory. Example: update, delete, and select 1 (see if something exists).
It has full text search if you compile the extension.
Hardest to learn. Easier if you use a wrapper: FMDB, egodatabase.
If you can get away with a plist do that. If you see the amount of code you will have to write is too much work, then switch to Core Data. Only if you are an expert and absolutely need the performance use SQLite (unless, of course, you already know SQLite and not Core Data).
It should be, yes. I'd set up a Core Data based app with entities for Questions and Answers and set up relationships between them. Then just use NSFetchedResultsController or whatever you would like to gather and display the data
You have several options:
Sqlite
Core Data
Client-Side storage
If you wish to go the web based route, I'd take a quick look at Safari Client-Side Storage and Offline Applications Programming Guide.
Basically, you store a local copy of the database in memory so incase the web service is down, users can still use the app.
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 am new to iPhone app development and have a question about storing data. I've spent quite sometime learning about core data but still confused about the concept of persistence store.
What I understand is that core data is just a way of managing the data you downloaded from an external database. But given that core data is backed by SQLite, does that mean there exists a SQLite db in-memory while running? If so, does that mean when I use core data it will be more effective if I download a huge data set at start? But what about apps such as twitter or Facebook that require constant update of data, is a straight $NSURLConnection$ sufficient in these cases? If core data is used, will the extra overheads (i.e. data objects) be of any burden for such frequent request of update?
I would also like to find out some common ways of setting up an online database for iPhone app? Is it usually MySQL servers with a homemade Python wrapper that translates the data into JSON? Any standard server provider would provide the whole package? Or open source code?
Many many thanks!
I'm going to go through and try to address each of your questions, let me know if I missed one!
Firstly, Core Data can be used to store information generated in your app as well, there is nothing keeping you from using it in one way or another.
The way I understand it working is that the file, or other storage mechanism Core Data uses, exists regardless of whether or not your app is running. For a user to have to wait for a large database to be downloaded and loaded into a local database without being able to interact with your application is not the best way to do it in my opinion, people react negatively unresponsive UI. When a user may run your app for the first time, its possible you may need to get a larger set of data, but if any of it is generic and can be preloaded that is ideal, the rest should be downloaded as the user attempts to access it.
Facebook and Twitter applications work just as you understand in that a connection is established and the information is pulled from the appropriate site, the only thing they store is profile information, as far as I know. I would hesitate to use Core Data to store peoples information as eventually yes, there would be a significant amount of overhead caused by having to store peoples news feed or messages going back months on end.
As for setting up on online database that is something I'm unfamiliar with, so hopefully someone else can provide some insight on that, or if I find something I think may be of use, I will post back here for you. This part may actually merit its own separate question.
Let me know if you need to me elaborate on anything!
So I have been doing lots of reading and found out NSCache is not persistent which is a slight problem for what I need to do. I have heard that I will need to use Core data instead... but I don't have any experience with core data so am wondering if its the only solution for persistent data.
The app will allow the user to search through a catalog, by typing in a search parameter in the code and select a distributor for their search parameter. What I want to do when the app loads is download the list of distributors and save them to a "cache" the will be persistent (till when the header I will make at some point changes and demands the app to update the cache), so that if the user turns the app of or the phone next time then open it the manufacture.
Now that I'm getting abit deeper into my app I'm getting abit lost in things for instance how would setting up a cache work with regards to NSURLConnection.
Any suggestions or code examples would be greatly appreciated..
This previous answer of mine might help you decide.
To sum it up:
If your data is small, static and low-complexity, use a collection class and write it to disk using the built-in class methods
If the data is static, low-complexity but large, SQL may be a good solution especially if you already know it.
If the data is dynamic and complex regardless of size, then Core Data is your best choice.
Viewed purely from the technical perspective, Core Data is always the best choice for iOS/MacOS API apps. Core Data is not just a persistence API, it is an API for creating the model layer of the Model-View-Controller design paradigm that the Apple API uses. It not only persist the data, but models it, validates its and provides an easy interface to the rest of the API.
If your going to be writing iOS apps, you need to eventually learn Core Data. However, it does have a learning curve and you should pick the method right now that will let you ship a usable app.
You can also check out sqlite. Here's another question that discusses getting started with sqlite on the phone: Where's the best SQLite 3 tutorial for iPhone-SDK?
The advantage to sqlite is that it is fairly easy to pick up. The downside is that you have to write queries for everything, and that can be a pain. It doesn't save objects, just data, numbers or text.
We're beginning development of an in-house app in the iPhone Enterprise developer program. Since it's close to OS 3.0, we're reconsidering our original design of using SQLite and using Core Data instead. Here's some more info:
There is a legacy desktop application that this is replacing. We will reuse the existing back end.
We currently have a SQLite database generated as a proof of concept. This is basically a cut down version of the existing back end database.
We will be loading data from a remote site and storing it locally, where it will persist and need to be . We only update it if it has changed, which will be every month or two. We will most likely use XML or JSON to transfer the data.
There are two developers on this project and we both have strong SQL skills but neither one has used Core Data.
My questions are: what is the benefit of Core Data over SQLite, what would the benefit be in this specific instance and do the benefits justify learning a new framework instead of using existing strong SQL skills?
EDIT:
I just noticed this question: Core Data vs SQLite 3. I guess my questions therefore are:
If I have to check if a specific item either exists or has an update, which is easy using SQL, does Core Data still make sense? Can I load the first object in a graph and check the version number without loading the whole graph?
If we already know SQL, does the advantages of Core Data for this one project justify us learning it?
As you've read Core Data vs SQLite 3, you know that Core Data and the persistence mechanism (SQLite in this case) are largely orthogonal. Core Data is really about managing an object graph and it's main use case is for the model component of an MVC architecture. If your application fits nicely into this architecture, it's probably worth using Core Data as it will save you a lot of code in the model component. If you already have a working model component (e.g. from the existing desktop app), then Core Data won't buy you much. A hybrid approach is possible-- you can do your own persistence/querying and build a Core Data in memory store which you populate with the result of a query and use this in-memory store via Core Data as the model component for your app. This isn't common, but I've done it and there are no major roadblocks.
To answer your specific questions:
You can assign a version number to the entire persistent store and retrieve that information via +[NSPersistentStore metadataForPersistentStoreWithURL:error:], without even opening the store. An equivalent +setMetadata:forPersistentStoreWithURL:error also exists, of course. If you want to store the version info in an entity instance instead of in the persistent store metadata, you can load only a single object. With an SQLite persistent store, Core Data does a very good job of fetching only what you need.
The NSPredicate API, is very easy to learn and it seems to do a decent job of compilation to SQL. At least for databases of the size you could fit on an iPhone it's certainly been adequate (performance wise) in my experience. I think the SQL vs. Core Data question is slightly misguided, however. Once you get the result of a query what are you going to do with it? If you roll your own, you'll have to instantiate objects, handle faulting/uniqueing (if you don't want to load the entire result of a query into memory immediately) and all of the other object graph management facilities already provided by Core Data.
It sounds like you already have the project designed using SQLite, and you have experience in that area.
So the bottom line is, does it make sense to port this project, will Core Data give me anything that I didn't already have in my original design?
Assuming that the original design was done properly, based on the requirements ON THIS PROJECT, it's probably not worth it.
But that's not the end of the discussion. There are other things to think about: Will my next project have such light database requirements? Do I need to ship soon, due to timeline or budget constraints? Assuming I'm going to have to learn Core Data sooner or later, doesn't it make sense to do it now? Am I possibly interested in porting my code over to the Mac?
The answers to these questions may lead you to the decision that yes, it is indeed worth it to go back to the drawing board so to speak, and learn what Core Data is all about.
To get to your final question: What are the advantages? Well, Core Data is a higher level abstraction of your database, it is also data store agnostic (so if a future version of the iPhone were to ditch SQLite for an embedded version of MySQL... unlikely, but it's an example) then Core Data would require VERY few changes to the code to make it work with the new data store. Core Data will provide a great deal of quick portability to the Mac platform. Core Data will handle versioning of your data model, whereas unless you have a framework or a workflow to manage it, direct access to SQLite won't.
I'm sure other answerers can come up with other advantages, and maybe some good reasons why NOT to mess with Core Data. Incidentally, in a similar situation, my decision was to port to the higher level, newer framework. But in my case, it was for a side project, and ship date and budget were non-factors.
Not to detract from this forum, but you might find more respondents with contextually relevant experience at the Apple iPhone DevForum.
Speaking from a purely project management perspective, it sounds like you know how to build what you want to build using SQLite, and so it would make more sense to me for you to start along that route.
That being said, CoreData builds on top of SQLite and if you are trying to leverage other parts of the system in conjunction with your data, e.g. using KVC/KVO or bindings, then you may quickly find that this functionality is worth the learning curve.
= Mike