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.
Related
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 6 months ago.
Improve this question
I am brand new to ios development and am looking for some advice on the best way to structure my user data and access it throughout my app.
Data is retrieved via HTTPS requests that query a database for the desired information. There are separate calls for the different tables containing information of interest. The returned data is formatted as nested dictionaries where the outermost key is the column and the subsequent dictionary is key-value pairs of the index and the table value. Example:
{"column1":{"0":"value1-1", "1":"value1-2", "2":"value1-3"},"column2":{"0":"value2-1", "1":"value2-2", "2":"value2-3"}...}
My primary requirement is that I will need to be able to filter this data by the innermost values (some will be dates, some will be numbers, etc). I would like to have the data in a format that will make this simple to do and will not cause delays as there is no limit on the number of possible rows.
I have looked into reconstructing a user-specific SQLite database with the information and querying that throughout the app as necessary. I have also explored dataframes as this app was originally developed in python - don't ask - and relied on pandas dataframes.
I know this decision will impact me heavily and am trying to do my best to make an informed decision. I appreciate any feedback and am happy to give more useful context that might be missing.
TIA
You can use SQLite database for persistent storage. This is ideal for your main requirement of filtering the data. You should also create a structure or a class modelled on your data to store and use during runtime. You can refer this for deciding between a class or structure.
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 6 years ago.
Improve this question
I'm developing an iOS app that is going to parse XML from an RSS feed of events and display the details of each event on a table view. Each event has a title, a description (optional), a date and a time. I am able to parse the XML data using NSXMLParser; however, I am not sure how I should store the data and make it so that it persists after the app is closed.
I have read that I can use NSCoder to persist the data but I am not sure if this is the best route forward.
Does anyone have any ideas or suggestions as to what I could do?
Any help is appreciated.
You have several options for persisting data.
NSUserDefaults are meant for user settings - small amounts of data. They seem unsuitable for what you have in mind.
NSCoding is quite a good way to store structured data without the overhead of a database, yet it is slow in comparison to core data.
Core Data is Apples ORM, which is quite powerfull but not as easy to wrap your head around.
I answered a similar question recently, which goes into more detail regarding NSCoding with a complete example and some links for further reading.
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'm writing an application which uses core data, and I use it to store a reasonable amount of user generated data.
However, the app also has a few settings ... such as the users name, age.
I'm wondering if it is better practice to store setting information in CoreData, or to simply store this information in UserDefaults?
answer acording to title: no
(added: especially not large amounts of binary data)
This is really more a question for Programmers Stack Exchange, but I give it a quick go over.
Core Data is powerful, but that power comes at a cost. It adds complexity and indirection.
I think it good to think of all your model objects separately. Figure out what makes the most sense for that object. This is not to say let chaos rule, patterns make code easier to understand. I think it's not good to shoehorn something into an existing pattern, because you want everything in your app to fit the pattern.
All that said. Unless your app is storing a list of users, I think it's better to use the simpler approach of NSUserDefaults.
Core Data is a big thing, not really simple. I would rather you to think about your data model first. If its "big" enough and you think about to expand it maybe in the future i would recommend you to use core data.
Now to my personal opinion:
I'm not really a fan of Core Data. I use mostly a SQlite-Database. If you need alot more and you are a starter checkout parse.com. Its a complete backend-service in verious languages. Check it out..
If you are saving credentials or some other protected data then this is the best practice:
iOS: How to store username/password within an app?
For temp data and most of other flat data use UserDefaults...
Use CoreData as more structural data storage, when you have lots of records or linked records, for more complex data structures in general...
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