There are some threads on SO that cover this - but most of them are 12 months old. I want to understand if Meteor (and available packages) is currently capable of handling:
An App that runs both online (when there is network connectivity) and offline (when there is not).
Allows changes made while offline to be persisted to the server when online (and the reverse).
Allows the data that is persisted to be stored encrypted on the device and only decrypted when used.
Allows some attribute of the user (application password, or possibly a token generated by the server for each logon) to be used as part of the decryption key. (intent is that if the device is stolen and the screen lock bypassed the data is still "reasonably" safe).
On both IOS and Android, rooted and not.
Quoting my own reply on Reddit:
when you export let's say an apk from Meteor, this is a self contained app? this app connects o a server? does it work offline by default?
Yes, theoretically they will work offline. They do work offline now, but they cannot get new data from the server or execute remote procedures on the server w/o a connection (makes sense, right?).
If you want a fully offline app, you can try to use one of the community packages for the offline data support: https://atmospherejs.com/ground/db
Related
I came across a wonderful feature of Firebase offline feature. I integrated that in my app just by writing one line of code in my main.dart file after initializing Firebase await FirebaseDatabase.instance.setPersistenceEnabled(true);
Question 1 :
I couldn't able to understand the database.keepSynced(true) function because without using this line of code, my app is persisting old as well as fetching new updated data, so what this exactly does ?
Question 2 :
How could I prevent the write operations when a user is offline, because I read that after setting persistence enabled, it makes a queues of write operations and update them when user gets online, so how could I stop this ?
Question 3 :
Is this persistence feature going to work in IOS device as well or need some permission settings first ?
Thanks
When you call FirebaseDatabase.instance.setPersistenceEnabled(true) you're allowing Firebase to create a local file on the device where it persists any data it's recently read, and all writes that are pending while the device is offline.
When you call keepSynced(true) on a node, you are telling the SDK to always keep that node synchronized. It essentially creates a onValue listener on the node without any handler code, so you're purely doing this to keep the data synchronized for when the device does go offline.
By combining keepSynced(true) with setPersistenceEnabled(true), you're specifying that you want the app to continue working when it's offline across restarts, and which data is needed for that.
If you call keepSynced(true) on the root of your database, you're telling the SDK to synchronize all data in the database to the disk cache. While this may initially be a quick way to get offline mode for your app working, it typically won't scale when you more people start using your app.
If you only want to allow write operations while the client has a connection to the database backend, you can register a local listener to the .info/connected node, which is a true value when there is a connection and false otherwise.
Note that Firebase doesn't require this, as it queues the pending writes and executes them when the connection is restored. In general, I'd recommend working with the system here instead of against it, and also trying to make your app work gracefully in the offline scenario. In many cases there is no need to disable functionality while the app is offline.
Offline disk persistence is available on Android and iOS, but not on web.
I'm trying to make use of an API from a local bank, which uses OAuth2 as their authorization method.
The authentication process is as follows:
User clicks on button, webview within application is launched, and user is directed to
URL A: "https://{API URL}/{constant key}/{redirect url}"
Then they have to authenticate with their banking credentials, and the next page prompts them to key in an OTP.
If this is successful, the session token will be embedded in the redirect url as such:
Redirect URL: https://{redirect url}/{access token}/{type}
How can I cache or store this access token as a variable in my flutter code so that i can use it for other API calls? I am currently using flutter webview plugin and i have no issues launching the webview and reaching the different URLs, but i can't seem to find a method to store the token.
For local storage:
You can use https://pub.dev/packages/shared_preferences which uses the native counterparts for storing preferences. Its basically a key/value store.
Wraps NSUserDefaults (on iOS) and SharedPreferences (on Android),
providing a persistent store for simple data. Data is persisted to
disk asynchronously. Neither platform can guarantee that writes will
be persisted to disk after returning and this plugin must not be used
for storing critical data.
Another alternative would be SQLite with this package: https://pub.dev/packages/sqflite
SQLite plugin for Flutter. Supports both iOS and Android.
You can of course also use the File I/O capabilities of Flutter as described in the docs:
https://flutter.dev/docs/cookbook/persistence/reading-writing-files
Another route is by using a cache manager package, which will use the cache of the app together with SQLlite in the background. Might also be a solution but files can be deleted by the OS at any point in time. See the package at: https://pub.dev/packages/flutter_cache_manager
for remote storage:
Then of course, as most of the flutter developers use firestore (https://firebase.google.com/docs/firestore) or cloud storage (https://firebase.google.com/docs/storage) from the Firebase Brand, you can easily chose to go this way. Of course then the data would be in the cloud. Dont know if that meets your security requirements.
Most likely i would prefer going the local persistence way with the first mentioned methods.
Using
FirebaseDatabase.getInstance().setPersistenceEnabled(true);
Is this guarantee to download the data only one time across the App life/App restarts even if the user has good connection?
N.B: The official docs isn't clear ( at least for me) at this point.
By enabling persistence, any data that the Firebase Realtime Database client would sync while online persists to disk and is available offline, even when the user or operating system restarts the app. This means your app works as it would online by using the local data stored in the cache. Listener callbacks will continue to fire for local updates.
The sole goal of enabling persistence is to ensure that the app continues to work, even when the user starts it when they don't have a connection to the Firebase servers.
The client does send tree of hash values of its restored local state to the server when it connects, which the server then uses to only send the modified segments back. But there is no guarantee on how much data this sends or saves.
If you want to learn more about what Firebase actually does under the hood, I highly recommend enabling debug logging and studying its output on logcat.
For more on the topic, see these questions on Firebase's synchronization strategy.
Assuming my rules are setup to user read/write on owned object only, I want to know what data does firebase client (IOS/Android) store in devices? In this example, does it download the data that doesn't belongs to the user as well on the device but just blocked it? or only object owned by user will be downloaded on device.
Is there a way to just have some of the child object saved in the cloud only but not locally? I am worried about the db size getting too large in the devices.
Thanks!
Your Firebase app will only have access to data in the database that the rules permit. Security is handled by the Firebase Realtime Database (not the app) so only data that the user is allowed to access will be downloaded.
In order for your app to work with data stored in the database, it needs to be downloaded to the device. By default, data is cached so that your app still works even if your device temporarily loses its network connection. The app only stores this locally if you enable offline capabilities to allow the app to continue working when no network is available.
Firebase apps automatically handle temporary network interruptions. Cached data is available while offline and Firebase resends any writes when network connectivity is restored.
When you enable disk persistence, your app writes the data locally to the device so your app can maintain state while offline, even if the user or operating system restarts the app.
The Firebase app will automatically handle all of this functionality for you.
The size of the local cache will rarely be large enough to worry about, unless you are storing or downloading huge amounts of data, which is not recommended. If your database is large, you should implement strategies to restrict queries to only retrieve relevant data by filtering or paginating your queries.
I have built an application with Firebase and I've also made a desktop version available with nw.js. The point of this being to allow for better offline usage in areas with bad or no internet (and it will sync when the user gets internet again). Now, I can disconnect just fine and reconnect while the app is running, but I want to be able to fully close and reload the application. I've seen this blog post from firebase, but it appears this only works for mobile platforms.
Is this currently possible on the web platform, too?
All Firebase SDKs will handle intermittent loss of connectivity (driving through a tunnel). But disk based persistence, which allows the data to survive an app restart, is currently only available in Firebase's iOS and Android SDKs.