09-04-2013 06:27 PM
I've got a situation where a BB10 10.2 device (beta 10.2.0.1445) is reporting a 10002 error, which "Indicates an invalid provider application ID." according to https://developer.blackberry.com/native/reference/
That page also says
This result code can occur from any of the following PushService operations: createSession(), createChannel(), destroyChannel() (only if using public/BIS PPG).
Recommended action: When you receive this code, fixing the application ID programmatically and retrying might correct the issue.
The surprising thing is that this app is installed in the work perimeter (yet see note in docs about "only on BIS"), and also it generally works. I'm not sure yet if this issue is intermittent or what, but sometimes it is not responding to pushes (for no apparent reason) and I'm wondering if this is involved.
The equally odd thing is that even when the app reports this error, it can sometimes receive pushes. I have a case where my log shows this:
10:47:59.231 com.AppName.ent.47018175 startup: built 2013-09-02 13:43:02, v22.214.171.124, OS=10.2.0.1445 10:47:59.232 com.AppName.ent.47018175 ****** partition work 10:47:59.241 com.AppName.ent.47018175 connection? True 10:47:59.657 com.AppName.ent.47018175 onCreateSessionCompleted 10002 10:47:59.658 com.AppName.ent.47018175 Push error: InvalidProviderId 10:47:59.665 com.AppName.ent.47018175 onPushReceived 20130904144744-000, len 8192 ack 1 10:47:59.665 com.AppName.ent.47018175 ....
(I suppose that might not be so entirely odd, actually, given that receiving a push involves mainly the invocation framework and not so much the PushService... you need the PushService created only to ack/reject a payload, as far as I can see, if all you're doing is receiving a push.)
The application is always using "" as the application id when it's installed in the work perimeter.
It also has always worked without this error on a 10.1 (full 10.1.0.4633) device, with identical code.
09-05-2013 11:46 AM
The app ID should either be:
1) The port used to send the push (if using legacy push)
2) The app ID set in the push message if using the updated newer push approach
Am I correct that you're leaving it blank?
09-05-2013 12:09 PM
I've definitely been leaving it blank, because that seems to be both the documented approach, and the way it actually works -- at least sometimes. That is, when I've used '' it generally shows in the log something like this:
default 9000 dname: "com.company.AppName.gYABgHfSB.BlahBlah.Q" providerApplicationId: "" default 9000 Connect to personal/consumer agent: false default 9000 perimeter[ 2 ] personal:1 enterprise:2 default 9000 updated enterprise empty providerAppID to dname: "com.company.AppName.gYABgHfSB.BlahBlah.Q"
This is during the PushService() construction.
I think it was mdandrea who said in other threads that passing '' was correct procedure here, when not using BIS.
09-05-2013 01:31 PM
Hmmmm, it may fall back to using the package ID, but I don't think this should be relied upon, it requires the pushing app to know the exact package ID of the receiving app. Using a port or created app ID is the suggested way to go.
09-06-2013 03:57 PM
I checked with our server dev team and it sounds like Matthre D'Andrea steered you in a solid direction. Passing a blank value uses the DNAME of the app, the same value displayed in the BAS, which should still be a perfectly acceptable and usable option.
The 1002 is a bit concerning though. The push APIs haven't changed on the device, and it shouldn't be a BES issue with the 10.1 device is working fine, so something else in the Work Perimeter may be the root cause.
Could you try clearing off all versions of this push app, reboot then re-install and try again? This will at least rule out a few possible causes.