Erik,
No there are no warnings or any any errors. Errors and warnings we can
work with, this simply didn’t fire.
At the moment we have got around the issue with a different plugin. We
didn’t change the architecture at all and the different plugin works.
At the time we thought it was a timing or race condition and we still
think that.
We have this on the backburner as we need to get a release out. We’ll
try and revisit it later but it won’t be for a few weeks as Twitter
interfaces, GPS maps and route matching is on the critical path :)
Thanks
Rob
On 13 Jan 2016, at 9:43, Erik Jan de Wit wrote:
> Seems to be an cordova issue, when loading a lot of javascript makes
> the
> plugin skip init, are there warnings in the log about this?
>
> On Sun, Dec 20, 2015 at 8:52 PM, Rob Willett
> <rob.aerogear@robertwillett.com
>> wrote:
>
>> Dear all,
>>
>> We *think* we can now reproduce the problem. Clearly writing the last
>> e-mail has focussed our attention :)
>>
>> Summary.
>>
>> We have a simple Ionic app that would call the Aerogear notification
>> handler when notifications were receive in the foreground and when
>> the app
>> was in the background. The Aerogear notification handler would
>> sometimes be
>> called and sometimes NOT be called when a notification was received
>> when
>> the app was not started. See our long previous e-mails detailing the
>> problem.
>>
>> We think we can now reproduce the problem as follows:
>>
>> 1.
>>
>> Kill the app.
>> 2.
>>
>> Send a notification down to the app.
>> 3.
>>
>> It appears in the iOS notification drawer
>> 4.
>>
>> Click on the notification. if the Aerogear handler has worked then go
>> to 1 and repeat. We want a failure :)
>> 5.
>>
>> If the Aerogear handler is NOT called, then put the app into the
>> background using the Home button and then click on the app icon to
>> resume.
>> 6.
>> ------------------------------>>
>> The notification is now processed by the Aerogear handler. We can now
>> see it.
>>
>> We are at a loss to explain this, we found it by accident, but we
>> think it
>> shows some sort of timing issue somewhere because if we pull out the
>> various Javascript files the Aerogear plugin seems to work
>> consistently at
>> startup. We have checked and checked the JavaScript files and cannot
>> see
>> any error with them at all at load time.
>>
>> All suggestions welcome now.
>>
>> Rob
>>
>> On 20 Dec 2015, at 19:26, Rob Willett wrote:
>>
>> Erik, Sebastien,
>>
>> We’ve spent a significant part of the weekend looking into this
>> issue and
>> we have still not got to the bottom of it.
>>
>> We have built a very simple Ionic test app that works in isolation.
>> We
>> have used the default Ionic tabs at
>>
>> http://ionicframework.com/getting-started/
>>
>> We then add in our Javascript files as <script> entries in the
>> index.html
>> file (shown for example)
>>
>> <script src="js/polygon.js"></script>
>> <script src="js/urls.js"></script>
>> <script src="js/utilities.js"></script>
>>
>> <script src="js/moment.js"></script>
>> <script src="js/perimeter.js"></script>
>> <script src="js/leaflet.markercluster-src.js"></script>
>> <script src="js/cycle.js"></script>
>> <script src="js/clipper.js"></script>
>> <script src="js/easy_button.js"></script>
>> <script src="js/graham_scan.js"></script>
>> <script src="js/sha.js"></script>
>> <script src="js/r-tree.js"></script>
>> <script src="js/angular-leaflet-directive.min.js"></script>
>> <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
>> <script src="pouchdb/pouchdb-5.1.0.min.js"></script>
>>
>> We do NOT call any functions within any of these files, indeed we
>> make no
>> reference to these files beyond including them in the index.html
>> file. Our
>> dummy html templates make no reference to them. We simply load the
>> javascript files in. We get no errors from including the files. We
>> have
>> used the controllers and services as provided by the dummy sample
>> Ionic app.
>>
>> If we then send foreground notifications, the notifications are
>> always
>> handled by the Aerogear notification handler.
>>
>> If we send notifications to the app when it is in the background, the
>> notifications are always handled by the Aerogear notification
>> handler.
>>
>> If we kill by swiping up the app, we get the notifications but when
>> we
>> click on the notification from the main IOS screen it is arbitrary as
>> to
>> whether the notification is handled by the Aerogear handler when the
>> app
>> starts up. Sometimes the handler is called, but once the handler is
>> not
>> called, the Aerogear notification handler never appears to be called
>> again.
>> If we reinstall the app it sometimes works again and sometimes it
>> fails.
>>
>> We can reinstall the app and the Aerogear notification handler might
>> be
>> called or it might not. We just ran the app with 20 tests to the app,
>> each
>> time killing the app and then sending down a a notification and it
>> started
>> the Aerogear notification handler each time. We then reinstall the
>> app
>> again, no changes in the code and it simply doesn’t process any
>> notification when the app is closed. The notification turns up, but
>> no
>> event is called to the Aerogear event handler.
>>
>> Given that we are getting arbitrary results from the same codebase,
>> clearly something is remiss. Sometimes it works and sometimes it
>> doesn’t.
>> There is no logic that we can see. We’ve closed down Xcode after
>> installing, we’ve started and stopped our sample app a few times to
>> try and
>> make sure its closed down, ew are sending exactly the same payload
>> each
>> time.
>>
>> We feel that there is some sort of timing or race condition, or if
>> this
>> was a piece of C code, that we are overwriting somewhere we
>> shouldn’t be.
>> It has that sort of feeling of a pointer going bad but we cannot see
>> where
>> the issue is at all. The fact that we get different results from
>> doing the
>> same install is very worrying but we can’t say whether its the
>> Aerogear
>> plugin, Ionic or our code.
>>
>> Thanks,
>>
>> Rob
>>
>> On 18 Dec 2015, at 17:26, Rob Willett wrote:
>>
>> Erok,
>>
>> We’ve not forgotten the notification issue, we’re still working
>> on it to
>> try and get to the bottom of it. The problem for us is that its not
>> so
>> simple to cut code out and try and reduce the problem down. Our code
>> is
>> quite interlinked, for good or for worse.
>>
>> We’ve added some simple sound debugging to the Objective C source
>> for the
>> Aerogear plugin. This means that we can hear where things are when
>> the
>> plugin starts up from a cold start after receiving a notification.
>> This
>> works quite well.
>>
>> We initially added a beep to here
>>
>> - (void)notificationReceived {
>> NSLog(@"Notification received");
>>
>> AudioServicesPlaySystemSound(1005);
>>
>>
>> if (notificationMessage && self.callbackId) {
>>
>> and this works whenever we get a notification in the foreground and
>> when
>> the app is in the background. We then started tracing backwards in
>> the
>> source code to see what called notificationReceived
>>
>> We can see it here
>>
>> - (void)register:(CDVInvokedUrlCommand *)command; {
>> NSLog(@"register");
>> self.callbackId = command.callbackId;
>>
>> AudioServicesPlaySystemSound(1007);
>>
>> isInline = NO;
>>
>> [self.commandDelegate runInBackground:^{
>> NSMutableDictionary *options = [self parseOptions:command];
>> [self saveConfig:options];
>>
>> // when running under iOS 8 we will use the new API for APNS
>> registration
>> #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
>> if ([[UIApplication sharedApplication]
>> respondsToSelector:@selector(registerUserNotificationSettings:)]) {
>> UIUserNotificationSettings* notificationSettings =
>> [UIUserNotificationSettings
>> settingsForTypes:UIUserNotificationTypeAlert |
>> UIUserNotificationTypeBadge | UIUserNotificationTypeSound
>> categories:nil];
>> [[UIApplication sharedApplication]
>> registerUserNotificationSettings:notificationSettings];
>> [[UIApplication sharedApplication]
>> registerForRemoteNotifications];
>> } else {
>> [[UIApplication sharedApplication]
>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge |
>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>> }
>>
>> #else
>> [[UIApplication sharedApplication]
>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge |
>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>> #endif
>>
>> CDVPluginResult* pluginResult = [CDVPluginResult
>> resultWithStatus:CDVCommandStatus_NO_RESULT];
>> [pluginResult setKeepCallback:@YES];
>> [self.commandDelegate sendPluginResult:pluginResult
>> callbackId:command.callbackId];
>> }];
>>
>> if (notificationMessage) // if there is a pending startup
>> notification
>> {
>> AudioServicesPlaySystemSound(1024);
>>
>> [self notificationReceived]; // go ahead and process it
>> }
>> }
>>
>> So we add some more beeps in to track down whats going on. We add
>> AudioServicesPlaySystemSound(1007) at the beginning of the function
>> and add
>> AudioServicesPlaySystemSound(1024) just before we call the
>> notificationReceived method.
>>
>> We get the first sounds on startup but do NOT get the second set of
>> sounds. It looks like notificationMessage is not being set at
>> application
>> startup.
>>
>> Our problem now is that we are not Objective-C developers so we are
>> struggling to debug much further. So trying to understand how
>> notificationMessage is set and defined as its declared as @synthesis
>> is
>> unclear. We’ll start reading and learning quickly but as this is
>> new for
>> us, so we will be slow.
>>
>> Any suggestions welcomed,
>>
>> Rob
>>
>> On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> What you could try is to debug this in xcode, when the notification
>> is
>> touched it should launch the app and that will in turn call the JS
>> callback. Would be good to see if this code is called 100% of the
>> time.
>>
>> You can put a breakpoint here:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56
>>
>> That code will execute on cold start and here:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102
>>
>> That is where the onNotification callback gets invoked.
>>
>> Hope this helps,
>>
>> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <
>> rob.aerogear@robertwillett.com
>>
>> wrote:
>>
>> Sebastien
>>
>> Yes, we do it at that point, $ionicPlatform.ready. I include the
>> whole of
>> that area of code for reference but we’re not expecting you to
>> debug it for
>> us. Merely to demonstrate its there.
>>
>> At the moment all we want the code to do is put an alert up.
>>
>> .run(function($ionicPlatform , CordovaService) {
>> $ionicPlatform.ready(function() {
>> if (window.StatusBar) {
>> // org.apache.cordova.statusbar required
>> StatusBar.styleDefault();
>> }
>>
>> ConsoleLog('<<< Cordova ready >>>');
>>
>> /* This seems to remove an annoying page flicker on iOS when the
>> keyboard
>> is displayed */
>> cordova.plugins.Keyboard.disableScroll(true);
>>
>> isDeviceReady = true;
>>
>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";
>>
>> var aeroGearPushConfig = {
>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>> ios: {
>> variantID: “XXXXX”,
>> variantSecret: “YYYYYYY”
>> } ,
>> // sendMetricInfo: true,
>> alias: uuid
>> };
>>
>> push.register(function (event) {
>> alert("EVENT = " + JSON.stringify(event));
>>
>> } , function () {
>> if (1)
>> {
>> // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
>> // ConsoleLog("UUID = " + uuid);
>> }
>> } , function () {
>> } , aeroGearPushConfig);
>>
>> We were still loading up another 18,000 lines of code so we need to
>> start
>> pruning that back until we have something that works.
>>
>> Rob
>>
>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:
>>
>> In the ionic app when do you do the registration of UPS ? on the
>> platformReady event ?
>>
>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
>> rob.aerogear@robertwillett.com
>>
>> wrote:
>>
>> Erik,
>>
>> We have built the simplest possible app we can that uses the Aerogear
>> push plugin but using the ionic tabs starter kit.
>>
>> http://ionicframework.com/getting-started/
>>
>> We have taken the code directly from the Cordova simple app that we
>> have
>> got working and put it into the Ionic app.
>>
>> if we follow your tests as below:
>>
>> 1.
>>
>> IOS App in foreground, we send a simple push notification from the
>> Aerogear console - Works OK, We can see the event. Good
>> 2.
>>
>> IOS App in background, we send a simple push notification from the
>> Aerogear console - Works OK, We can see the event. Good
>> 3.
>>
>> IOS App killed, we send a simple push notification from the Aerogear
>>
>> console and some of the time when we click on the notification in the
>> notification drawer we do NOT get the notification handler called.
>> Not
>> so good
>>
>> However it does appear to work most of the time with our minimal
>> Ionic
>> app, but some of the time it fails. We had a run of 1 in 2 failures
>> when
>> we click on the notification. Now we have just done 20 runs in a row,
>> each time killing the app after receiving the notification and not a
>> single failure. Nothing changed.
>>
>> We cannot find any obvious reason for this so we are still
>> investigating.
>>
>> We have reconfigured our main app to work the same way as the minimal
>> app but we are still getting the same issues as before, we can see
>> the
>> notification in the drawer but clicking on it does NOT call the same
>> handler with the same code as the minimal app. We get zero calls to
>> the
>> notification event handler.
>>
>> We are wondering if there is a timing issue somewhere in our code,
>> but
>> we can’t see it. We also wondered if the size of the code we are
>> loading is the cause of a timing issue as well.
>>
>> Is there any way of adding more debugging into the Aerogear push
>> plugin
>> to see if we can track things down that way?
>>
>> Its very frustrating, but thanks for your help to date. It does look
>> like its an interaction with our code, Ionic and the Aerogear plugin.
>> My
>> money is on our code though. We’ll now start pulling working code
>> out
>> of our app until we get back to the minimal app. Only 18,604 lines to
>> go
>> :)
>>
>> Rob
>>
>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> That would be a bug, although I can not reproduce it, to test it this
>> is
>> what I've done to test it:
>> $ > cordova create push-test <my bundle id>
>> $ > cordova platform add ios
>> $ > cordova plugin add aerogear-cordova-push
>>
>> copy paste your js code into www/js/index.js onDeviceReady, changed
>> pushServerUrl and variant info and changed quotes to " (this is your
>> client no doubt) and changed : into ; after console.log("Success")
>>
>> Attach Safari debugger and send a message when the app is in the
>> foreground
>> and get in the console:
>>
>> HandleAeroGearNotification: event =>
>>
>>
>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>
>> I press the home button and send the app to the background send
>> another
>> message and 'touch' the message to launch the app:
>>
>> HandleAeroGearNotification: event =>
>>
>>
>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>
>> The I kill the app by pressing home twice and swiping over the app to
>> remove it send another message and 'touch' it to launch the app. This
>> kills
>> my safari debugger so no way to see the console log, but in this case
>> coldstart should be true. To test this better changed the code to
>> alert
>> instead of console:
>>
>> function HandleAeroGearNotification(event) {
>> alert("HandleAeroGearNotification: event => " + event.coldstart);
>>
>> // Stuff cut for clarity
>> }
>>
>> I send another notification 'touch' it to launch the app and see the
>> alert
>> box display the text:
>>
>> HandleAeroGearNotification: event => true
>>
>> Hope this helps
>>
>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
>> rob.aerogear@robertwillett.com> wrote:
>>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>> 'additionalData' => { 'Disruption_Id' => '107546',
>> 'EpochTime' => '1450125268'
>> },
>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>> 'alias' => [ ‘alias1’ ],
>> 'ttl' => 600
>> };
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>>
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>>
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>> var aeroGearPushConfig = {
>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>> ios: {
>> variantID: “variantid_obscured”,
>> variantSecret: “variant_secret_obscured”
>> } ,
>> android: {
>> senderID: "variantid_obscured" ,
>> variantID: "variant_id_obscured" ,
>> variantSecret: "variant_secret_obscured"
>> } ,
>> sendMetricInfo: true,
>> alias: alias1
>> };
>>
>> function HandleAeroGearNotification(event) {
>> console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>> // Stuff cut for clarity
>> }
>>
>> // Slightly simplified registration event.
>> push.register(HandleAeroGearNotification , function () {
>> console.log(“Success”):
>> } , function () {
>> console.log(“Failure”);
>> } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>> Rob
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>> ------------------------------
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> ------------------------------
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> ------------------------------
>>
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
> Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
_______________________________________________
Aerogear-users mailing list
Aerogear-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users