I'm working on an application that has a read-only database shipped with it.
The user will run the application and be able to select a series of "favourites" from the database which will appear in there "favourites" tab bar section. I.e. storing the primary keys.
With each update to the application the read only data will potentially contain more entries or have things like spelling mistakes fixed etc.
I'm using Core Data but I'm unsure whether to use it for storing the users "favourites" as-well. As - to my way of thinking - this might cause headaches for migration. Is this the case?
Should I consider storing the "favourites" in a plist perhaps and perform some sort of query to retrieve the records? Any recommendations?
Also what internal pieces of an iphone application are kept (or can be kept) during an update?
Phew I think that's it.
Thanks for any answers you might have.
Cheers,
Matt
I'm using Core Data but I'm unsure
whether to use it for storing the
users "favourites" as-well. As - to my
way of thinking - this might cause
headaches for migration. Is this the
case?
If you're going to port the app to another platform, then Core Data is not the way to go. And since we are talking about a static database, I'd keep it simple - read it once, do what you need with it and close it and forget about it. Not like a real database where you're doing multiple GETs and some amount of additions, modifications and deletions.
Should I consider storing the
"favourites" in a plist perhaps and
perform some sort of query to retrieve
the records? Any recommendations?
Your database could be a plist too. After the user selects their favourites, you can easily store them in yet another plist. This one goes in the Documents or Prefs folder.
When you release a new app, you should probably compare the favourites with the new entries to correct any typos or other changes, if applicable.
Also what internal pieces of an iphone
application are kept (or can be kept)
during an update?
I believe that your app is replaced but your Documents and Preferences folders are kept intact.
Related
I'm not sure if this is possible but hope that it is.
My app is more complicated that this example, so I'm using this to explain.
The iOS app offers e-books and stories which are organized by library, so a user can subscribe to a library CKShare and have access to all the books in that library, potentially tens of thousands of books. Obviously one wouldn't want to duplicate the entire library from CloudKit to the local CoreData store, so I'm wondering if there is a way of filtering what gets synched to the local store via a predicate. The predicate might allow the user to only duplicate a genre (fiction) and/or author (Tom Clancy) such that the local store only has a few dozen books instead of tens of thousands. The nature of the app is that it is important to be able to access the books/stories desired off-line, so caching the desired books is necessary.
I realize that if I was doing the sync manually vs taking the default core data -> cloudkit sync this is doable, but I'd like to use the default sync mechanism and apply a filter. Can this be done and if so, how?
I already have an app in the app store. I want to do an upgrade. My local data store has changed, with an extra table, and with a few fields added in the existing table. I want to retain the data in the old tables. How would I go about doing that? Could someone point me to tutorials that handle that kind of change?
Assuming you're using SQLite: Use a new database with a different name for your update. On startup, check for the table with the old name, copy the data you want, and delete it when you're done.
CoreData has it's own update data which may or may not work for you. You should look into how to change the data model.
Check out Apple's docs on migrating a core data instance. They make it super easy for 90% of the cases. The basic idea, is you break you xdatamodel into versions, so it has a path for migration
Here's a tutorial that might help you Core Data Migration
So I am working on an iOS search where I have to implement a keyword search. I have used a custom view controller with a Search Display Controller object embedded into it. What I want to do is be able to store the search terms somewhere when the search button is clicked. I have thought of two ways:
store them locally in the device and query them up whenever a search is performed
store them in the web app this iOS app is connected to and perform a GET request to the web app whenever a search is performed
The second one I know how to do but I have no idea how to do the first one.
SO how do I store the search terms locally? Also, what would be a better option? The first, the second, or another?
EDIT: A remote API holds the data I am querying. I want to mimic the google search app functionality, in which it stores maybe 10-20 keywords that are searched by the user.
Thanks in advance!
It's tough to recommend with more understanding of the data and usage. For example, number of keywords? keyword list static or grows? keywords shared? what are you searching - local or remote?
EDIT: You clarified 10 - 20 strings. In that case, consider something as simple as -[NSArray writeToFile:atomically:] and just persist in a file. If you read and write in NSArray, you can work on them very quickly in memory.
Original:
If you store locally and it's a growing dynamic set of keywords, I would recommend CoreData or Sqlite directly. Sqlite is a very fast efficient local DB. If you do sqlite, checkout fmdb on github. It's an objective-c wrapper.
Concerning the pros and cons:
Local storage will be faster - you won't have network latency. Especially if you want to do type ahead queries on key stroke. Keeping in memory is even faster.
Consider how much data you're storing. How many key words are there? Is it feasible to store on the device in a DB or a file?
Do you want the keywords to be shared from multiple users? In that case either storing on the server or a combination of storing on the server and syncing to the device is needed.
Do the keywords grow over time based on usage? In that case a local database is better.
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 planning to create an iphone app which uses CoreData. There might be enhancements added later as new versions of the app.
My question is;
When using CoreData, what are the factors to keep in mind to ensure if the user upgrades the version, his previous data remains intact ? Like I heard we should keep the.sqlite file name same. What are other factors to keep in mind while releasing Core Data apps?
Thank you.
Data migration concepts are important to understand if you're going to maintain it over time, since you're likely to want to change at least some things eventually.
The ideal is Lightweight Migration, where minor conversion from your old data model to your new one is automatic. As noted in the document, it can take care of itself if your changes are:
Simple addition of a new attribute
A non-optional attribute becoming optional
An optional attribute becoming non-optional, and defining a default value
Renaming an entity or an attribute is also easy and nearly automatic.
Everything beyond that -- new or removed entities, new or removed or changed relationships -- is hairier. It's not incredibly difficult, but it's definitely more work, with more room for failure.
As such, a little speculation about likely potential changes may make it easier and more efficient to provide a little wiggle room in advance. Obviously if you do too much, especially with theoretical-but-currently-unused relationships, you're likely slowing down the current system and potentially for no reason.
Worth consideration.
One thing we have done is to manage two separate core data databases.
First, a "read-only" core data database that gets supplied with app updates (assuming you want to be sending data with the app, if not then don't bother with this part).
Second, a local core data database (data store) that's stored on the phone that is initially populated with the data from the first, and then added to by the user or with updates from a server that you control. This second core data store can stay persistent between updates.
For later modification and updates you have two options. You can add additional features in a new core data store as long as you don't need to get at the new data at the same time as the old data. The other option is to use apple's core data migration stuff which you can read more about here.
Here are also some additional resources for gearing up with core data, there are plenty of more specific core data examples on SO.
Finally, if you plan on significantly adding/modifying your core data store I'd suggest looking into SQLite. That's easier to change with updates (in my experience) than migrating an existing core data store to a new schema, especially if the schema changes often.