I am designing an architecture for an iOS SwiftUI app and I have no experience with it so I need to clarify few things.
My app will use these datasources:
Bluetooth device
API
CoreData or Realm
Bluetooth device sends data regularly (every 5 minutes) and I have to be able to get them even the app is in the background (or terminated) if possible. Data should be stored somewhere and synced to the API when connected.
Also app should be capable of determining when to use persistent storage and when to use API. One idea is that I would always use for example CoreData and data received from bluetooth device would be stored there (it should automatically rerender view). API will be requested regularly in the background, data from API will be compared with local data and synced appropriately.
I dont’ know, where should I start. I researched commonly used architectures and I really like hexagonal and clean architectures, but I can’t image how to use it correctly.
I didn’t find any resources mentioning switching datasources as the user is online/offline. If is it appropriate to use always CoreData in the app or if I should switch datasources and synchronize with CoreData in the background.
Related
I am designing the architecture for a ToDo toy app to get familiarized with the latest version of Apple frameworks like SwiftUI and Core Data.
One requirement is that the ToDo app must be able to sync in real-time with other instances of app running on other devices. So, in all likelihood I will need to store the state of the app somewhere external to the devices as well.
I see that Core Data offers a data persistence layer on the device but what I am not understanding is whether it can support the real-time requirement. I see that it can also support CloudKit but, can it be in real-time? I am not seeing much info on this.
Also, what I do see a lot is Firebase integrated with SwiftUI.
I'm currently working on a project that uses CoreData for data saving in swift, and for the purpose of synchronization I wanted to use iCloud, and the first thing I thought was on the CoreData iCloud implementation, but since it's now marked as deprecated I started using CloudKit, and everything works fine until I try to make a backup of the information after an internet connection is stablished (in case of failure when the information should be updated), the app does not store files, just data, all CKRecords are working fine.
My questions are:
Can you synchronize the information after the application is terminated?
Does CloudKit connect to the automatic iCloud synchronization, the one that happens when the device is plugged and has an internet connection.
The current structure is:
CoreData for local saving and withdrawal of data, and CloudKit for Cloud synchronization.
So far I understand that: CloudKit does not interact directly with CoreData and all actions involving data synchronization must be done with the Api calls.
Thank you for your help and if I forgot something please let me know.
1) When your app is terminated it isn't running so you can't sync anything. You would need to re-launch your app (possibly into the background?), but there are some serious limits to what you can do to have that happen without user intervention. Here's a couple threads that might shed more light: Launch app in background automatically? and Will iOS launch my app into the background if it was force-quit by the user?
2) Out of the box CloudKit doesn't do anything 'automatically', it does what you tell it to do. You will need to set it up to fire at appropriate times in your code (when something changes), and in response to push notification for changes from other devices.
I'm new to IOS programming, and I have had a great time learning it. It took me about 4 months to really get a good grasp on it. I have began creating my own app, and I ran in to a few questions. The app I'm creating is a live app like instagram, foursquare, etc. How do I store all of the information I need. Can I use Core-Data to create a real-time app that can handle updates from multiple users?
The app I'm creating is a live app like instagram, foursquare, etc.
How do I store all of the information I need.
You'll probably create some sort of server to manage the data. Having a single, central source of data is a lot easier than trying to sync data between multiple devices.
Can I use Core-Data to create a real-time app that can handle updates from multiple users?
You can -- Core Data works on MacOS X as well as on iOS, so you could write a Mac program that is the server for your iOS app. Whether that's the best approach is another question... I suppose it depends on how well you already know Core Data, whether there are any advantages to using the same Core Data data model on both the server and the client, how many clients you think you might have to support at once, etc.
If you're asking about using Core Data on the iOS client, then yes, you can certainly do that.
We have finished writing an iPhone App that uses coredata.
In further versions we plan to add an iPad App that is able to display the data collected by the iPhone App (and of corse modify, use it) to give more interaction possibilities to the user.
My question is: Is it possible to move existing coredata (of already installed apps on iphones) to the cloud and read that data out with an iPad application?
If yes: can you point me in the right direction of where to start?
If no: is there another alternative to access coredata created with an iPhone App with an iPad app?
When using Core Data's built in iCloud support it doesn't matter what kind of device you're on, only that the Core Data stack is initialized the same way. Any iOS device or Mac can use the same iCloud store, and data created on one can be read on another.
One crucial detail though: If you already have a data store and you add iCloud support, those pre-existing records do not automatically get migrated to the cloud. iCloud works based on transaction logs, and transaction logs are only created when you save changes. Existing data that doesn't immediately change generates no transactions, and therefore doesn't go to the cloud.
If you have existing data when you add iCloud, you'll need to migrate the data to a new data store to force transactions for those existing records. You can do this fairly easily using NSPersistentStoreCoordinator's migratePersistentStore:toURL:options:withType:error: method. It's not hard, but it's not always obvious that it's necessary.
To get started, I first suggest watching Apple's WWDC videos on iCloud-- especially WWDC 2012's session 227, Using iCloud with Core Data. Next, I suggest extreme caution, because as of today Core Data's iCloud support is still, shall we say, far from being the most reliable of Apple's APIs.
i have an iphone app that uses coredata to store its contents. users often ask me if i could provide a way to sync data between their mobile devices (ipod/iphone/ipad). as of now, i have no idea on how to achieve this.
i found zsync, but this seems to depend on a osx version of the app (which i dont have). i also read about upcoming iclouds sync features, and it seems to be what i need - however i think its not possible to sync coredata contents, but text-based contents only (e.g. xml storage files). is this true?
another way i was thinking of was to abuse the eventkit api to sync via a user-provided calendar. since my app is mainly managing events, which can optionally be stored in a user-calendar (in addition to coredata storage), syncing through a calendar would seem good to me. however i think syncing might break, e.g. when the user chooses not to syncronize the whole calendar but only like 3 months in the devices settings/account settings.
anyone got an idea of how my approach should be like? any tips?
Syncing device to device (if that is what you are trying to achieve) can be quite tricky. You could implement your own discovery and data-transfer protocol and work something out that way, but it could be quite a bit of work.
Syncing device to server to device is a bit more straightforward, assuming that you already have a server with some form of registration/login system. Then you just need a way of communicating your current database state up to the server, and then back down again from the server to other devices. Again there is a fair bit of work involved in doing this, but at least the logic of working out which devices sync with which other devices and how they transfer data from one to the other is all implicit in the workings of the server.
As for iCloud, the programmatic content that you sync through it needs to be derived from UIDocument, so it will not help you with generic Core Data entities.
If you're looking for an out-of-the-box solution that will sync all of your Core Data content from one device to another with no custom code, then there really isn't one. The closest you can reasonably get would be to ship the entire .sqlite file that your app uses from one device to another, overwriting the target devices .sqlite file. That works fine if your sync only needs to be unidirectional, but obviously is not appropriate for other use-cases. Perhaps you could use this model with iCloud, if you can get it to sync your app's entire .sqlite file as an atomic entity.