the completionHandler moved in the else statement

[knight9999]

This PR is very simple.
Calling completionHandler after finishing javascript notification handler for the iOS silent push.

Description

For the iOS silent push, the working flow should be following.
(Supposing the device state is background and the push notification has the property content-available=1)

Obj-C => Receive PushNotification
Obj-C => define safeHandler in which completionHandler is embedded
Obj-C => call JavaScript handler
(start javascript handler)
JavaScript => do something necessary in app
JavaScript => call Obj-C by push.finish
(finish javascript handler)
Obj-C => do completionHandler in safeHandler

Related Issue

Motivation and Context

If the completionHandler is called before starting javascript handler,
calling other Obj-C in javascript handler is paused.
Calling other Obj-c resumes after application state becomes active.

How Has This Been Tested?

Here is sample code,

  push.on('notification', (data) => {
    var additionalData = data["additionalData"];
    if (additionalData["foreground"]==false && additionalData["coldstart"]==false) {
      id = additionalData["notId"] || "handler";

      var pushFinish = function() {
        push.finish( function() {
          console.log("finish success");
        }, function() {
          console.log("finish fail");
        }, id);
      }
      push.setApplicationIconBadgeNumber( function() { console.log("badge success"); pushFinish(); },
                                          function() { console.log("badge failure"); pushFinish(); }, 99);
    } else {
      alert(data);
    }
  });

This handler sets badge number to 99 when background app receives silent push.
Before applying this PR, the badge number becomes 99 after launching app.
After applying this PR, the badge number becomes 99 as soon as receiving push notification.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[macdonst]

It looks good to me and @merrygobyebye gave it a thumbs up as well. Just let @jcesarmobile give it a once over then we can merge it in.

[jcesarmobile]

LGTM.

[macdonst]

Thanks for the PR and reviews everyone.

[lock]

This thread has been automatically locked.