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/
Related
Hey at the moment I'm learning Swift and started to create an App for that. Everything is fine and I think I know the basics now. In that App, I use CoreData to save my Data but I would like to Sync that across Devices
Is there a way with Icloud to do that, I found there is something called "Core Data Ensembles" But is there a better way, or should I use the IcloudKit, if I can do the same things in IcloudKit with the relations like in coreData.
I just found old posts about that, so maybe there is a better way to do this.
Thanks in advance
Such synchronization works without any libraries involved. The main trick here is to place SQL file (or whatever you use for storing data) into a special folder that is going to be synced, so-called ubiquity container, and specify path to it for your persistent store coordinator. Here you can check high-level description of how it works, and there are a lot of step-by-step tutorials about it, e.g. here.
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.
I'm creating an iOS application that has a Twitter-like feed of data. I'm currently planning on storing the data on Parse. However, what is the most efficient way to store retrieved objects locally for use when there does not exist a network connection? It sounds like using Core Data is overkill since I'm storing the data on Parse anyway. Can the Parse caching system do this for me or is there something else more appropriate? On a similar note, is there a simple way to check if this locally saved data is up-to-date?
I recommend you have a look at SQLite, especially with the FMDB Objective-C wrapper classes.
Parse has the capability to cache objects locally. If your app can tolerate the characteristics of caching, then just use that.
My own app will not, so I am using CoreData as my local store. My app has to be able to operate fully when disconnected from Parse, so I have to have something more than cached data. I looked at FTASync and found the concept very useful. When I got into the code though I realized I needed something much more robust, so I have ended up doing a completely new utility to sync Parse with CoreData. This is a huge job, so don't take it on unless your need is commensurate.
-Bob
I'm developing an app that stores data in the iPhone, but I need to know if it's possible to export the data (as an entities, tables, .txt or xls) to a desktop because I need the data to be readable on my Computer OR do I need to create a web site to do it?
By the way.. I'm still not sure what method is more effective for this kind of app, Core Data or SQLite.
Core Data on the desktop and iOS are identical. You can stand up a SQLite file created on either on the other with no issues. In these situations it is highly recommended (I would say necessary) to use the same data model in both applications.
I'm coding an app with core data. I need to sync the database between two iphones running the same app maybe via bonjour...
Can anyone help?
Thankyou!
I would suggest using cocoahttpserver for the basic network communication. Now you can either
copy your sqlite file if used in CoreData
or
use some exchange-format (xml, json) on top of the server communication.
I myself would consider idea one being quite bad in most situations, also it might fit for your use-case.
With idea two you will have more work but more control about the data representation on each phone.
Actually we are using idea two in my company. But I can't post any code here.