My app starts with five cells (Ca, Alk, Mg, PO3, NO3). When the user taps on the cell they want to dose lets say Ca, it segues to a screen that have all of the Ca products. From there they get to pick which Ca product they need to use, which segues to the calculator screen where they can calculate the dosage they need.
I need to find a way for the user to save the product they chose, so lets say they selected Ca, I want them to save the product in the Ca list, if they chose Alk, I want them to save the product in the Alk list.
I am lost here whether UserDefaults is okay for this or if I need CoreData.
I personally would use CoreData over UserDefaults for this. CoreData is designed to solve persistence in a more general way that will scale with the needs of what you are building. It's possible to do what you describe with either one - but the modeling of your data, with generated files will provide your code with safety, migrations, and performance if you use core data.
See Here for determining which data storage types to use based on the problem you are trying to solve.
For help in how to actually use CoreData - this article gives some code examples for basic CRUD operations.
Basic CoreData Tutorial
Related
We are developing a social app with Firebase (swift / iOS).
We face the problem that we have two data trees and have to calculate the delta without generating a high data traffic.
Example:
We have a structure cars and a structure user.
The structure cars contain 100 different vehicle models.
The user structure contains all vehicle models that have already been driven by the user.
We now want to implement a high-performance solution in order to determine all the vehicles that have not yet been driven by a user without downloading the whole tree structure.
The number of users and the number of vehicles are growing steadily.
Does anyone have a solution approach or idea in which direction we need to think?
love, alex
I think they key to effectively using firebase is data duplication. So if you want to display a list of cars the user has and hasn't driven, create a separate table containing only the information displayed in that list, like the path to an image, the make & model, using unique IDs as the keys to entries in that table. You wouldn't need to know things like top speed and price until they tap into details, right? (I'm making some assumptions here though.)
Then, simply get the list of unique IDs for the cars the user already has driven, and manipulate your offline model accordingly.
Right now I'm using an external server to manage data duplication, that propagates a write operation to other places in the database when necessary. I'm on my phone right now but I think Ray Wenderlich has an article about this.
I am working on my first iOS app which will be deployed for both iPhones and iPads. The app contains data that needs to be bundled with the app, which will be used when the device will be offline.
The offline version has atleast 35-40 records with each record containing images(which would be bundled in the app, only names will be saved), and a varchar field which would be atleast 1000 words and a boolean field.
I have found three possible solution for the same
Save all the fields using database (SQlite or Coredata), however
I am concerned about the table which will have 1000 words. But since
the varchar field might vary, I need to allocate max 2000 (or more,depending on the actual length of keywords)
limit (which will lead unnecessary allocation of memory resources)
Another Approach I would like to have is save the information in form of json locally and use it as and when required and save the boolean fields(only true locally in NSUserDefaults)
Use the JSON Approach as discussed above and create a database for managing the boolean fields.
I would like to seek the opinion of StackOverflow community on what would be ideal/optimized approach for this scenario. Also, I am open for any other approach as well.
Edit 1
Proposed provisional databased structure
Listing Table
id -> int (autoincrement)
name -> varchar(25)
imagename -> varchar(10)
desription -> varchar(2000)
favorite -> boolean
It sounds as though the text field (with the 1000-2000 words) is static text that is bundled with the app and can not be changed by the user of the app. If that's the case, then you can store that data in the app bundle with plist files, or JSON files and load it on demand (assuming you don't need to search though it).
Then, if each of those records has only a single boolean value that is changeable by the user, those could be stored in NSUserDefaults very easily (since you've stated you're only dealing with 35-40 records). You'd use the id to link the boolean to the data file.
You could use Core Data or Realm to store the data, but it may be overkill if you don't need a search feature and the user can't change the text. But if you do go with a database option, be aware that you can not store static data (the text), in a location that is backed up by iCloud, or Apple will reject your app. Regardless of whether you use iCloud in the app or not. So if you were to create a Core Data persistent store and save it to the users Documents folder, then load in all the static data, you will be rejected. You would want to save that data store in the users Cache folder so that iCloud doesn't back it up. The issue you'll hit after that though is that you want the user's choices that are your boolean values backed up. This means they need to be stored in a different place. Core Data does have a feature that lets you create Configurations where it will separate the user changeable data from the non-changeable data, but again, that's overkill for your case.
I'd recommend starting with Realm over 'Core Data` for such a small dataset. It's much easier to get up and running.
If you need to look into the fields, CoreData is th best approach, because you can easily access your data using NSPredicates, ( Like an SQL where statement` ).
But if you need to load everything at each launch, you can just store everything to a file ( plist, son ... ), because it is really more easy to managed, and to update ( If you update CoreData Model, the change may be complicated on the App update ).
So my short answer is :
If you need to teach into your data => Core Data
Else => File on local Storage
Do not use UserDefault to achieve that, this is not designed for it.
It is depends on you data base's complexity and operation.
See, first thing is whatever data base system you used, there is no performance difference.
Every database system has different complexity and operation limitations.
For example, It is very simpler to use NSUserDefaults to store and retrieve data.
But if you required to do relational operation between bulk data then it is better to use sqlite or core data. Relational database operations are easily performed by sqlite or coredata compare to others.
There is another option is property - list also available if you data is only type of key value pair.
Core data is totally based on sqlite. In root core data itself using sqlite.
Difference between core data and sqlite is : core data provides more flexibility to use it but it is comparatively hard or complex to learn. Where sqlite not provide flexibility compare to core data but it is less complex to learn and use. Flexibility means for example : you can see visual representation of core data. Can visually add entity or attributes etc.
So, select data base as your need and complexity of use or base on operations that you will required to perform. Your database is not much big and not complex and not required any relational operations or multiple tables then you can use user defaults or property list also.
Hope this will help :)
Pitching in with an option.
To make it easy for yourself later on, I would suggest using CoreData. This lets you easily manage the products for reading and writing. This also gives you a good persistent storage.
To the description issue; you could store the description for each product in its own file with a unique name that references the product you store in CoreData. In your CoreData entity you define a descriptionFile, which will hold the file path.
This approach makes it easier for CoreData when you fetch the objects, maybe you want a browse view where you don't need to display the description, therefore you don't need to load the description text into memory. When a product is selected, load the description file for that product and display the text within.
Happy Coding :)
Let's say I had a game where in the beginning the user gets to choose a couple of things like name, gender, etc, and that will affect a lot of aspects in the game such as the sprite used to render the user, and the text that is displayed.
So every time I leave one area of the game and enter a new one I should figure out according to the user data - what sprite to use and what text to prep. Should I make a separate class with a dictionary just for the user's data and then just call it whenever I enter a new area?
Thanks yall.
There is a few ways to do this.
I prefer to use a singleton GameData class with NSCoding to house all the properties (arrays, dictionaries etc) that need to be saved permanently.
I like it this way because it makes code more readable and also has the advantage that you can access the properties from anywhere in your project. This way it's also easy to include icloud key value storage.
You can read these 2 questions I answered for a simple example of how this can look
SpriteKit: Why does it wait one round for the score to update? (Swift)
Is there a better way to save a custom class to NSUserDefaults than encoding and decoding everything with NSCoder?
There is a also few good tutorials around such as this
https://www.hackingwithswift.com/read/12/3/fixing-project-10-nscoding
To securely save data you can/should use keychain. To read more about it check out this question.
How secure is NSUserDefaults on iOS 8,9?
As 99% of iOS apps, mine has a main screen with a long list of items, and when a user taps one, he sees item details. Pretty much straightforward. Let's say, to render the first screen I need titles and images. And for the second one - a large html. All the data is stored persistently in CoreData.
I want the list (UICollectionView) to be as fast as possible. So I can't load html-s until a user is on the details screen.
How can it be implemented? Should I create two NSManagedObject classes: Item and ItemDetails? Does CoreData load everything lazily?
Splitting it into Item and ItemDetails is a good approach.
I'd check first, though, if it's really a performance problem. You want to be sure to understand how setting a batch size affects fetch performance. The Accessing Data and Performance chapters in our Core Data book goes into all the details.
I have a question concerning Parse.com and Swift. To make a long story short, I'm creating an app that allows installers of racking around cash registers to enter the details of checkout lanes into their phones, save it to Parse.com, and then have it be retrievable by the guys making the racks in the shop.
For the app, I was thinking of a basic flow like this: A) ask how many checkout lanes there are (x), B) populate a table view with x rows, C) each row represents a register that, when tapped, takes them to a detail view where they can enter details like lane and belt measurements, power sources, etc.
My question is how would I save the registers data to Parse, structurally speaking? Would I be creating a column that stores an array of complex register objects in the row for that specific store? Or would I create a store class, and then a registers class, and dump all those registers into the registers class and relate them, one to one, to the appropriate corresponding store?
I'm not having any issues with the actual saving of the data or the general programming, parse seems pretty straightforward, just conceptualizing the structure is giving me issues. Any help or links would be greatly appreciated.
Here's how I think it should work:
Store class: holds information about all of the stores. Things like the number of registers, number of checkout lanes, location, etc. Stores get a randomly assigned identifier when they are set up.
Register class: holds information about all the possible registers. As you say, users can add them and define values. When created, assign parent store identifier. This should be relatively easy--just get the ID of the nearest store or ask the user what store they are in.
Then you can PFQuery all of the registers by knowing the store identifier, and create an array of all the registers.