[Pushwoosh Plugin] Pushwoosh AppId and Google Project Number Across Environments

[Pushwoosh Plugin] Pushwoosh AppId and Google Project Number Across Environments

Forge Component
Published on 27 Sep (4 weeks ago) by OutSystems R&D
10 votes
Published on 27 Sep (4 weeks ago) by OutSystems R&D

We have different Pushwoosh AppId and Google Project Number across the dev, test and production environment

In the outsystems guide - https://success.outsystems.com/Documentation/Development_FAQs/How_to_Use_Push_Notifications_with_Pushwoosh, the Pushwoosh appId and Google Project Number is hardcoded straight into the plugin in server studio. However, that would mean that every time we use lifetime to deploy the apps, we have to change the Pushwoosh appId and the Google Project Number manually. 

We tried to put the Pushwoosh AppId and Google Project Number in site properties and have the app retrieve the site property on the mobile through a server action. However, the app fails to register with pushwoosh after this. 

Has anyone found a way round this?

Hi Stephen,

As far as I can tell, Pushwoosh Plugin requires that info on the device, so having server-side Site Properties isn't directly helpful... that being said, you may consider synchronising that information to a LocalEntity specifically designed for it, this way you will have the correct info on your device. You can still use the Site Properties you setup, and sync them into the LocalEntity record.

Thanks Jorge, 

We tried the method but it seems like the PushwooshAppId and Google Project Number on the web block itself needs to be hard-coded. 

The one in the login button can be from the site property. 

I don't read it like that... what you do need is to have those tow pieces of information available when your PushNotifications\PushWooshNotifications is first evaluated/rendered.

I would place the logic that fetches the PushwooshAppId and Google Project Number from the server and stores it on LocalStorage, on the device (if it's not there already) on the Splash screen for instance, that way you guarantee that you'll have all you need on time.

Jorge is right, but there is one other problem - even when the properties are stored on the device in local storage, the amount of time to complete the data fetch is sometimes greater than the amount of time it takes to render the pushwoosh client block on the screen. So you end up with a race condition that causes the pushwoosh client block to render incorrectly sometimes. The way to get around this is to surround the block in an "if" and defer rendering until the data is fetched:

This was causing more problems than seemed reasonable. Happy to say this fixed everything, and we do not appear to have any issues with devices receiving notifications in the few milliseconds it takes to retrieve this data. Performance also increases if you do it this way since you can now asynchronously load those properties from local storage and do not need to block rendering of anything visible in the app while you wait.

Hope this helps someone!