I build apps that bundle up JSON data. I want to switch to Firebase as my backend, but I need to ensure I can access the data even if firebase is offline. There's no guarantee that the user will have an internet connection at the time they launch the app. The data consists of a fairly large JSON blob.
I heard that firebase does cache data on iOS for offline access, and that's great. I just need to know how to bundle the data for that first time the app is ran, so the user can use the app prior to getting to a network connection.
As it sounds like you discovered, the Firebase Obj-C client does have beta support for offline access / disk persistence. Details can be found here.
But that doesn't address your desire to "seed" the app with initial data so that it has data available before the app has ever been able to connect to Firebase. Unfortunately, there's no direct support for that.
One hacky solution you could attempt with Firebase is to just do a setValue with the data in question, in order to seed the cache. This should work but will eventually try to write that data to Firebase, when the app gets connected, so you'd probably want to have security rules to prevent the user from actually modifying that data. As I said, it'd be a hacky solution.
For now it might be best to just handle this with special logic in your app that pulls data from some other data source (hardcoded values or an embedded file or whatever) until the first time you get data from Firebase.
Sorry there's no direct support for this at the moment. We'll take a look to see if we could support this more directly in the future.
Related
I'm new to Swift & Firebase and I haven't really figured it out yet. Currently I'm thinking about adding a Database to store data for the user to fetch in case he switches device.
So far I've stored data with UserDefaults. Now that I'll probably be using a Database, do I still need UserDefaults? What if the user is not able to get internet connection and closes the app, before he gets to synchronize his data going online - will there be a danger of data loss?
Or is it best to keep both - UserDefaults and the Database?
A UserDefaults from Apple documentation:
An interface to the user’s defaults database, where you store key-value pairs persistently across launches of your app. https://developer.apple.com/documentation/foundation/userdefaults
UserDefaults is a great solution for keeping unique values between app sessions. For example user settings, preferences (Simple, dummy data).
To share data between 2 devices you can use Firebase Storage. Another option is a CloudKit.
Synchronisation - this is more about what you need and how you would like to handle it. You can base on online data, so there would not be need to synchronise (you are always up to date). Or make periodically synchronisation, but you would need to think about best solution for local database.
It depends on what you are doing. Using user defaults is certainly fine for holding defaults but not information. What if 2 people use the same device, then you have user defaults for one user and a database for the other. I personally would use just one. If you are learning Firebase I would suggest 2 tutorials:
https://www.youtube.com/watch?v=F42CzqIBxHQ&t=406s
https://www.youtube.com/watch?v=RMudKhNY0sI&t=627s
and the question I just had answered about reading and writing to a secure database: User already authenticated in app and Firebase realtime database returns failed: permission_denied
What is the best way, to share a database between different devices, that are not just the user’s ones, but for example could be his friend’s phone. That means that iCloud is not an option.
Example:
All of my data is app-user specific, so basically:
user logs into my app, do some work
then he can log in with the same acc on his friend phone and data should be the same
Is there an any way to upload the whole user specific database to some online storage provider (like firebase,… ) and then download it on another device and initialise core data stack, when the same user logs in on a different device?
Or is it the only way to sync data with the server and than preload the database?
You could simply upload the whole database file(s) and then download it on another device. The problem though is portability. You need to ensure that both devices support the same version of the database so they are compatible. To port the same thing to another platform is again a different story but doable when not using core data.
Then there is a problem of conflicts. Imagine you forget to log out from the second device and you open it after a week and the database is accidentally synced back to the server. This will make you lose all the data you created on your "main" device.
So in general it is possible to sync the whole thing but you will have loads of issues. You should create a server that supports all entities and works through ids (so you know the object was modified and not created) and date modified to be able to resolve conflicts.
Syncing data between multiple devices is the biggest reason to use something like Firebase. That's one of its primary purposes. You would use Firebase for data storage instead of Core Data, and it would automatically handle syncing between devices. You don't write code to upload or download anything, you just read and write Firebase data and it handles the syncing. It supports user accounts, so if a user logs on on a different device, their data automatically syncs to that device. There are numerous other options besides Firebase, of course.
CloudKit also syncs between different devices, but it's linked to the current iCloud account on the phone. Since you want in-app login, it's not so good.
I'm writing an iOS app that uses data collected from websites. A large amount of data is retrieved when parsing the content so it needs to come from a backend server where data can be collected and added to the database once rather than parsed on the device.
I've looked at BaaS frameworks like Parse and am considering using this, but I'd like to know if it is possible to add records to CloudKit externally from say a Linux server? I've looked everywhere and can't find anything other than adding records programmatically (from the app) or via the dashboard.
You could create an OSX app (no other platforms are supported yet) that is communicating to the same CloudKit container. But then that app also needs to be signed and submitted to the app store. You don't have to make it public, you just need to submit it.
How can I have the customer of an IOS app select and change selection data for use with an app?
I have an app that is designed to operate away from wifi. As such, it needs to carry its data around with it. This makes the data requirements rather large.
A base package is 25MB of data. However, it is likely people who use this app would want as much as 1GB of data.
Is it possible to do selective data downloads and updates from the app store?
How else could this be done
How can I have the customer of an iOS app select and change selection of data for use with an app?
Hard to say. It's not clear what you're talking about. Downloading data through an app is a well researched topic. You shouldn't have any trouble finding examples for downloading data to an app, here or elsewhere.
Is it possible to do selective data downloads and updates from the app store? How else could this be done?
Again, its not 100% clear what you mean. I don't think you can use the app store to provide new data to users who downloaded your app, unless you're talking about a full app update that comes bundled with your new data set.
I worked on a project once that had to work offline, but also work with a very large data set as well as some mapping components. We required users to first download our app, then after authenticating, the app would automatically download a cache of data while connected to a WiFi hotspot. When the user was out of WiFi range the app would operate off the data set they downloaded and would operate normally. When they came back into range it would ping the server to find out if their data was stale. If it was stale it would download new data. The WiFi connection requirement ensured that they would have an optimal experience fetching the latest data.
My thought is to create a menu in your app that lets the user select which "packages" of data they want to save to their device and run those downloads in the background when the user has an internet connection.
I an building my first iOS application and I need to store the user registration details of the user using the application. The details include his mobile number and a unique id( uuid ) which I use to contact with the backend. It would be great if I could get a suggestion on where to store this user details.
Should I be storing this in the NSUserDefaults or should I be using Keychains to store this data or even may be a using a user model in the database ( I would need a database in any case to store a few other details ). Just to add on, I also would like to perform a few validations like if the mobile number is of proper format and so on before I could actually save it. Also can any one please suggest on the security aspects of different storage mechanisms possible here?
Any help on this would be much appreciated.
The most secure way would be to use keychain services as the data is encrypted but in your scenario it seems a bit over kill. I would recommend either just using NSUserDefaults or an sqlite database I wouldn't really recommend storing in a plist as this can be accessed really easily.
But this all depends on the data you are getting, if it was just uuid and mobile number then NSUserDefaults would do probably, whereas if you were getting usernames and passwords and other personal data I would looking a mix of keychain and sqlite database.
Also you could use coredata file to store user data but seems a bit over kill as well for for such little data.
Just a little note you are actually not allowed to get the iPhones mobile phone number programmatically, getting this would use Private APIs that Apple would reject your app for using.
2.5 Apps that use non-public APIs will be rejected
So you would have to ask he user for this.
Database selection is totally depend on the architecture and security, if you just need to store the few information like login details and some field then Keychain for login details and plist for data is best option, but if your application also working with services and fetching and saving lots of data and continuously updating it then a serious database structure required. In that scenario core data and sqlite both are good option depends on your preference
Following ways you can save details.
In NSUserDefaults
In coredata file.
In sqlite database
Plist file.(Not recommended)
You can save data at server site using webservice.
Any one of these you can use according to your requirement and data.
Cheers :)
If you store information on the UserDefaults, a jailbroken device can see the information you have stored, it is a plist after all. If you are going to keep sensitive data on your device, user defaults itself is not a good option. Possible alternatives:
Use keychain: Keychain is a tool to keep usernames & passwords securely on a device; so you may need to find a way to convert all the info you have mentioned ( a dict, I presume? ) into NSData and put into/get from the keychain but it's been explained on other threads. Additionally, keep in mind that when the app is deleted, keychain data will persist on the device.
UserDefaults & encrpytion: If you can encrypt the data yourself, than using UserDefaults might be a better option. Its more straightforward than keychain and it will be deleted if you delete the app from the device (which may be the thing you want, or not. It depends)