I am writing a function with firebase cloud function. Is there a way to find out which version of the application the mobile user is using?
what i want to do is this: function will work differently if the user is using version 1.2.4 and earlier of my app. It will work differently if using version 1.2.5 and above.
I'm currently unaware of any version information that is exposed in the authentication tokens or the API calls themselves out of the box. Implementing such detections is a responsibility of the author and in certain regions, collecting such data must be communicated to the end user.
Going forward, each time you make a function call, either:
include an ordinal version whenever your API changes (e.g. { v: 1 } in the request body, or ?v=1 or /v1/endpoint in the URL), or
include the true app version after seeking the appropriate permissions (e.g. { app: 'and.1.2.6' } in the request body, or ?app=and.1.2.6 or /and-1.2.6/endpoint in the URL).
Related
There is a new JSWASM approach that allows saving to SQLite (the fast OPFS way) in the browser via a javascript Worker. A sample is here that is (sort of) for a Chrome extension. Ideally, it would allow saving from the background.js, but it's unclear whether a worker can be called from there in MV3 based on this and this. Does anyone have a simple working example closer to my use case, which is saving content from the user's active tab to a SQLite database? Thanks.
The OPFS depends on the createSyncAccessHandle() method, which is exposed in Worker threads. The usual feature detection goes like this:
if (self instanceof WorkerGlobalScope && 'createSyncAccessHandle' in self.FileSystemFileHandle.prototype) {
// OPFS in `Worker` is supported!
}
Now an extension service worker (as currently implemented in Chrome) is an instance of ServiceWorkerGlobalScope, so the API is not supported there.
Unfortunately at the moment the only choice is to open an extension page and then run the OPFS code from there.
Since AppCenter retiring at the end of this year, I have started migrating to Azure-Notification-Hub.
But the documentation for notification-hub is not clear at all. Especially the documentation for Xamarin.Android. It does not match with their latest SDK.
In the latest (version 1.1.1) azure-notification-hub SDK for Android (or Xamarin.Android) there's no need to implement FirebaseMessagingService. NotificationHub.Start() method registers the device in the Notification-Hub. A device registered with this way gets notifications without any problem.
NotificationHub.Start(Application, <HubName>, <ConnectionString>);
Addition tags to existing NotificationHub instance are also straightforward with the new SDK.
NotificationHub.AddTag("username:user123");
But in Registration Management official doc states that devices can register with the notification-hub either from client-side or from server-side. Is it necessary to use one of those methods if my app registered with the notification-hub using the NotificationHub.Start() method? Or do I missing something?
Also, when I was using the AppCenter, I have used the AppCenter-InstallId to target a specific device.
With that in mind is it possible to use the NotificationHub.InstallationId to use as a tag (eg: "handle:<devce's InstallationId>") to send device-specific notifications?
Is it necessary to use one of those methods if my app registered with the notification-hub using the NotificationHub.Start() method?
When you invoke NotificationHub.start(Application, ...), the Android SDK will listen for changes like added tags, new FirebaseMessagingService tokens, etc. Anytime it detects a change, it will invoke an InstallationAdapter to inform a backend of the new details.
The default InstallationAdapter will send an PUT request to the Azure Notification Hubs backend as documented here. This is what is created by NotificationHub.start(Application, string, string); for people who are not hosting their own backend, this is a sensible default.
If you have your own backend where you track devices, or you're just looking to keep your credentials server-side, you can swap out the InstallationAdapter to be a class that invokes your API. All you need to do is implement the InstallationAdapter interface and initialize the SDK by calling NotificationHub.start(Application, InstallationAdapter).
If you use the NotificationHub.start(...) methods as indicated above, there is no further registration action required.
With that in mind is it possible to use the NotificationHub.InstallationId to use as a tag (eg: "handle:<devce's InstallationId>") to send device-specific notifications?
Yes! This documentation walks you through how to use the special tag format $InstallationId:{YOUR_TAG_ID} to target a specific device.
When you've used NotificationHub.start(), if you do not specify an InstallationId, it will generate one for you.
Question about setting the InstallationId and/or UserId. If I'm using Microsoft.Azure.NotificationHubs.Client, which makes more sense to do.
Should I set the InstallationId via the $InstallationId Tag (see here: https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-registration-management#installations) or via implementing the InstallationEnrichmentAdapter and set it via a call to installation.InstallationId = in the EnrichInstallation method?
Additionally, the Microsoft.Azure.NotificationHubs.Client.Installation class provides a UserId property that can be updated too.
I'm also moving my push notifications from AppCenter to Azure Notification Hub and want to reuse my existing AppCenter InstallId.
i am able to add tags and userid as below(java)
NotificationHub.start(this.getApplication(), BuildConfig.hubName, BuildConfig.hubListenConnectionString);
NotificationHub.setInstallationId("123");
Set<String> tags = new HashSet<>();
tags.add("role_memeber");
NotificationHub.setUserId("123");
NotificationHub.addTags(tags);
sdk: com.microsoft.azure:notification-hubs-android-sdk:1.1.6
I want to verify if a user exists in the Authentication list of users in firebase. I know I can use:
admin.auth().getUserByEmail(email)
admin.auth().getUser(uid)
I am building a react native app, so I can't install firebase-admin since it would require I ship credentials in the app, which is too dangerous, since someone can do reverse engineering and find them.
I have found I can write functions, so I have created a separate project to create and deploy functions, this will work as a backend.
Now I want to create a function there that uses firebase-admin and to be able to use the 2 methods listed above.
I found I can create:
exports.addMessage = functions.https.onCall((data, context) => {
// ...
});
and call it like:
var addMessage = firebase.functions().httpsCallable('addMessage');
addMessage({text: messageText}).then(function(result) {
// Read result of the Cloud Function.
});
Not sure if using https.onCall is the best for this case or is there a better way.
Thanks in advance.
As far as the documentation indicates - accessible here - and the fact that the https.onCall() uses a safe method to be called (HTTPS) I believe that this is the best option for your case, since installing firebase-admin doesn't fit your case.
The official documentation Protocol specification for https.onCall also says:
If you are able to use the Android, iOS, or web SDKs, you're recommended to do that instead of directly implementing this protocol. The SDKs provide features to save coding time and effort, as detailed in Call Functions from Your App
So, this is indicated, in case you don't want/can use the SDK, which I believe it's what you are saying. Considering that, I believe that the https.onCall() it's the option for your situation.
Let me know if the information helped you!
I am trying to connect my Adobe Captivate XApi course to the LRS (YetAnalytics). I have very less information as to what should i add in this code of tc-onfig.js in the course files:
// Pre-configured LRSes that should receive data, added to what is included
// in the URL and/or passed to the constructor function.
//
// An array of objects where each object may have the following properties:
//
// endpoint: (including trailing slash '/')
// auth:
// allowFail: (boolean, default true)
// version: (string, defaults to high version supported by TinCanJS)
//
TC_RECORD_STORES = [
{
endpoint : "",
auth : "",
allowFail: ,
version: "",
}
];
Generally you should avoid using that functionality. That code is leveraged by an underlying library in Captivate (Rustici Driver) for packages with a tincan.xml file. That package will be launched with an LRS endpoint and authentication credential which is where it will send the statements that it generates. Generally it is a much better idea to send all statements to that configured LRS and then figure out a way to get those statements either forwarded from or pulled from that LRS into your additional LRS(s).
This is for two main reasons. First by using this functionality you have to hard code a credential into the package which makes it insecure and indistinguishable during requests, this is generally just bad. Second, there is little to no error handling around calls that leverage this functionality, so if you set allowFail to false exceptions will go uncaptured and the content will likely behave in strange ways (or break completely), if you set allowFail to true then you will have no recourse when a call fails and you potentially will not know that you've lost data.
(Unfortunately, I know this because I implemented the functionality originally a very long time ago before fully understanding all of the ramifications.)
But just so I've answered your actual question, if you wish to not heed my advice, then the values that should go there will be passed through to the constructor for a TinCan.LRS object which is documented here: http://rusticisoftware.github.io/TinCanJS/doc/api/latest/classes/TinCan.LRS.html
The auth being the most tricky, it should be a value that is a full Authorization header value as needed to connect to the LRS, very often a Basic Auth header.
I have used the techniques in the RealmTask tutorial (https://realm.io/docs/tutorials/realmtasks/ ) to get a demonstration of synchronisation with the Realm Object Server working. However, as mentioned in realm mobile platform, how to connect while offline? , it is difficult to find design guidelines on realising a robust app in the presence of intermittent network connectivity. For example, the network might not be available when the app is first run, and in the tutorial example I think the login attempt would just time out after say 30 seconds.
From various sources, I have tried to outline an implementation approach on the client and have come up with the following:
=============================================================
At start-up of app
Create login credentials with
SyncCredentials.usernamePassword()
Check whether user credentials already exist using
SyncUser.all
If so, get the correct user using the appropriate key (UserId)
If a user is obtained, get the Realm configuration using
realmConfiguration = Realm.Configuration(SyncConfiguration(user, realmURL))
Attempt a log-in with
SyncUser.logIn with SyncCredentials
On completion, put the following on the main DispatchQueue (async)
realmConfiguration = Realm.Configuration(SyncConfiguration(user, realmURL))
if not logged in, repeat login attempts every N minutes until successful? E.g. to handle the situation when the network is unavailable when the app is started, but then becomes available?
Launch the rest of the app, making realmConfiguration available.
However, only access the Realm if realmConfiguration has been set up. Design the app so that it handles the scenario of realmConfiguration not being set up.
=============================================================
Is the above approach sensible, or is there a better solution?
Katsumi from Realm here. Our RealmTasks demo application may help you.
https://github.com/realm-demos/realm-tasks/tree/master/RealmTasks%20Apple
First, check whether the user has logged in or not at launched the app.
if configureDefaultRealm() {
window?.rootViewController = ContainerViewController()
window?.makeKeyAndVisible()
} else {
window?.rootViewController = UIViewController()
window?.makeKeyAndVisible()
logIn(animated: false)
}
https://github.com/realm-demos/realm-tasks/blob/master/RealmTasks%20Apple/RealmTasks%20iOS/AppDelegate.swift#L35
If the user has been logged in before, you can use user object that was cached before. (SyncUser.current or SyncUser.all)
If there is no cached user object (The user is the first time to use the app, or the user re-installs the app), show login view to signing up/in.
The former case (Use the cached user object) doesn't require network access, so you don't need to care about the offline situation.
The latter case (The user should signing up/in) requires network access, in that case, the best practice depends on the specification of the app. It is enough to show a just alert view that indicates requiring network for some apps, or use standalone Realm and then migrate synced realm after the app will be online.