Questions about being confident of recognizing the initial user

[sneko]

Hi @NLueg ,

I already asked my question on another repo. You all try to target the same need, but I'm missing some information and I hope to get it somewhere :) .

If you could take a look at sencrop/capacitor-firebase-dynamic-links#6 (comment) and tell me what you think, it would be great!

Thank you,

For record here is the message:

I'm interested by the "MatchType" variable in iOS to leverage the Firebase score if they are confident this is a user coming from the initial link or not:
https://firebase.google.com/docs/reference/swift/firebasedynamiclinks/api/reference/Enums/DLMatchType

From what I understand it would allow me to know for iOS if the user clicking the dynamic link before installation is the same than after (can be useful for referral system and so on...). Do you plan to support this?

I guess on Android this score does not exist because Firebase is able to pass a parameter "referrer-id" to the store, that will be pass to the app at the end, so there is no doubt of the "uniqueness" (user at click, user at install). (ref: https://stackoverflow.com/questions/58790604/matchtype-in-android-firebase-dynamic-link-sdk)

Aside this, I try to figure out a case where Firebase does not document that much:
I plan to integrate your plugin in my PWA app, and when on a browser on a mobile, dynamic link will work perfectly, except that when I'm in a desktop browser, the redirection is targeting the link, not the store (I thought at first Firebase would set the fallback automatically but it does not make sense if online version). In my case, I have a Smart App Banner to encourage the user installing the native app, so when on desktop browser I let the choice on it between Android and iOS installation, when the choice is made by the user I create the dynamic link with ofl parameter as the right store link (iOS/Android) so the user are redirected to it. At the end the user will know how to install the native app (moreover Google facilitates it from the browser since we see already linked devices), but I'm not sure after installation the user will be recognized based on IP... have you tried something similar? Or an advice?

[sneko]

@NLueg from what I see, the idea would be to return the matchType with the "absoluteLink" as on what you have:
https://github.com/Pantrist-dev/capacitor-firebase-dynamic-links/blob/main/ios/Plugin/Plugin.swift#L123

On the other hand I think a good improvement would be to also give in the result a boolean telling if "yes or no" the link is the one that started the application.

In my case, I differentiate the routing process from "at start", and "after the start" (universal links...) since almost all the application has main modules loaded (splashscreen hidden...). This can be easily done since handleLink(...) is only triggered by:

• https://github.com/Pantrist-dev/capacitor-firebase-dynamic-links/blob/main/ios/Plugin/Plugin.swift#L86
• and https://github.com/Pantrist-dev/capacitor-firebase-dynamic-links/blob/main/ios/Plugin/Plugin.swift#L70

Tell me what you think, that's simple improvements but they bring lot of interest 😄 . For instance the matchType was already handled in the most used similar plugin for Cordova: https://github.com/chemerisuk/cordova-plugin-firebase-dynamiclinks/blob/a93c3fde7b987449fdad9f7ad18c4ec55389b154/src/ios/FirebaseDynamicLinksPlugin.m#L171-L178 (even if they restricted to 2 values the matchType instead of the 4 possible).

EDIT: for the first one I just tried this line:

      self.notifyListeners("deepLinkOpen", data: ["url": url.absoluteString, "matchType": dynamicLink.matchType.rawValue], retainUntilConsumed: true)

and it works perfectly. I can now temperate if Firebase is confident or not that's the same user

EDIT2: could be good too to have implementation/documentation to stop listening (removeAllListeners and removeListener)

[NLueg]

Hey @sneko, thank you for your issue and your thoughts of supporting the matchType!
As I can see, you already did some research in how to integrate it in this plugin. I would be very happy, if you could create a PR for this that the implementation totally fits what you would expect.

I also added a short comment for the removeAllListeners method to the documentation. For removeListener I added no documentation as it's not clear how this is expected to work. To remove a Listener, you need to call remove on the PluginListenerHandle which is returned by addListener

[sneko]

@NLueg I may be wrong but yesterday I tried to call CapacitorFirebaseDynamicLinks.removeAllListeners(); as it exists for some other Cordova/Capacitor plugins but it was throwing an error.

I listed all properties/methods of CapacitorFirebaseDynamicLinks and it appears there was no removeAllListeners at all at runtime (javascript object).

I just took a look at your commit, it's just about the docs, but I just wanted to warn it seems not implemented at all. I'm not really aware of plugin development but maybe there is something to enable to get it set up?

[sneko]

About doing a PR for the "matchType", I'm not totally confident how it should be done to keep things separate between iOS/Android. In my case I just assumed it was a test so I put it directly in the object.

• I'm wondering if this should not be scoped in a nested object like ios since it's only for this platform?
• Also, I guess Typescript should be modified too, to export an Enum instead of relying on the integer directly

[NLueg]

@NLueg I may be wrong but yesterday I tried to call CapacitorFirebaseDynamicLinks.removeAllListeners(); as it exists for some other Cordova/Capacitor plugins but it was throwing an error.

I listed all properties/methods of CapacitorFirebaseDynamicLinks and it appears there was no removeAllListeners at all at runtime (javascript object).

I just took a look at your commit, it's just about the docs, but I just wanted to warn it seems not implemented at all. I'm not really aware of plugin development but maybe there is something to enable to get it set up?

That's because it wasn't part of the definitions in the current version. But that's really strange, that it's not part of the JS-Object.
I just oriented myself by the official Capacitor plugins: https://github.com/ionic-team/capacitor-plugins. They also don't have any implementation for the removing.

[NLueg]

About doing a PR for the "matchType", I'm not totally confident how it should be done to keep things separate between iOS/Android. In my case I just assumed it was a test so I put it directly in the object.

• I'm wondering if this should not be scoped in a nested object like ios since it's only for this platform?
• Also, I guess Typescript should be modified too, to export an Enum instead of relying on the integer directly

If I understood you correct, we would have something like the following?
This is perfectly fine for me.

export interface DeepLinkOpen {
  /**
   * The URL that was opened
   */
  url: string;

  ios?: {
     matchType: MatchType
  }
}

export enum MatchType {
  ...
}

[NLueg]

Closed as there is no progress after a year. If this is still relevant for you, feel free to reopen it.