Great work, Christoph – this sounds excellent!
I am currently working on implementing Push Notifications into Studio & the wrappers for a future release. This will be cross-platform, so will probably be less specialised than your solution.
We are examining using Firebase for iOS & Android, as Firebase is the officially recommended means of sending push notifications to Android, and it also works with iOS. So developers will have a single service to set up & administer (unless they’re using the Win 10 wrapper).
The current high-level approach is to call a method on the server to send a notification to specific devices, all devices, or devices which are part of a specified ‘group’.
– You can send the text to display in the visual notification, and a series of key-value pairs as the data payload.
– When the client receives the notification, it will display as a native notification on the device (whether the app is open or not).
– When the user clicks the notification, if the app is closed it will be opened, if it is already open, it will reload your main form. In both instances, any data you passed as part of the notification’s Data Payload will be passed to the form’s $construct row parameter, as JSON text in the URLparams column.
We will probably also expose functionality to set the badge count (for iOS) with your notification, and any other parts of the Firebase API which we think would be useful. Or just allow you to specify the raw JSON directly, so that developers can use all functionality the API provides.
I’d be interested as to how you are handling the ‘silent’ notifications (Firebase terms them ‘data-only’)?
My current feeling is to include stub methods in the wrapper code for handling these, so as not to support them ‘out of the box’, but allowing developers to add their own code here, should they wish to use them.
I would be very interested in your (or any other developer’s) thoughts on this approach.
I would also like to be able to make the wrappers more easily extensible (especially if there is a call for it from Omnis developers).
Do you think there would be a significant benefit to this? i.e:
– Did you find that you had to fight against the wrapper in some ways to get your extensions to work?
– Would it be a pain to implement your extensions into a new version of the wrapper?