Extending the Omnis JS Wrapper for iOS

[Christoph Schwerdtner Participant]

We’ve modified the JS Wrapper 1.5.0 for iOS so that we now can use:
– Touch ID (fingerprint services within Omnis)
– Apple Push Notifications to receive messages when the app is NOT running
– Silent Apple Push Notifications to perform background tasks in Omnis while the app is NOT active
– Badges in your iOS App Icon to show the number of unread mails or anything else you can imagine

In fact there are no limitations for extending the wrapper.

Next steps might be using Health Kit, Home Kit or even InApp Purchases.
What do you think?

[Jason Gissing Keymaster]

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?

[Christoph Schwerdtner Participant]

Hi Jason,

this sounds promising!

Silent notifications have been tested successfully. On iOS you have to activate this as a capability in the Background Modes section. It’s named “Remote notifications”.
Then I added an AppDelegate method didReceiveRemoteNotification that calls basically a Javascript method in the viewController.

Something like this:

	NSString* jsCode = [NSString stringWithFormat:@"jsWrapper.didReceiveRemoteNotification('%@','%@');", action, data];
	AppDelegate *appDelegate = (AppDelegate *) [application delegate];
	[appDelegate.viewController callJavaScript:jsCode];

Jason, of course you know better than anyone else about the details. The following is just for all the guys not familiar with it so everybody can get a clue about what we’re talking about.

jsWrapper in fact is a Javascript module that I defined in an Omnis Library js method. This is the place for every extension callback.

Using this concept I can use EVERY iOS feature within Omnis.
Generally we face two situations:
1. Actions initiated by iOS itself (like push notification)
In this case we simply need to define a module method and call it using the procedure described above.

2. Actions initiated by Omnis with some iOS follow up and results given back to Omnis.
In this case we need to extend the Javascript traffic control in the OmnisJSViewController. To be more specific it’s the method
webView:shouldStartLoadWithRequest:navigationType:

Example: At some time in code I need the push token of the device so the server app can push a message to the device at any time. Therefore I’ve written a new device method getPushToken that in return calls jsWrapper.getPushTokenComplete. At app init I get the push token from iOS infrastructure and save it in an iOS variable for later use.
To be more generic it might be a good idea to initiate the push stuff from an Omnis method so it would be up to the developer if he uses push functionality or not. This might be important because the user could be annoyed if he gets the notification about allowing push notifications being sent the very first time of app use. If this is within a device call the omnis developer can decide whether to bring it up or not. Callback is done asynchronously as always using my jsWrapper module.

To give you some idea about the js code within Omnis I give you my module skeleton here:

The following must be placed within the $init method of your apps offline form

;  Definition of module jsWrapper to access device functionality
JavaScript: window.jsWrapper = (function() {
JavaScript: return {
JavaScript: applicationDidEnterBackground: function() {
Do $cinst.$applicationDidEnterBackground()
JavaScript: },
JavaScript: touchidTestComplete: function(pOne) {
JavaScript: lVar = pOne; 
Do $cinst.$touchidTestComplete(lVar)
JavaScript: },
JavaScript: touchidComplete: function(pOne) {
JavaScript: lVar = pOne;    
Do $cinst.$touchidComplete(lVar)
JavaScript: },
JavaScript: getPushTokenComplete: function(pOne) {
JavaScript: lVar = pOne; 
Do $cinst.$getPushTokenComplete(lVar)
JavaScript: },
JavaScript: didReceiveRemoteNotification: function(pOne,pTwo) {
JavaScript: lVar = pOne; 
JavaScript: lVar2 = pTwo; 
Do $cinst.$didReceiveRemoteNotification(lVar, lVar2)
JavaScript: },
JavaScript: Version: 1.3
JavaScript: }
JavaScript: })();

As you can see we’ve defined these methods here:
applicationDidEnterBackground
touchidTestComplete
touchidComplete
getPushTokenComplete
didReceiveRemoteNotification

These methods call my Omnis delegate methods
$applicationDidEnterBackground()
$touchidTestComplete(lVar)
$touchidComplete(lVar)
$getPushTokenComplete(lVar)
$didReceiveRemoteNotification(lVar, lVar2)

Now it’s easy to use Omnis Code to handle the results of all this.
To give you a more concrete sample:
I want to use the fingerprint sensor within my app to make the app more secure.
First I need to test if touchid is available. If it’s not (iPhone 4), it doesn’t make sense to show a fingerprint icon in the app.
So I’ve written a command touchidTest. The result is given in a call to jsWrapper.touchidTestComplete which calls the omnis method $touchidTestComplete(lVar). The parameter gives info whether the hardware is available or not.
If it’s available I can call device method touchid which brings up the typical fingerprint message on the iPhone. Finally the result is given in method touchidComplete which call omnis method $touchidComplete(lVar) with result of id process.

The push notification is given in didReceiveRemoteNotification with some action and data information in its two parameters. This is useful to have some different action types like data update push, private message, breaking news etc. Data contains even more payload.

Have fun

[Jason Gissing Keymaster]

Hi Christoph,

Thank you very much for all of these details – very interesting!
I like your approach – it is very clean.

I have steered away from calling a form method when the notification actions take place, as I could envisage this causing problems for developers who are changing the top-level form in their application (using $changeform/$openform etc). Although I can see that if you can ignore this, it allows developers much greater freedom in how they react to notifications.

What would happen in that case for your framework? I guess the calls to the Omnis methods in jsWrapper may fail because the original form instance has gone away?

[Author]

Posts