New methods to manage numeric data stored in the native app

[jprietoTuenti]

Message type: INCREASE_TRIGGER / RESET_TRIGGER

Originator: Web

Min app version: B2P app 25.6 proabably although it could be 25.7 without issues

Description

In B2PDE apps app rating triggering is based on several rules. All rules have the following shape:

• {event in app} has happened at least {rule's threshold} times
  In order for the app rating to be triggered all rules have to return true

Rule examples:

• 3 or more successfull topups
• 10 or more webviews fully loaded without issues

The native app will receive the rule names (from now on, "key") and thresholds from external configuration, not relevant for this issue (more info on [link to tech spec].

The amount of times a rule event has happened will be stored in the native apps and, in order for the webview to notify the native app that a value has to be updated, the webview-bridge library has to provide new methods.

In order to provide a solution that makes easy to add new rules without having to change the native implementation we propose 2 generic methods that can be used to update numeric variables stored in the native side (no tied exclusively to the currently known rules).

increaseTrigger(key: string) => void

• if a variable for the given key does not exist, nothing is done # maybe we should return an error?
• if a variable for the given key exists, its value is updated with +1

resetTrigger(key: string) => void

• if a variable for the given key does not exist, nothing is done # maybe we should return an error?
• if a variable for the given key exists, its value is set to 0

Differences between iOS/Android (if any)

None

Payload definition

Request Payload
The key of the rule which value has to be updated, mandatory.

key: string;

Examples:

{"type": "INCREASE_TRIGGER", "id": "web-2", "payload": {"key": "topupSuccess"}}

{"type": "RESET_TRIGGER", "id": "web-2", "payload": {"key": "topupSuccess"}}

Response Payload

No response

Possible error cases

As stated in the description we might want to return an error in stead of silently do nothing when a non existing key is sent in a request

404 → Not found could be a good error code to send

[jprietoTuenti]

Would it make sense to make this methods even more generic and have them be named increaseNumVariable and resetNumVariable?
Maybe we prefer to keep them more tied to the use case as they are defined right now taking into account that this is not a approach we'd like to be widely applied.

[jeslat]

I wouldn't make these methods more generic. We haven't needed this in the past, so if we do in the future, we can just create new methods. To be more concrete, I would rename the message types to INCREASE_APP_RATING_TRIGGER and RESET_APP_RATING_TRIGGER.

I agree to return an error if the key doesn't exist in the apps.