O$: Push Notifications anyone?

Bryan Brodie brb at appimatic.com
Sun Jun 10 12:09:39 EDT 2018


hi paul,

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
available...

thoughts?

bryan brodie

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
> 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@
> 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