I need to add video and audio recording functionality to an existing app that uses Core Data. I've been thinking that I should save them to the file system and reference them using Core Data but I wondered if I can put them into Core Data as Transformable attributes and ignore the file system altogether?
My gut feeling is that this is a Really Bad Idea™. I do like the ease and value-add of using Core Data however.. I've tried searching for 'iphone core data video' but that just returns heaps of core data tutorials.
Don't put binary data in Core Data. Store them on the file system and store a reference to the file system location in Core Data.
If you store them in Core Data you risk blowing the cache and causing terrible performance, not to mention probably blowing out memory as you try to fault in a large amount of data.
Coredata has a 'allow external storage' option when saving binary data with coredata which will automatically store files larger than 1mb to the disk.
However, this question is very similar to these questions:
https://softwareengineering.stackexchange.com/questions/150669/is-it-a-bad-practice-to-store-large-files-10-mb-in-a-database
and
Storing large (e.g. image/movie) files in Core Data on the iPhone
In contrast to the selected answer, Core Data should be able to maintain good performance as long as there isn't a huge amount of videos or photos.
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.
We have to write a directory application in Objective-C , we now use plist xml file to read data and write data , and store some data in it .
The plist xml file generated from mysql database , to avoid scaling problems , we have to decide weather to stay with xml plist files or move every thing to SQLLite ? as we estimated the maximum file size of xml is 10MB .
Any Suggestion ?
Another option would be to move to CoreData, which I'd prefer over SQLite.
I would go for a sqllite dbs, with the right wrappers it's very easy to get data and write data without parsing everything and sqllite is very fast...
Heres the issue with switching to SQLite, the file size of the database will be at least 3x the size of the plist. SQLite databases store a significant amount of information besides what the app generates from the user interaction.
As for using a plist over 10MB's, if the user is consistently writing to that file, there will be some noticeable delay unless you place the writing on a new thread.
You can always try CoreData as well. Even with this option, you will need to restructure and move your data. This will also require a ton of new code to your application.
You should also look into NSCoding and NSKeyedArchiver, which is almost exactly the same as an XML Plist, only it's a binary format (so much more compact) and it's faster, and it supports pointers (so if the same object is in multiple places when you write the file, it will still be the same object when you read it).
Generating an NSCoding file from a MySQL database could be a challenge (I've never tried), but you could always generate a plist, and then immediately convert it to the binary format once it's on the device.
My rule of thumb is if it fits in RAM you should use NSCoding, if it doesn't fit in RAM you should use SQLite or Core Data.
I would always avoid XML on an iOS device, disk space is at a high premium. Obviously sometimes you need XML though, especially if you're going to allow the user to import/export files in and out of your app and they expect something XML based.
i have a .sqlite file with all the data i want to be used with my iPhone app .
but i feel i should be using Core data for what i want done.
is it possible to some how move all the data that is held within my .sqlite file to core data's .sqlite file ?
i have created only 2 fields in my .sqlite file and 2 attributes in the core data file, but i don't think i can replace the coreData's sqlite file as core data added additional fields to it.
what is the best way to handle this .
thanks
Since you generated the database yourself, the best way to move the data into a Core Data store is to use Core Data itself to re-generate the data. You can do this either through a throw-away app or within your app itself.
The fact that Core Data on the iPhone uses SQLite as a backing store is an implementation detail. Trying to recreate the core data store yourself may to cause very obscure bugs, you'll be much safer by allowing Core Data to generate the database.
#ExtremeCoder's answer is an option, but even writing an app to read from SQLite and store into Core Data would be a better choice than what that blog suggests.
Check this out: http://ablogontech.wordpress.com/2009/07/13/using-a-pre-populated-sqlite-database-with-core-data-on-iphone-os-3-0/
I'm prototyping a simple sports sim game for iPhone which will use Core data.
One the biggest challenges I'm facing is how to get the data into Core data in the first place.
The second biggest challenge is whether I should use core data's persistent stores or use fixed files (JSON) for pre-fixed game data.
--
Concept
The general concept is that a player can start a new game or continue an existing one.
When they start new game they would use pre-fixed data. (IE. A database which is read-only.)
When they continue game they would use a different database (the game database).
I am not sure how to deliver such a feature.
--
Prototype
Currently, I am experimenting with this prototype:
PHP Web App -> 2. API -> 3. iPhone
A local PHP web app which acts as a CMS.
A basic API which lets me expose specific data in a JSON format.
Read the JSON into Core Data using TouchJSON/other tools.
I have no intention of making the API public/online (for various reasons), so the method I have described is a only meant to ever be a one-way process.
This will of course cause a problem because I need to make the data read-only.
--
In sports sim games you will often find them using fixed files (.txt, .csv, .dat, etc) and then they read this data into memory or a database.
Therefore, using this concept I could:
Save the JSON as fixed files and read them at run-time into memory/core data.
And then whenever the player starts a new game, the existing core data store will simply be wiped.
However, having said that I've heard that you can use persistent stores as a method to overcome this problem.
Therefore I was thinking of setting up 2 persistent stores;
1) A pre-fixed read-only persistent store
2) The actual game store (which gets overwritten if you start a new game).
But which is better?
Creating JSON fixed files for consumption, or using 2 persistent stores?
I apologize if my question/concept is overly complex; but would welcome better/simpler solutions where possible.
I think you can use Core Data for applications that is going to store data on it and the database is empty when it starts but if you needed you data store to be pre-populated with data it is better to load it from fixed data like sqlite or xml files.
Lets say I make an App that enables users to make short notes and write things down.
Is there Core Data on iPhone OS too?
Or how else would you save that data in iPhone?
No. Core Data, and Cocoa Bindings, as well as Objective-C Garbage Collection are all missing from the iPhone.
Update: As mentioned below, Core Data is available with iPhone OS 3.0.
If you can wait for iPhone OS 3.0, Apple's preview movie lists Core Data as one of the new features in 3.0.
SQLite is generally the preferred storage method if you have a lot of data. You can code the SQL classes by hand, or there are a number of nice third-party solutions.
For smaller amounts of information, you can easily store data in a file using NSCoding and NSArchiver.
I'll reiterate the above, but you could have a look at OmniDataObjects which provides Core Data-esque functionality and runs on the iPhone.
If you have to do some ordering or querying on the saved data, the best solution is SQLite.
Otherwise you can use serialized data. NSDictionary and NSArray provides -writeToFile methods to write serialized (in xml format) data to file.
Marco
depending upon the complexity, you can save your data on sqlite database, plist files, or even create your own xml files and save them on iphone file system (usually in the documents directory)
if you dont anticipate too many reads / writes / complex lookups then stick to plist files or xml files
however anything more complex, go ahead with sqlite.
if you do go ahead with sqlite then i would suggest you to use FMDB - a cocoa wrapper for sqlite, this saves you tons of repetitive code
Data saving on the iPhone is not much different - write the data to a file (like a plist). As far as I know, there's no iPhone Core Data.