Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My Core Data object has become bloated with properties (10 in total, 2 BOOL, 5 NSString, 3 NSDate)
and now I want to add yet another few properties. This object is the central data object for my entire app, so it's required a lot of properties. I read somewhere that some people separate out a single object into 2 or more Core Data Entities. What's best practice?
Unless you can prove me otherwise, 10 properties is not a problem at all.
You can bloat your single Core Data Entity with as many properties and relations. Core Data works on retrieving data via lazy loading and is automatically managed by itself. Hence, don't worry you will not run into memory scarcity issue. :)
In "edit scheme..." select left run app and in the right "Arguments passed on launch" add "-com.apple.CoreData.SQLDebug 1" it will show you sqlite query time in your log.
you just want optimize sqlite query not about core data, just use explain to analyze it
just focus on query time and optimize it
Core data not only store data and query ,also provide PersistentStore.
I think core data is framework , sqlite like mysql , PersistentStore like small memcache , you
get once from sqlite, and crud in the PersistentStore
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have a few core data entities in my app.
One entity for example, is a more complicated one and represents a task. Something like 12 fields consisted of the premetive types of String and Int and some relationship to "premetive" core data entities, like an entity that represents an hour in the day and consists of two fields of int.
Are this type of objects can actually effect the device free space in any significant way in the long term of months and years ? Should I routinly delete them ?
All data that your app saves affects the free space on the device. Whether it's significant depends on how much data you're saving. If it's 1 or 2 old instances and the strings are short, nobody will ever notice. If it's 1 or 2 billion old instances or if some strings can be really long, you need to take some action.
In general you should delete any data you won't use any more. Not "routinely", but literally as soon as you're sure you don't need it any more. Not deleting it is sloppy programming that shows lack of care for your users. Nobody expects you to be perfect, of course, but if you don't need the data, you should delete it. And of course, it's OK to cache some data that you don't need right now but that you might download from a web API in the near future.
If you do need the data though, don't delete it. If there's a lot of it, look in to whether some can be moved off of the device to a web service of some kind, but don't delete it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I make an application which receives data via bluetooth. I would like to store this data received at regular intervals to make a history and store it in the application.
I would like to know what to use (Core Data, UserDefaults, ...) ?
Thanks
It depends on amount of data but mostly what you want to do with that data.
Core data will take most of time to implement but you can do a whole lot of things with that data. You can search and filter items for instance by date and even put them into sections. NSFetchedResultsController can be very helpful here.
User defaults are probably not very appropriate as they are designed to hold small (or at least finite) amount of data variables like some settings, flags...
The other that comes to mind is simply saving them into file. Probably the easiest would be using JSON. JSONSerialization should be able to encode or decode your data from concrete objects to Data and back. Also there are some nice tools now that can greatly speed up the process. Check into Codable. Data in the end can be saved directly into files which may then be created in documents directory of your application.
You should evaluate how will these data be accessed. If you are targeting for instance showing charts on monthly, daily and hourly basics, have ability to remove entries and such then I would go with Core Data. If you just need to open some old logs and look into them then saving to disk is probably a more fitting solution.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am writing a trivia app in which there will be hundreds of sets of questions.
The app will come pre loaded with some quizzes however they would then need to download further quizzes which once downloaded will be stored within the app so that users can play them offline.
In this specific instance would I be better using core data or SQLite.
Thanks in advance.
The thing you have to realise here is that CoreData is not a DataBase.
It is an object persistence layer in your app. It happens to be backed by a SQLite DB by default but that's largely irrelevant.
I have written apps with a CoreData store that contains in the region of 100,000 entities and millions of relationships between them.
The argument that CoreData cannot handle complex data is not correct.
The trick is to design your Object Model exactly like you would define you object model in code.
You don't need foreign keys or join tables (these are all handled for you by Core Data).
If you have (for instance) a many-to-many relationship between Class and Student then just create a relationship between them and define it as a Many relationship on each end. Core Data will handle the data for you by creating the join tables and stuff like that. You don't need to worry about that.
For preloading the data you can also do this. It takes a bit of work but you can bundle a preloaded DB generated by CoreData and unwrap it at initial launch.
Which to use comes largely down to opinion (and so isn't a very good question for StackOverflow). There are some excellent tutorials on Core Data on the Ray Wenderlich site.
Worth reading through if you've never used CoreData before.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The question is very simple.
Should I use Core Data only to persist data, to store it locally on a device or should I use it ALWAYS just to manage my application's model even if I do not persist significant amount of data?
What do you think?
Core Data provides an infrastructure for change management and for saving objects to and retrieving them from storage. It is not, though, in and of itself a database. You can use an in-memory store in your application.
Use it Always ? : NO. Use it when you think that your require the features that the Core Data framework offers to you, like any other framework.
Short answer is no. As others said if you do not need persistent store just create runtime objects and manage them.
Even when you need persistent database, Core Data is not always the best solution. For example if you have multi-platform app, or if you plan to port your application in future I'll definitely consider use base sqlite3 with requests. This way I can use same database structure in my Android, iOS and BB application, and even my sql statements will be written only once(with their interface) and then I'll just need some platform specific implementation above them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to create a searchable database in Xcode - for example, of different trees. The database would consist of the tree name, two images, price, and a short description. What is the best and most efficient way of creating such a database?
I am aware of: Core Data, SQLite3, and Parse. I am leaning towards SQLite3 but have not found a good place to learn how to implement this. Any suggestions?
Seeing as you are new to Objective-C and I doubt this will evolve into something need direct SQL I would suggest using CoreData. Although it is not technically a data base it is an object graph, it is built for exactly what you are wanting to do. Apple was even nice enough to build wrappers for everything you want to do.
CoreData to store your tree name, two images, price, and a short description.
NSFetchedResultsController for grabbing it.
UISearchBarController for letting the user search.
You would want to use Parse if you wanted to save your data to a server. If your doing everything locally I wouldn't worry about Parse. CoreData is what you want.