This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Use CoreData or SQLite on iPhone?
I would like to build an App which enables you too find stores (for example stores with your favourite shoe brand) even when you're not connected with WiFi or 3G.
For now the App should have a couple of possibilities:
User selects his favourite brand and gets a list of nearby stores. After that the user must be able to select a store to get the address, contact information and maybe a map;
User selects a certain city, gets a list of the available brands, selects one and gets a list of stores in that city selling the selected brand.
Since I'm new to making this kind of Apps, I have started doing my homework. I know I have to use a database to store all the data and found out there are a lot of ways to do so. One of them, creating a MySQL Database, wouldn't be an option since it can't be used offline. If I'm right two other methods are SQLite or CoreData.
Problem is, I'm getting kinda lost in all the available information which makes it hard for me to start. Are both methods possible for this App and which one is the easiest for this job?
I was hoping someone could point me in the right direction and maybe give me an usefull link or tutorial to continue with my App.
Thanks in advance! :)
Only use SQLite if you already know it, or you know that your use case is one of the rare few that has proven difficult for Core Data.
Thus, I would think your decision is simple. Use Core Data. It's extremely simple, unless you start updating data from multiple threads/contexts at the same time, then it gets pretty hairy relatively quickly.
There are tons of tutorials available online for Core Data, and ou always have Apple's documentation and sample code on their developer web site.
If you've never used MySQL or SQLite, just use CoreData. But if you have used MySQL or SQLite, i would recommend using SQLite as it will be easy for you to understand and thus you will be able to develop your app faster.
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 2 years ago.
Improve this question
I am newish to Swift/SwiftUI and have been reading a ton of resources. Using what I am learning along with another example app similar to what I am trying to create, I am making an app that downloads a JSON file from an external API service. That JSON data contains the main part of my code (items from a video game), and my app displays that data in various views. My question though is this: I want a user to be able to track a few things about each object, such as whether they have collected it. I have spent 2-3 weeks researching and trying various options of how to do this, but I am wondering what the most efficient/most popular way of doing something like this is in real-world apps?
Here are some things I have been considering:
Download the API JSON initially and then create both it and my collection data as one object. From there, I would persist that data either be encoding back to a JSON file to be stored in the app's documents directory or in Core Data (or even Realm). The views would actually pull from my own personal data. My first concern with this method is that the API JSON may have changes at some point and I would like the app to always have the most up-to-date version of that info (and I don't know how to compare for updated info yet). My second concern is why keep all of that extra info locally in my app when someone else is already hosting it (or should I do that anyway so the app can be used offline)? If that is the case, is there a tutorial or something around that shows how to manage downloaded JSON data without completely overwriting current data?
Download the API JSON as I currently am (every time a view needs it), and store the collection info as its own data. This is the method I think makes more sense, but my question is how do I combine it with the API JSON? Is it easiest to use JSON or Core Data to combine these files? Do I use the Combine framework? Are there other frameworks/methods that would be better suited for that?
To sum up:
My app downloads JSON files from an API containing items from a game that can be collected. I want the user to be able to track whether they have collected said items from that game. I don't know the best way to do this or what framework/classes I should be researching to do this. Any help would be greatly appreciated.
Warning: Most tutorials for CoreData and SwiftUI, FYI, both ignore MVVM (e.g., using #FetchRequest so your view directly reads your model) and the benefits of abstracting your persistence choice with a DataManager object and protocol. Doing the latter lets you choose CoreData now and switch to Google Firebase later (i.e., launching a collaborative Android version), without changing any View code or really any ViewModel code. You can follow the same principles with JSON decoding as just a different DataManger for initializing data for your ViewModel to apportion to views. Ok, done with soap box.
If your dataset is really big and you plan to query it sideways, CoreData may be nice. Or just a skill to learn. It's not that bad.
But if the use case is something simple like
Character 1
-- isStarredAsAwesome
-- copiesCollected
-- maxLevelofCopyCollected
-- dateCollected
Then just save JSON to the Bundle.
The benefit of CoreData is you could query relationships, such as get a brag sheet of which of my video game characters are in my friends library, but at a higher level and played for fewer hours but collected far in the past. In a large dataset, CoreData will be faster than looping over arrays yourself. But for a smaller dataset like yours may be, again, it may not matter really at all.
I'm building a note-taking app with lots of cross-ways uses of entered text. In this case, CoreData was easier than managing all those relationships in JSON, which makes the extra function calls to manage CoreData CRUD calls worth it.
Also, you may want to ship the JSON with your app and then call an updater on launch. This way, in case the API changes, your app isn't immediately broken until you get around to updating it.
This question already has an answer here:
How to make offline database for my app?
(1 answer)
Closed 6 years ago.
I'm currently working on an application in Xcode 8/Swift 3 which runs through APIs. Essentially, I'm parsing information using SwiftyJSON from my MySQL database which keeps the content current and easily updated.
To keep it so the content is also available offline, I'd like to introduce a facility where the data is downloaded and stored on the phone so it is available in "offline mode".
I know it's a completely open question but can anyone point me in the correct direction of how I could make this JSON information available offline? I've tried searching the net with no success.
I know it's not Swift, but the absolute master of this has recently open sauced his master piece: Dash for iOS.
Reviewing what he's done to get rapid scrolling and searches might give some deep insight into how to best do this as done by someone with (arguably) more experience in this area than anyone other than Apple:
https://github.com/Kapeli/Dash-iOS
I will prefer here 2 option either I will go with 1.SQLite DB or 2. NSURLCache
For SQLite DB you can use FMDB wrapper-https://github.com/ccgus/fmdb
For NSURLCache check this link Best way to Cache JSON from API in SWIFT?
If you just want to save json then go with NSURLCache for offline mode.
Achieving offline for iOS is having two best paths they are CoreData and SQLITE. As per the definition of CoreData suggests it is a Model layer of the project. It comes with less efforts on developer side. Bit contrast SQLITE having the same way but little efforts on it.
In my project we are using the CoreData for offline maintenance. Really we have few concerns on the Relational data fetching, Although there is a Predicates representing CoreData for the same still it is limited to some part. These type of situations SQLITE is really a life saver. We can easily fetch the records with simple JOIN commands.
Conclusion:
If you have more complex data relations it's really better to go with the SQLITE, Apart from CoreData is best choice.
I build an iOS app which works with base. User can work with it everywhere, that is cool. When application starts for the first time, obviously, base will be empty. For now, user's base stores data locally with Core Data. But there is a case, when user may have his own base with a lot of data and he do not want to start work from scratch. For this reason I want to create simple Cocoa App for macOS, which will allow user to import some data from, for example - CSV file.
Both Core Data models (iOS app and macOS app) will be the same. I just want to make sync between two platforms.
I think it's possible with cloudKit, but which way is the best? Core Data Sync or smth like supporting MySQL database on server, etc...
Thanks in advance!
Asking which method is "best" is a matter of opinion, but in mine, Apple has made working with iCloud fairly simple. If all you want to do is sync between platforms, I would use cloudKit. There seems to be no reason to spin up your own MYSQL database instance and introduce another level of complexity, when the functionality you're looking for is free and easily accessible.
See this WWDC16 video for some cloudKit tips: https://developer.apple.com/videos/play/wwdc2016/226/
I'm planing to create an app for iOS which will be kind of informative application for public transport in my city. People will enter street name from where they want to get public transport and will get list of buses and minivans, which are traveling by that street.
My problem is that I'm just started developing for iOS and want to find easy method to create a database/table with simple information as streets name and bus numbers that will connected with those streets.
So basically I need to create database/table and an search-box which will be connected to that database.
From where I need to start? Thanks.
p.s. - sorry for my bad english ;)
SQLite is quite popular and supplied by Apple. This lets you manage your table, and allows most standard SQL queries. You can also link to Core Data if you want to treat your data as objects.
See the Apple overview
There are many tutorials to build a simple app with a table view using SQLite, e.g. here or here
I found the Stanford University videos a good way to learn this stuff, e.g. here on YouTube or there are later versions available in iTunes U.
Yep, for an on-phone database SQLite is the way to go for a full-featured database, or Core Data if you want some "hand holding". And, of course, if you don't need persistence you can make a pretty good database simply using NSMutableDictionary and maybe a few custom classes.
Learn to use CoreData. Its not there to "hand hold" you, its there to provide a complex and optimized ORM interface for the underlying SQLite database-- there are a number of optimizations implemented to improve efficiency. You could pick it up in a night following tutorials and online instructions.
First time asking a question on here, so please go easy if I don't provide enough info. Basically part of my iOS app allows users to take a picture which will be stored in a Core Data store. The attribute is a Transformable type, and I have created an NSManagedObject subclass which I simply use to set its image attribute to the new image provided by the user.
I know storing large files in Core Data is a bad idea, which is why I was excited when I saw the "Store in External Record File" option under the image attribute in the Core Data entity. However, my app performance says otherwise, taking several seconds on an iPhone 5 to load only a few images (which I know doesn't sound like much time, but considering how powerful the iPhone 5 is, older devices would likely take much longer with the same data).
I've looked around, and some people say that the Store in External Record File option is only applicable to the OS X environment, even though it is available in an iOS app. However, I also saw this under Apple's "What's New in iOS 5" doc (it's the next to last item under Core Data, near the end):
Managed objects support two significant new features: ordered relationships, and external storage for attribute values. If you specify that the value of a managed object attribute may be stored as an external record, Core Data heuristically decides on a per-value basis whether it should save the data directly in the database or store a URL to a separate file that it manages for you.
So my question is, who's right? Is it true that Apple made a mistake in giving this option for iOS apps, and that it actually does nothing unless you're on the Mac, or does it actually do something and I'm not configuring it the right way, or is it doing what it's supposed to do and the performance is bad anyway?
I've seen some guides explaining how to store large files (like images) as files, and save the URL to them in the Core Data store instead, but since this is essentially what this new option is doing, or maybe should be doing, I'm not sure if following these guides would even help.
I'm really sorry if this has been asked before. Normally I'd be fine with figuring this out on my own, but Core Data is totally new to me, and I'm still not sure how I managed to squeak by the initial setup. Thank you for any help you can offer!
who's right ?
the iOS docset for the NSAttributeDescription class does mention the allowsExternalBinaryDataStorage and the setAllowsExternalBinaryDataStorage: methods so there is little chance that there is a mistake from Apple.
are you doing something wrong or is slow anyway ?
You said that
The attribute is a Transformable type
But Core Data has a Binary data type. Maybe only this one is linked to the external storage capability.
if that's not it, we don't have enough info here:
How many pictures do you store ?
What are their sizes ?
Do you automatically fetch all the images ?
Also, the Apple doc states that:
Core Data heuristically decides on a per-value basis…
Did you use a migration or are you starting from scratch ?
You could have a look in your app's sandbox to see if your pictures are really saved outside of CoreData.
Hope this helps.
Good question!
Check this post:
Storing blobs in external location using built-in CoreData option
Apparently it should work. You should also try it in the simulator and inspect the application data folder to see if the folders are created as described (~/Library/Application Support/iPhone Simulator/... - you will figure out the rest of the path). Also you could inspect the sqlite file with the sqlite3 command to see if the binary data is in the database.
I haven't personally used this option as I would prefer to go for manually saving the images in a folder and store a reference to them in the database instead. This way it will be easier to create UIImage object from the file to be displayed, would have better control on what goes where and so on and so forth. Will take some extra labour though!
Hope that helps you out.