i am trying to develop a simple application like shopping list.
for that i have 20 categories in that 250 item names.
for that i found two ways to save these item names and it's respective values one is using sqlite data base,another one is plist.
and i need to edit these item quantity and need to add new item to category.
for that which way is better for my application.
experts who have familiar with sqlite data base and plist can suggest which way is better.
thank u in advance.
My feeling is that SQLite is the better tool for this job, especially when the data grows. That's because with a PList, you have to completely load it into memory whereas with SQLite you only fetch the data you need. Of course, programming for SQLite is a little bit more work but if you encapsulate that in a class it can be as easy to use later on.
Using of SQLite would be suggested.
If you are doing more transaction over the database then use SQLite instead of plits.
If it is client- server modal, have a database of SQL or Oracle at the back end. Store the data which is frequently used at the client side using SQLite ans sync it regularly with the database
regarding sqlite tutorial
http://dblog.com.au/iphone-development-tutorials/iphone-sdk-tutorial-reading-data-from-a-sqlite-database/
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.
Hi I am a newbie to iPhone programming. I have been looking at some tutorials online for using SQLite on the iPhone.
From what Iv'e seen, one has to read the entire database in the app delegate method and then store the contents in an array. This is then used to populate a UITableView.
I was wondering how this can be efficient? I mean, if you are going to store the contents of your entire database in memory why have a database?
Is this standard practice?
Instead of this, if I use Core Data, I can set the paging size and it will optimize how much data is stored in memory and only read whats being shown within the visible cells.
Is there anyway, In can have the same functionality using SQLite? so its easy on memory. I mean my database has only 300 entries now, but what if in the future it has 3 million?
Can some one please assist me in understanding this....
Are there any tutorials for SQLite that show how to do it in an optimized way?
Thanks
I would suggest using Core Data. It's extremely powerful, better supported than a SQLite table, and not as complicated as it looks, it just uses a lot of "managed object" jargon which can be daunting at first. Check out the CoreDataHelper class, and a few tutorials. I was able to get Core Data working in a few days (in my first ever app) using the links in my comment
If you're familiar with SQL, basically Core Data works like this: the Persistent Store IS a SQLite table, but you never access it directly; the managedObjectContext is where you do all the data work in your program (and don't forget to save it to the persistent store!), while an Entity is a table, attributes of that entity are your columns, and a managed object is a row.
Further Reading:
Core Data Tutorial - YouTube
Core Data Tutorial: Getting Started | Ray Wenderlich
iPhone Core Data: Your First Steps
Here is some tutorial that may help you:
iPhone Programming Tutorial.
I recommend you consider using core data instead of sqlite.
I am new to iPhone development and want to know which database you use to program an iPhone/iPad?
I have heard its SQLite, are there any alternatives to this?
The application I am programming is like an online shop however you can't buy products, only view their details.
You should use CoreData for that. CoreData is a database abstraction layer which uses SQLite to store your data. Or you could use SQLite directly. But I would prefer CoreData.
Core Data Programming Guide
Core Data Overview
If you have any plan to use the database file outside iPhone e.g. in other computer, or data input program to populate data, then SQlite is the best choice. CoreData modify the fields name when you create the database inside XCode. But if the data is only accessed by your app in the iPhone, best choice is CoreData.
If you want to run complex sql query then sqlite is better. Read about NSPredicate, what type of query you can do there.
SQLite is the master choice here!
As an alternative, I would suggest you the simplicity of an XML file.
You can also use NSUserDefaults if u have less data to be stored in your database.
http://icodeblog.com/2008/10/03/iphone-programming-tutorial-savingretrieving-data-using-nsuserdefaults/
If the data to be stored is more then go for sqlite
So I have a question about the ideal setup for an app I am getting ready to build. The app is basically going to be a memorization tool and I already have an sqlite database full of content that I will be using for the app.
The user will navigate through the contents of the database(using the uipickerview), and select something for memorization. If that row or cell of data is selected, it is put into a pool or a uitableview that is dedicated to showing which items you have in your "need to memorize" pool. When you go to that tableview, you can select the row, and the actual data would be populated. All information in the tableview would be deletable, in the event that they don't want it there anymore...
Thats it.
I know that with database interfacing, there are a few different options out there, in this particular setup, is core data the easiest approach? Is there any other way that would be better? I am just kind of looking for a point in the right direction, any help is greatly appreciated!!
Core Data is going to be the easiest. You will want to migrate your data from your raw SQLite file to a Core Data generated SQLite file as Core Data is designed to manage its own file 100%. Fortunately you can do this with a quick command line app on the desktop and then copy the resulting Core Data Sqlite file into your application bundle for later use on iOS.
Doing raw SQLite on iOS is possible but a real headache to get right compared to the ease of use that Core Data offers.
Update
Core Data on iOS produces identical files to Core Data on the Desktop. Therefore you can develop a quick and easy app for the desktop that say for example takes the following inputs:
Table/Entity Name
CSV of a row of data
Then it would create a Core Data entity based on the entity name and insert the data into that row.
With that in place it would be trivial to do a bash script to loop through the all of the tables and the rows in those tables to create your new SQLite file.
Hmmm, might have to do a blog post some time on CIMGF about this :)
I would like to begin work on an iPhone app that does little more than display a books content for reading. The book content is available online, and is fully open source, but I would like to make the content available locally. With apps that I have worked on previously, namely with iPhone OS 2.X, creating (or finding) an .sql database and then just making queries for data from within the app worked really well. With the advent of Core Data (which I am not that familiar with) the older sql method may not be ideal. So my question is: What is the best way for me to go from online web content to locally stored iPhone readable content? Regardless of which approach I take, I am going to need a db (right?), so should I get the brunt of it out of the way and start with importing the web content into a db with all of the correct tables and columns? I guess with this question, I am just looking for a point in the right direction. If there were any suggestions about the best method for me to get rolling on this, it would be greatly appreciated. Thanks!
Core Data is good if you have "objects" that you want to make persistent. In the case of having just a lot of data to read/write, plain old SQLite may be simpler.
Sorry that I can't give any more specific advice, but it comes down to how complicated your app's data model and object models are. I'd recommend looking at Core Data, but don't use it just because everybody tells you how cool it is.
If you go with Core Data, you won't define your own SQL database schema, so don't start down that path until you've made the decision.
I actually would go with the Core Data route. Core Data is just an API provided by Apple to manage persistent data no matter the data backend (wether it is a flat plist file, an XML file, or a full sqlite database file).
In the case of a book, you can break down the entities as follows.
Book Entity
Title which is a String Attribute
Author which is a String Attribute
chapters which is a has many relationship of Chapter Entities
Chapter Entity
Title which is a String Attribute
pages which is a has many relationship of Page Entities
Page Entity
PageText which is a String Attribute
Then you can access all the values as if they are objects using Core Data without having to worry about the SQL backend code, and writing all the code to translate the SQLite datatypes to Cocoa objects that your view controllers can display.