I am planning on developing a data intensive application for medical guidelines, these guidelines will need updating every so often so there will be a requirement to update them myself as the developer. One option is to put the data in a plist but I find this approach quite tedious. I was thinking of using chunks of HTML and referencing the files in my application, this way they would be a lot easier to edit.
I am curious to know how the interface below has been generated or what options I have available to generate a similar interface, is HTML the best option here or native UI elements with either Core Data + Core Text or SQLite + Core Text? Bearing in mind that I want an easy way to update the data and the data must be available to the app whilst offline?
Bearing in mind that I want an easy way to update the data and the
data must be available to the app
I would go with plists. I think they are quite good to hold your data and to be edit by any person (non IT related person, with HTML they would have to be careful with tags). HTML files although ok, don't think it's as good as plists, since on the last one, you immediately understand the hierarchy if you structured it correctly, while on HTML is just a bunch of files. As for the view, I do think a UITableView with some custom UITableViewCells would do the trick (I find the interface a bit ugly to be honest).
I would go with SQLLite database, which you can frequently update from your server.
I have also created a medical app and oftenly need to update the data, so I designed it on SQLLite.
I check at program startup if a new version of the DB is available and if it is I'm downloading it on the App replacing the old version.
Just keep in mind that you need to keep a record in your App about the DB version it is running and whenever you update it you need to update the db version key on your App as well.
I would also suggest to create an editable version of the SQLLite DB in case you want to allow the users to store data to it, by copying the database from the app bundle to the users documents dir.
Related
This question is different from questions here, because of the app being mostly in the background.
It is a requirement for our application that we keep the data store encrypted.
Our current implementation is using SQLite using SQLCipher. The plan is to move to Core Data.
I'm looking for a solution to keep the data encrypted, while still accessible in the background and is not restricting in terms of queries-NSPredicates and migration (schema change).
Below are all the options I've been looking into:
NSFileProtectionComplete - will not allow file access in the background
encrypted-core-data - This library does appear to be kept up-to-date. However, I've had second thoughts about using it in production after seeing the list of known issues. Has anyone used this recently?
NSIncrementalStore - This was the way that Apple engineers recommended that we follow. encrypted-core-data is using this method.
Transformable Attributes in core data - is this solution scalable for larger data sets?
Does anyone have a recommendation that meets all of the criteria and can be used in production apps?
I ran some proof-of-concept apps using each of the above options. I ran numbers and bench-maked it against our existing solution (SQLCipher).
Looks like using core data with incremental store (encrypted-core-data) came out to be the best.
After analyzing runtime performance times for read, write and search on DB with small and large sizes, encrypted-core-data turned out to be the most efficient and simpler to implement.
I've heard of iOS developers retrieving items from a RESTful web service and storing them as Core Data objects right away. I can see why that may be useful if you want to save or cache these items so the user can see them later (e.g. Facebook feed), but are there any other reasons to do so? I have items in my web service that are invalid within an hour, so caching is out of the question. If it's a good practice to do so, why?
For me, there are 2 reasons to stock datas in local:
Better UX: first, show old contents, then do an update in background for example, then update your application UI when new contents are availables.
Work offline whenever online mode is impossible.
Even if your items are invalid within an hour, if you do not cache items in local, your application has to call to webservice to retrieve these items, and it takes time.
Caching almost never hurts and CoreData is a very nice way to cache data which comes in as a pile of similar records.
I am one of those devs you mentioned who store almost anything using CoreData. Because I do, a lot of useful code and selfmade frameworks has summed up over time which make working with CoreData and RESTful apis a breeze. And if connecting an api to CoreData is just a matter of a few lines of code, there really isn't any reason not to.
While I cannot share my libraries, I'd strongly recommend taking a look at RestKit, which does pretty much the same - mapping a RESTful api to CoreData. And if you're not used to CoreData yet, fear not. It is a very powerful tool and getting used to it is definitely worth the while!
im learning about core data at the moment, I can see its benefits for apps like a phonebook etc, however is core data good if your app is to contain preloaded data. For example the players of an American football team. I was using MESASqlite and manually entering the ino and then copying and pasting it into xcode to have all the players preloaded in my app.
Basically, I hear core data is not a database (according to the Apple documentation) so im a little confused.
Using CoreData as a read-only pre-loaded data-store is very possible. In fact, CoreData's faulting mechanism may well work in your favour to keep runtime memory consumption low if the dataset is large. Using CoreData is almost certainly easier than fetching sub-sets of records as required from an SQLite database with SQL. CoreData also provides a solution for versioning, and model version updates.
To do this, you use an SQLite backing store and will need to write a tool to populate the initial model. Note that whilst it's just about feasible to use an SQLite database table editor to modify individual fields, you definitely can't create or delete rows using one.
In terms of a tool for populating the initial model, it makes a lot of sense to make this a MacOSX console or Cocoa application and run it as part of the application's build process. You include the SQLite database as a binary resource in your iOS application.
Building a graphical editing tool is actually far easier in MacOSX than iOS because of the extra KVO bindings on many controls provided by the cocoa framework - for instance, in NSTableView.
Alternatively, you can easily convert data from an existing format such as CSV or XML.
I almost always use Core Data, for pre-populated or empty databases. If you have to handle persisted data, you can either use .plist or database (mostly sqlite) files. The difference is that if you use .plist files, you load the data into NSDictionary objects. On the other hand, if you use Core Data, the persisted information is loaded into "managed" objects, wich are easier to work with. You have several advantages using Core Data (manage several contexts, data model editor, caching, etc.)
If you are not familiar with Core Data you should give it a try
Core Data may not truly be a database, but it holds a number of common features with SQLite databases.
Yes, Core Data is a good option. You would generally use an SQLite store to hold the data in your app. You can also write some code or a desktop app which will allow you to edit the preload database. You'd then copy the preload database to your Xcode project.
If you already have a solution using MESASqlite and everything works then there isn't a particular reason to change.
Basically, I hear core data is not a database (according to the Apple
documentation) so im a little confused.
Core Data is an object persistence framework: you put objects into a store, and you can get them back out later. So it's like a database, and it can use a database for the actual storage, but if you're thinking about it in terms of tables and rows instead of object graphs you should maybe consider just using SQLite yourself. Working with objects lets you build the smarts for manipulating your data into your classes, and the objects you pull out of a data store will have those behaviors.
is core data good if your app is to contain preloaded data.
Sure -- it's great for stuff like that. In fact, it's not uncommon to write a simple Mac program that takes data from somewhere else and adds it to a Core Data store using the same model you've created for your iOS app. You can build that data store into your iOS app along with the model, and it'll just work.
I read this blog where he writes, that everyone should use core data as soon as he want to store more than just trivial data.
So I added a xcdatamodeld to my project. I'm going to fill the database in the app with a formular. And I know, that I will change the data model a lot in the future development. But the entered data in the formular have to be saved. This means I need many migrations. Do you think that it is a good idea to use core data at this stage of development? I don't like the idea having tons of old xcdatamodel files while developing.
By the way, I'm using Magical Record if this helps anyone.
Definitely use core data. It's great.
I don't find that it is worth the effort doing migrations while you're developing the app. Half the time you're not saving the data anyway, or you want to start from a clean slate, or you have data setup code you want to test on the new model.
I'd advise altering your core data stack setup code to simply delete and recreate the persistent store if there is an error. Save the migrations for when you're updating a live version of the app.
I'm working on a project in which I might need to change my local database, according to information fetched from a server.I've read about Core Data, but from all I saw it uses a pre-defined database structures, and I haven't found a way to alter a table by code with it.I was wondering - should I use Core Data for this use? or should I stick with low-level objective-c wrap for SQLite?Tnx in advance!
I am going to go ahead and say "no, that is not a good idea" mainly because core data requires a lot of generated code to work properly...code which is generated in the XCode environment, not in the application environment.
For example, if you come up with schema for your data, XCode creates data entity objects and links them in specific ways which you shouldn't tamper with. If you were to attempt to alter the schema in real time, you would have to effectively regenerate all those entities and their linkages...which seems impossible. In my experience, any core data schema change requires a clean, delete and reinstall of the application before it will run again as well as resetting the host device's data entirely in some cases to get rid of the old data.
So no...seems unlikely to work.