I want to download a hosted XML document into my app's bundled SQLite database, updating existing rows, or inserting new rows of data as necessary.
My thoughts as far as app design are this:
App loads.
App looks for a connection to XML Host.
If connection exists, App consumes the hosted XML document, updating row and column data in the bundled SQLite database, adding any new rows if new rows exist in the XML document. If no connection exists, App uses the previously stored data in the SQLite database.
User has a merry time using the app, oblivious to the state of the data.
Is this the right approach? Is there a better way to do this? How do I do bulk inserts and updates from an XML document into my SQLite database. I've only seen examples of how to do this row by row. My data is hundreds of rows by 10 columns.
Any insight is greatly appreciated.
lq
I found a link that answers my question and provides a working example of taking an XML document and inserting it into a SQLite database: http://blog.sallarp.com/iphone-core-data-uitableview-drill-down/
I think your idea is ok.. I have developed "Movie Vault for iPad" app and its doing the exactly same thing. This app also have lot of movies data to download and its working quite well. You can also do one thing you can give a "Refresh" button and when user click/tap on this button you can download the xml and insert it in database in a secondary thread.
Related
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/
I hope all of you have had a good Christmas :-)
In my app i have a database, using Core Data, that requires a lot of data, at least 1.500 records consisting of 6 fields. That means at least 9.000 lines of data. All data is pure text.
During the development phase i have 250 records to test on.
The way i do populate the DB at this point is that i have a text (.txt) file, which i edit in Word and then reads into my database. This is very inconvenient for many reasons such as if i save it, by mistake, in the wrong format it all screws up (i have Swedish characters that changes).
Given the amount of records i will need i would like to ask for advice how people do these things and what to use? Is there some sort of (free) database available that i could use etc.
Cheers
For editing use notepad, notepad++, or gedit. You won't have issues with MS Word specific characters.
I am not too familiar with Core Data, but I believe it uses SQlite on the backend.
I have implemented SQLite directly into a few developments that I have worked on. It might be worth your time to take a look.
Can you give more details about your app? Platform, how often data is accessed, how often it is modified, etc.
Hmm, one way to get started on this might be to fill the Core Data store a single time, and then, whenever you need to run your tests, just copy this store file out of your application bundle into your documents directory. I maintain a "Reset All" function in a game I've worked on using this method, and it works great for very quickly populating Core Data.
Hej,
currently I am developing an app with very similar requirements - a prepopulated Core Data database with 1200+ entries with more or less the same amount of fields.
The data I receive is in xml format. I've written a small mac app which features the same core data model as the iphone app does - it will read the xml and create core data entries accordingly. I then take the database file my mac app created and add it to my iphone apps bundle, from where it will be copied to the documents folder on the first launch (or whenever a reset to the factory data is required).
This is working perfectly, I think you could do something very similar. The only difference would be that, instead of parsing xml, you'd need to write something that reads your textfile. Fear not, it's easy to do!
I've taken the approach to add a unit test that determines if the database exists. If the database doesn't exist, the test creates it from a text file (usually a plist or csv).
This approach enables me to: alter the underlying data via text, "clean" the database by simply deleting it, and run tests against the data. Since you're using CoreData, there might be some additional benefits by ensuring your schema matches the dataset; I once found I'd accidentally set an attribute to not allow nil.
I am creating a small application rss for iphone
I wanted to make sure that once you are parsing the XML feeds were stored in a SQLite database so when you open the application should not wait for the reloading of feed (which by then will Bottene upgrade) but are read by database.
you have any advice for me to do this?
I can not save the parsed data in the database :(
tnx
This is not a question that can be answered easily since it's very broad; basically it's a whole application design process. To get you started, here are the logical steps needed:
Design your database layout according to your needs
Create that database in/for your app
Load the XML feed
Parse the XML data
Insert the parsed data into your database
Make your app read data from the database
Make your app display parsed data
Have your app periodically load and parse the XML feed
These are 8 steps all requiring a certain degree of understanding. If you're stuck on one step, learn how to achieve it; when you're still stuck, ask a specific question. I hope this helps!
Hoping to get some clear advice on this one.
I want to push updates to my app when it is live. I plan to do this by modifying the sqlite that ships with the app and then have the app download it. Easy.
I haven't worked out how actually get the app to see the new data though.. I can overwrite the sqlite in the documents directory, but the app has to be restarted for the new data to be picked up - no good. As a first step I don't mind if modifications to it are lost, but I am really looking for a way to keep any modifications to data, and add/remove entries based on the new sqlite. It will be the entire data-set rather than just the changes.
I am going down this path as the data is quite complex, but manageable through a desktop app based on same core-data model.
Is there a common way, or a way at all to achieve this?
Thanks.
There is no simple way to completely merge to two Core Data stores SQL or other wise.
Maintaining the integrity of the object graph requires that new data be inserted into the existing store via a context using the same model as that used to create the store. In other words, batch adding new data to the store is the same logical process as adding it one piece at a time from UI. You insert NSManagedObject instances, populate them, set their relationships and save them.
In theory, you could write great gobs of code to merge the old and new SQL databases into a new SQL store that Core Data could read. However, that is complex, unsupported and likely to break when Apple revs something in the future.
I would recommend having the app itself download the data piecemeal from the server and then insert the new data into the existing store. It's trivial to send data using something like JSON. Alternatively, you could download a new store, add it to the existing persistent store coordinator and then create clones the new objects in the old store. Then remove the downloaded store from the coordinator and delete the downloaded store file.
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 :)