O$: Push Notifications anyone?
brb at appimatic.com
Sun Jun 10 12:09:39 EDT 2018
i find it interesting you are able to retrieve a persistently unique
hardware device ID using this process.
it's been my understanding that iOS (at a minimum) and other mobile / etc
operating system platforms were moving away from letting developers
uniquely identify mobile device hardware in web / mobile applications.
it makes me wonder if the unique hardware device ID is only persistent
during a session, or cookie, etc?
also makes me wonder how long a developer can depend on this ID being
From: Paul Mulroney <pmulroney at logicaldevelopments.com.au>
> Subject: Re: O$: Push Notifications anyone?
> 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
> 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
> 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
> 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:
> 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!
> > On 8 Jun 2018, at 6:40 pm, Gavin Foster <omnislist at dataweaver.com>
> > 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@
> 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/
> 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
> BENTLEY WA 6102
More information about the omnisdev-en