O$: Push Notifications anyone?

Paul Mulroney pmulroney at logicaldevelopments.com.au
Sun Jun 10 04:33:15 EDT 2018


Hi Gavin,

Thanks for your feedback!  For Push Notifications, you don't need to setup a push connection - it's handled slightly differently.

I ended doing this: I registered with FireBase, then at least once for this device I do this (in the main form):

Do $cinst.$clientcommand('enablepushnotifications',kTrue) Returns vbResult    

and then later on, when the device receives a notification, you need a way to pass the details of the notification via the main form.  I had the following in the $construct of the main form:

;  - Push Notifications
If prParams.$cols.$findname('URLParams')     ;; That's our special column that we use to indicate that we've been called via the Push Notifications system
	Calculate vsParams as prParams.URLParams
	Do OJSON.$jsontolistorrow(vsParams,vsKey) Returns vlParams
	Calculate trowParams as vlParams     ;; Copy to trowParams, so we can use these once we've logged in successfully.
End If

In the documentation ftp://omnis.net/Wrappers/v210/PushNotifications.pdf, it talks about how you can send a notification to a device, but it doesn't say how you get the Device's hardware ID.  This is the bit that had me stumped for a while.  Then I realised that I had that figured out for a previous project - you can get the Device ID from the wrapper - it's one of the parameters that comes in from the connection with the device.  In the $construct of the remote task I have this snippet:

If pParams.$cols.$findname('DeviceId')
	Calculate tsDeviceID as pParams.DeviceId     ;; Remember the device ID for later on
End If

And later on, when the user has logged in I can link the user ID to the device.  In my main desktop app, I can send notices to users, so I just do the lookup for the user, get the hardware ID/IDs and then create my notification:

Do $root.$pushnotifycommand('sendnotification',vlDeviceIDs,vlNotificationPayload,vlDataPayload,vlExtraParams)     ;; Could also include AppGroup, ResultsHandler, Identifier....

When the device receives a notification, the user taps on the notice, the push notification system has a way of passing data to Omnis - it's embedded in the Data Payload of the sendnotify command.  For us, we make it simple - the Data Payload list is a set of key/value pairs, so I have a set that looks like this:

PushNotify=1
FormName=<the remote form to switch to>
RecordID=the record we want to display.

In the main form, if we receive a URLParams, we look for the PushNotify key/value pair, and if it exists jump to the nominated form and load the nominated record.

It's lots of little bits, but together it's really cool!

Regards,
Paul.



> On 8 Jun 2018, at 6:40 pm, Gavin Foster <omnislist at dataweaver.com> wrote:
> 
> Hi Paul,
> 
> I’ve implemented them successfully.
> 
> There are a couple of caution notices I’d put out:
> 
> a) You have to load for every form:
> If you load a remote form and instantiate a push connection, then $changeform, you have to instantiate a new push connection for the new form.
> 
> b) Time taken to load:
> When I set up the above, I was instantiating a push connection in every $construct. Then I implemented a ‘straight through’ process where the user might launch one form but depending on some URL parameters, the form might automatically change to another, then another. This caused 3 push connections to be loaded. When I ensured that only one connection was loaded on the final form, the load process was quicker.
> 
> c) Loading too many of them/Cleaning up:
> Like I say, you have to load a push connection for every form that is going to use them, but you don’t want to do so unnecessarily as it might slow your $construct down. Under the hood, these are ajax connections being instantiated and they should probably be used judiciously and cleaned up when no longer needed. I suspect they can be left lying around when a remote form is destroyed.  I am currently investigating an issue with my application that might be a memory leak and might be related to the push connections I’ve created.
> In short, I suspect that it would be wise to use $cinst.$clientcommand(“closepush”,row()) before changing forms with $changeform.
> 
> They can be used for some very interesting purposes. Good luck.
> 
> Rgds,
> Gav
> 
>> On 6 Jun 2018, at 00:55, Paul Mulroney <pmulroney at logicaldevelopments.com.au> wrote:
>> 
>> Hi $all,
>> 
>> I'm trying to implement Push Notifications in our jsClient Android wrapper, and I'm having some problems.  I think I've followed all the instructions, but there seems to be something missing.
>> 
>> Has anyone implemented Push Notifications?  Any gotcha's that I need to be aware of?
>> 
>> Thanks in advance,
>> Paul.


I saw an ad that said "Radio for sale. $1. Volume stuck on full"
I thought "I can't turn that down"! https://www.facebook.com/DadJokeOfTheDay
-- 
Paul W. Mulroney                                            We Don't Do Simple Pty Ltd 
pmulroney at logicaldevelopments.com.au       Trading as Logical Developments
www.logicaldevelopments.com.au                   ACN 161 009 374 
Ph: +61 8 9458 3889                                       86 Coolgardie Street
                                                                         BENTLEY  WA  6102




More information about the omnisdev-en mailing list