I'm writing an iOS applications that saves Music albums(just an exercise I'm doing for the fun of it) .
For every Album there's a singer, song names, time, and a picture
The final result will be a lot of objects with a lot of details including a picture attached to every object. Should I even consider doing something like that with plist? (can pictures be stored in a plist?)
What's the best way to save and access that data?
I'm new to iOS and from the training videos I've seen Core Data is not recommend for the beginner user. Is that really the case?
If I'm going with plist, should I create one plist for every genre for example rap.plist , rock.plist etc' or just a big data.plist?
Thanks
I would go for core data. If you choose the right template when you create your new project in xcode then reduce the once-off overhead work significantly.
With that simple structure I would say that the templates provides nearly everything you need. Just define your model and layout and off you go.
There is just the images where I would spend a bit more time in thinking it over. I personally never put the image data into core data itself. I rather stored them as file and within my core data model I just stored the path and filename to access it. As file name I simply used a timestamp. You could use some auto-increment or other unique id technique but a time stamp would do as well. It will not be visible to the user anyway.
I think the best way you can do this, since you are new to IOS is by using sqlite. Save all the information you want in your local database and display it on the screen.
You can use plist if you have data structure that is small.
Note that property lists should be used for data that consists primarily
of strings and numbers. They are very inefficient when used with large blocks
of binary data. A property list is probably the easiest to maintain, but it will be loaded into memory all at once. This could eat up a lot of the device's memory.
With Sqlite you will easily be able delete , edit, insert your data into the database.
Core data also uses sqlite for data storage only it helps you to manage your data objects, their relationships and dependencies with minimal code.
And since your are new getting started with core data would not be such a good idea i think.. so i would suggest start off with normal sqlite. Save the data in one of your folders of your app and store their path in the database.
You dont have to write different plists.. You can use the same one if you are using.
EDIT : here is a link that will help you with learning sqlite
http://www.iosdevelopment.be/sqlite-tutorial/
you need some more code to set up the core data stack (the store coordinator, the store, the object model, and a context)
it is a tad more complicated but that shouldnt scare you off.
Reading a plist is indeed dead easy but while good for smaller data (like the info.plist) it doesnt scale and soon you need a fullblown DB
As you edited your original question an decided to go with plist now.
In that case I would go for one plist per ablum and one overall plist for the list of albums.
You could, of course, use more plists for categories etc.
However, if you are thinking of data structures like categories you are far better off with core data. Especially when it comes to searching.
No one seems to be mentioning SQLLite, I would go that way and for reasons that I explain here ( https://stackoverflow.com/a/12619813/1104563 ). Hope this helps!
coredata is a apple provided persistant tool, while plist is XML file. The reason why core data is not recommended for beginner, I think, is core data is more difficult than plist from programming perspective. For your application, obviously core data is more suitable. But alternatively, you may also use archive file, that's between core data and plist.
Related
I've been wrestling with this problem with quite some time now and still have yet to figure out the most efficient way of dealing with it. Here are the details:
I have an app that uses Core Data to store the content for the app to show. The app downloads the content in the form of a SQLite database and attempts to merge it with it's local version. This is necessary because the downloaded content is often needs to be combined with content that the user downloaded prior.
To make things more complicated, on my end I also need a way of combining these files so their clean to download (in other words no extraneous relations or isolated objects in the core data file). I have already built the editor for this, but again I run into the problem of merging these sqlite files.
I'd like to find a better way of combining these sqlite databases if that even exists. I've seen that you can add many different store files using a persistent store coordinator, but coordinating all of the correct stores into a single download package becomes more difficult and dangerous.
The question is: what is the best way to use multiple sql stores and either make them into one convenient .sqlite file or have them operate seamlessly?
First, don't think of this as an SQLite problem. It is a Core Data problem. If you use Core Data and SQLite in the same paragraph, you have already lost. CD does (sometimes) use SQLite as its backing store, but that knowledge doesn't help you solve this problem.
When I have had to solve the problem of combining static and user-generated data, I have usually used two different data models, with a unique ID on the static side under my control. Any combined references between static and live data I handle programmatically, which has worked fine because the user data is tiny compared to my static data.
You might also investigate fetched properties, which allow you to obtain values from a different persistent store.
I think merging your original static data with updated static data is the wrong way to go. That sort of operation will take a long time on the device.
Can you use three different persistent stores? The first would be bundled with your application, available immediately. The second would be updated data, downloaded from a server, and would be a complete replacement for the first. Finally you'd have a userdata store, connected to master data either with fetched properties or your roll-your-own unique ID.
It's also possible that Core Data is the wrong hammer for this particular nail. If you have a lot of SQLite expertise, and if you really are more comfortable working with SQLite than with Core Data, just skip Core Data. Do the entire thing in direct SQLite.
I need your advise on this, I'm currently developing a kinda family application.(Everything relates to the family)
I would like to add something similar to a family tree or the family members. (Using Table view) and each member/element on the list will have its own "view" containing a 50 words biography about him and his photo.
Since, I'm still new to iOS development and I still haven't worked with SQLite yet. Do you guys think SQLite is the best for this job? How about the photos. Is there a way to put a thumbnail photo for each member?
SQLite does this well, though Core Data is generally considered the preferred iOS technology. There are a few situations where I might advise using SQLite over Core Data, but you haven't outlined any app requirements that would make me lean that direction.
If you do your own SQLite, though, I'd suggest you use something like FMDB, so you spare yourself the hassles of writing SQLite code.
And, as I mentioned in the comment of another answer to this question, regarding images in Core Data or SQLite, you face a significant performance hit for that. If you're dealing with small images (e.g. thumbnails), it's fine, but if you're dealing with a lot of large images, you really might want to consider storing them in some directory structure under the Documents folder (and then store relative path names in your database). It not architecturally elegant to take the images out of the database and use the Documents folder, but for performance reasons you might want to do precisely that.
No. I would use CoreData for this. CoreData gives you the graphical modelling tools to build an object model and handles all the tedious housekeeping required to persist your object graph to disk.
The photos you would store as conventional files on disk and be modelled by a CoreData object that maintains a reference (URI or file path) to the photo.
I would use CoreData for this, it boils down to an SQLite database, but Apple have added their own wrapper round the SQLite database, making it really simple to use.
There are a number sample apps on the Developer Site as well as numerous Tuts available just by searching the phrase "CoreData example" in google, the link here is ro Raywenderlich which is a good place to start. I think once you go through this blog you'll be using CoreData more and more when you need to store things like this.
With regards to the thumbnail storage I would store those on the device and save the path to the file in the Database.
Yes you can use SQLite for this; in fact it's ideal for holding a family tree given its relational nature.
The photo data can be serialised into a byte stream (NSData *) and stored in a column as a blob.
A database has the huge pro, that you can keep everything stored at one place.
You could (not that I recommend) also use a folder-structure to specify the data like /images/, /words/, /people/ and use the same name for everyone throughout the folders (tim.jpg, tim.txt, tim.dat )
Or use a small database to store everything in different tables all with relation to your "family(_members)" table.
You can also store images in a database, mostly as a blob (or base64 encoded or or or... yuck)
I don't know how well iOS stuff handles those database types of SQLite but you should be better of using a database for that.
You have a number of options here.
If you are storing all of the info within the application itself (ie. the details aren't being fetched from the web somewhere), SQLite (as a CoreData backend) would probably be a good idea. Read up on using CoreData so that you don't end up reinventing the wheel, and so that your implementation provides a smooth scrolling experience that iPhone users expect.
The photos, however, need a different means of storage/retrieval.
A common technique is to implement a 2-level cache system. What this would entail is storing the pictures in individual files, but keeping some of them in-memory after they are retrieved for speed. You could then have a class that looks something like the following:
#interface ThumbnailManager : NSObject
{
id<ImageCache> _imageCache; // You make this.
}
- (UIImage *)imageForFamilyMemberWithName:(NSString *)name;
#end
That's similar to something I would do in your position.
Good luck!
this question has been asked many times, I have read many users telling that it is not advisable to store images in a DB, in particular within CoreData. By they all seems to omit the reason why they would do so. Even Apple documentation state this, and everybody points to that direction, and every discussion end like this "well you can, but storing the path is better".
Apart from opinions, I would like to have a concrete example of why it is not a good solution.
I explain better, I have a strong background in building Web Application. A concrete example I would give from my point of view could be: do not store images in a DB, but rather the path to them, because you can have them served them by the web server, which can apply all of its caching issues.
But in a desktop environment, especially in iOS application, what are the downside of having stored in Core Data using sqllite, providing that:
There's a separate entity holding the images, it is not an attribute
of main entity
Also seems to be a limit of 100kb for images. Why ? What does happen with a 110,120...200kb ecc ?
thanks
There's nothing special about what Core Data normally does here. It's just using an SQLite database. You can put large blobs of data into it, but it just doesn't scale all that well. You can read more about it here: Internal Versus External BLOBs in SQLite.
That said, Core Data has support for external blobs which in Core Data terminology is called stored in external record (iOS 5.0 and later). Again, there's nothing magic about it, it's just storing the large pieces of data in the file system separately from the SQLite db itself. The benefit is that Core Data updates all this for you.
When you're in Xcode, there'll be a checkbox called Allows External Storage that you can check for Binary Data properties.
The filesystem, and the API:s surrounding it is (just like a webserver) optimized to serve files, of any size, and to apply caching where appropriate.
CoreData is optimized for handling an object graph with tiny pieces of data, like integers and short strings.
Also, there are a number of other issues that tend to creep up on you, like periodically vacuuming the SQLite database CoreData uses, or it won't be able to shrink, just grow.
Leonardo,
With Lion/iOS 5, Core Data started handling file system storage of large BLOBs for you.
The choice is really determined by how many images you are going to have open. If you have many, then you should keep them in the DB. Why? Because you only have a modest number of file descriptors, one of which is used for each open image stored in the file system.
That said, there is still a reason to manage the files yourself. If your BLOBs are really big, say 2+ MB, you will want to map them into memory and not just read them in. (When the memory warnings come, this lets the OS automatically purge them from your resident memory. This is a very good thing.) Even so, you still have the limited number of file descriptors problem.
Andrew
I'm currently looking for the best way to save data in my iPhone application; data that will persist between opening and closing of the application. I've looked into archiving using a NSKeyedArchiver and I have been successful in making it work. However, I've noticed that if I try to save multiple objects, they keep getting overwritten every time I save. (Essentially, the user will be able to create a list of things he/she wants, save the list, create a few more lists, save them all, then be able to go back and select any of those lists to load at a future date.)
I've heard about SQLite, Core Data, or using .plists to store multiple arrays of data that will persist over time. Could someone point me in the best direction to save my data? Thanks!
Core Data is very powerful and easy to use once you get over the initial learning curve. here's a good tutorial to get you started - clicky
As an easy and powerful alternative to CoreData, look into ActiveRecord for Objective-C. https://github.com/aptiva/activerecord
I'd go with NSKeyedArchiver. Sounds like the problem is you're not organizing your graph properly.
You technically have a list of lists, but you're only saving the inner-nested list.
You should be added the list to a "super" list, and then archiving the super-list.
CoreData / SQL seems a bit much from what you described.
Also you can try this framework. It's very simple and easy to use.
It's based on ActiveRecord pattern and allow to use migrations, relationships, validations, and more.
It use sqlite3 only, without CoreData, but you don't need to use raw sql or create tables manually.
Just describe your iActiveRecord and enjoy.
You want to check out this tutorial by Ray Wenderlich on Getting started with CoreData. Its short and goes over the basics of CoreData.
Essentially you only want to look at plists if you have a small amount of data to store. A simple list of settings or preferences. Anything larger than that and it breaks down specifically around performance. There is a great video on iTunesU where the developers at LinkedIn describe their performance metrics between plists and CoreData.
Archiving works, but is going to be a lot of work to store and retrieve your data, as well as put the performance challenge on your back. So I wouldn't go there. I would use CoreData. Its extremely simple to get started with and if you understand the objects in this stack overflow question then you know everything you need to get going.
I'm studying using Core Data.
After I create the entity in Xcode, I want to insert some data, which is master data, what is the common way or should I say best-practice to achieve this?
I googled a little and found out where the real sqlite file that generated by xcode located. It looks like /Users/<Username>/Library/Application Support/iPhone Simulator/User/Application/<Application GUID>/Documents/<database name.sqlite>
Now I'm wondering if I edit the sqlite (just to insert data) file directly is a proper way?
If what you mean is a preset database setup for all new database instances, there's a couple of ways to do this.
Programmatically , you can insert Entities into the managedObjectContext with a bunch of code. This will get be slightly painful for anything other than a fairly trivial dataset but the advantage is that you can use all of NSPersistantDocument for virtually free.
Use your app to create the dataset and then save it in the apps bundle as a read-only copy which you can clone as needed when a user creates a new database. A bit messier if you are using the NSPersistantDocument architecture.
Do what you said in the first place . Use an sqlite3 client to inject data into the database to create a read-only copy like 2, but the risk is that there is more to the database structure that CoreData inserts which you dont know about so you might put a bit of work in to find that CoreData cannot read the db after you mess with it in sqlite3. I haven't tried but it might work.
IMHO 1 is the best practice as you get a bunch of free behavior from NSPersistantDocument
The only sane way to populate a data set into a Core Data sqlite store is programatically.
For iPhone apps, it's common for people to write small OS X apps to generate sqlite files, which can then be added to the app bundle.
The Core Data sqlite store is complex, and Apple officially considers it an opaque data store. Attempting to modify or create data in the store manually is likely to cause data corruption. Don't do it.