I am planning to develop a quiz app in iOS and doing it offline. I need to store 100s of questions and options in that app. How to store? How does core data comes in handy here? Is there any other good methods for this problem?
The app is meant to be offline.
You can also use SQLite database for saving Questions and Answers offline for your Quiz app. You can create tables in SQLite and save and fetch data from that using SQLite queries.
I would recommend you to use realm.io. It measures better than core data, its fast and simple to use. On https://realm.io there is lots of documentation.
I find realm much easier to set up and in generally to comprehend. It works nicely with SwiftJSON and hence in my view much easier to connect to backend.
Preloading core data can be quite cumbersome and to me it seems that core data still relies heavily on objective c.
On the other Core Data is made by Apple so it could be more stable solution on longer run (parse.com)
Related
I'm currently learning ios core data and I understand that core data is based on sqlite.
I can find documentations on core data at apple's developer, but there seem to be no documentation on sqlite. However, sqlite does have its own website and documentation.
I was wondering, does ios has its own sqlite documentation? Or everything at https://www.sqlite.org/docs.html is applicable to ios sqlite?
Yes, the http://sqlite.org/cintro.html and http://sqlite.org/c3ref/funclist.html documentation works for Swift. See https://stackoverflow.com/a/28642293/1271826 for example of how you can do it. But you might want to find a nice Swift SQLite wrapper class to get you out of the weeds of SQLite's C API (as well as avoiding pitfalls of leaking because you didn't follow the excruciatingly detailed steps required by SQLite's C API).
That having been said, if you're using CoreData, I'd encourage you to stick with the CoreData API, and not dip into SQLite's C API. But, if you want bypass CoreData entirely and only interact directly with SQLite, you can do it like suggested above. But I might suggest really sticking with CoreData unless you have a compelling reason not to.
Everything at sqlite.org/docs.html is applicable in iOS SqLite ...because Core Data is only for iOS but SqLite is available for many platforms ..
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.
Good Morning,
I am in the process of designing an app. It will capture data in the device and will sync with a web server, I have a few months learning Swift to develope iOS apps and I am learning to use core data now with small samples.
I have a book I've been reading and available resources like this one:
https://developer.apple.com/library/watchos/documentation/Cocoa/Conceptual/CoreData/index.html
My question is:
Do I have to start learning how to sync and save data in the device at the same time? or I can learn Core Data first, make the app and then start the process of syncing (using JSON)?
What available resources can I see to learn what I need?
This is new for me, I have a friend who knows Ruby and has knowledge about API, but he does not know how mobile devices works in this matter.
I have searched here, but a lot of question and answers I see covers specific topics.
Your help and time is really appreciated. Thanks!
P.S.
I apologize for the term sync (send and receive data to/from the server) if I a using it wrong, or should I use the term API? For me is a little confusing on how to use the term, since it is use for a few things, like data, but also it's used when talking about a method which all the info you need to go to the API of the method, function or class.
The process you should follow is first learn basic iOS developemeet. Check out the tutorials at raywenderlich and hacking with swift. In the process you will learn a bit about networking(working with APIs) and Data Persistence(Core Data).
Since collection of data precedes storage of data you must learn first about REST APIs, JSON, JSON parsing and related stuff, third party libraries available like Alamofire and SwiftyJSON(these can be installed using cocoapods)
And then jump into data persistence which can be done through sqlite database(FMDB is a wrapper available and is super easy), Core Data, NSUserDefaults, plist, Realm etc.
I am developing a small set of classes that will make it easy to keep your Core Data in sync with your Firebase. But, I recently came across Firebase's iOS Offline Capabilities and I noticed, regarding data persistence, it sounds to me like similar capabilities that Core Data would provide.
As I said, I am trying to make it easy for my Core Data to stay in sync with my Firebase. How do the two differ (if at all for my case)? More specifically, will Firebase offline provide similar effects? My intentions are for a single-user app, I do not need to support multiple users simultaneously on the same app. I need the data to persist so that users can access their data offline, and between app sessions/restarts.
I work at Firebase, and I once tried to do the same thing.
The Offline Capabilities of Firebase make using CoreData a bit superfluous. Firebase's offline handles a lot of the complexities like dealing with authentication offline and syncing after being offline for long period of time.
It might be useful to have a wrapper around CoreData if you really want to use the two together. However, I have found that it ends up being more complicated than it's really worth.
As an additional answer...Both Core Data and Firebase can both store data 'offline'. They have data persistence and will enable your code to run offline transparently to the user.
To dig a bit deeper, Core Data doesn't have an 'online mode'* (built in) whereas, as soon as Firebase has a connection - wham-o, all of your offline data is now online. (*CloudKit gives CoreData that online-ness)
Additionally, Firebase has real-time data updates, so if that's what you need Firebase is the way to go for that functionality.
So for your use case, as David mentions, you are duplicating off-line functionality in many ways - especially if this is a single user only use.
If you've already got CoreData & CloudKit working, it may not be worth the time to also loop Firebase into the project - it really depends on the scope of the classes you are building.
I have started with Firebase and stumbled upon these two issues that made me switch back to CoreData:
No offline search - Firebase (online or offline) search is very limited, and they recommends using a third party service like Aglolia, which needs another subscription, another offline mode, another authentication etc. CoreData just supports searching via SQL like language and it is easy.
No offline attachments - Firebase (real time database or cloudstore) doesn't have offline attachments feature, and Firebase Storage doesn't have an offline mode as well, so I will need to implement this on my own.
Hey guys,
what would you say is the best way to ship initial data with an Core Data iOS App?
Is it maybe to once run the app, store the data and then insert the datafile in the build?
There must be a better way..
I have had good experiences with loading the data into a sqlite backing in the simulator, and then bundling the resulting sqlite file with the app.
Especially for bigger datasets, first-run filling of the database is not really an option.
I've been toying around with the same problem myself, recently; and what I opted for was to store the data in the app in some easily parsable (for me) format, and parse and incorporate it on first run.