I'm creating an app for iPhone, and I want it to load data from an external file (from an URL in a server), to display the hints.
I have read several tutorials, but I don't know yet what is more convenient for me:
Do I use CoreData?
Do I create a .sql file and I try to do queries inside the code of my app?
Do I use a .txt file and try to parse it?
Do I use a .xml file?
I have to say I'm quite lost at this point, and I really don't know what would be more effective, easy to write (code). And I don't how to access to a file that is in a server and not in the folder of the app itself.
If your loading data from an external server take a look at Rest Kit. It allows you to map an API to objects that are backed by Core Data. http://restkit.org/
Personally I would use CoreData simply because you get a lot of power out of the box right from Core Data, instead of trying to deal with raw sql queries or parsing data.
Another option if your looking for the simplest way to grab a file from a server and map it to an object is to look at .plists for example:
NSDictionary *data = [dict initWithContentsOfURL:[NSURL URLWithString:#"http://server.com/data.plist"]];
Although be careful with that call though because its not asynchronous, and if the file is large and call is made from the Main thread it will block the application.
The best way to implement database on iPhone SDK is to use CORE Data.
- It prevents you to write long sql scripts to fetch & write data in db.
- Easy Implementation.
- Excellent UI to simulate.
- portable
- Can upgrade later if any enhancement required after some time.
So I would like to suggest you to save your data using Core Data. you need to fetch your data from server & call simple methods to save it into App DB using Core data. You even dont need to do much manipulation into it.
Following are some Nice Links for some tutorials:
http://mobile.tutsplus.com/tutorials/iphone/advanced-restkit-development_iphone-sdk/
http://mobile.tutsplus.com/tutorials/iphone/iphone-core-data/
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 want to fetch data from web server and save it in my local database through sqllite.How is it possible.
You can fetch data from webserver using JSON and webservice and then parse the JSON Response string.
Then you may create insert statements from the data obtained and execute it to insert in your database using executeNonQuery method of SQLite.
Best option is to do all this on appDidFinishLaunching so that there would be initial delay but then whole app after that would not face any performance issues i.e. No delays
Hope this helps you.
Well,
it depends on what kind of data you want to fetch. If you want to fetch XML from the webserver, you will get a nice list of xml parsers on this site: http://www.raywenderlich.com/553/how-to-chose-the-best-xml-parser-for-your-iphone-project
Another nice option for fetching any kind of data from the webserver is curl. You can find static libraries on this page: http://code.google.com/p/ios-static-libraries/
Well, there's always the option to use the iOS native libraries, which are documented (with examples) in the iOS SDK.
I would not recommend using "raw" SQLite these days unless you have an exceptional reason to do so. Core Data is the way forward.
I'm not really sure what your question is; it's so broad. But, in general, you'd create an NSURLConnection, download the data, parse the data and store it in your database. Each stage is pretty well documented and there are lots of questions here on each stage.
If you use Core Data there are also some open source projects, such as RestKit, that might give you a good starting point.
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.
I need build a client server iphone app. Want to store a database on server and save it too on client's iphone. What strategy and what dbms' and tools i must use for it? AS my database can be enough heavy
This is EASY. If you control both parts of the system.
The magic word here is PLIST's.
IBM have a great example with an iPhone source project and a working google app engine deploy.
http://www.ibm.com/developerworks/web/library/wa-aj-iphone/
Here is some ultra basic code.
// SaveOnline.
NSMutableArray *myArray = [NSMutableArray arrayWithObjects:#"one",#"two",nil];
NSURL *url = [NSURL URLWithString:#"http://www.hurl.ws/api/"];
ok = [myArray writeToURL:url atomically:NO];
if(ok) NSLog(#"saved worked");
You can also load this PLIST from the URL and load it back into your object pretty easily as well. The whole PLIST system is very cool. It is slighly verbose but I would not worry about that as it is ultra flexible and in the long run is going to save you hour and hours of debugging.
I also noticed there a lots of libraries on the server to convert PLISTs into native objects for PHP, Python and assume you can find libraries for Java or .Net.
Dont think about trying to do it in XML your self, its going to get messy ultra quick and yo are going to loose so much time trying to fix it when you dont need.
PLIST's are you friend so use them. John.
For saving to the server, you can try out Parse: http://www.parse.com, they seem to have an easy system for storing data (without you setting up any servers).
On top of that, you can go with persisting the data locally as plist files. Here's a pretty good rundown of the different types of storage options: http://doganberktas.com/2010/10/16/data-storage-alternatives-on-ios-in-a-nutshell/
If you're going for simple, you should just go with storing data in a plist, preferably using the NSCoding protocol, which will allow you to easily store arbitrary objects.
If your database objects are complex you will probably want to use core data and model the objects your own way in the iphone. Of course you will have to sort of translate them when you are going from your service database to storing in core data but that should not be too difficult. If you getting and XML or Json response from your service you should be able to easily parse them and construct your objects over on the iphone and just simply use core data to store them.
The database that you are using on the server side doesn't matter, it's just a black box to the iPhone app. The app can communicate with this server via HTTP using XML, or PLISTs or JSON as John and Daniel recommend.
As far as what's easiest, just go with what server side language you already know. It's probably easiest to run it on something akin to Google app engine, I'd imagine.
bpapa you note "the app can communicate with this server via HTTP using XML", I assume from that you mean web services?
I ask because I'm trying to demystify getting data from the iPhone to a data store such as provided by Google App Engine, and back.
Thanks // :)
P.S.) More to the point of this thread, Google has a great solution for scaleable data store creation without large capital investment. I've been looking at it, Amazon Web Services, and Windows Azure. It seems that, unless you have a heavy reliance on or strong ability in .net, Google's solution makes sense.