Push Notifications through BES/BIS , BlackBerry

Question

I am trying to use push notifications for OS < 7.X .

I downloaded the sample server / client code. I deployed the client code on my device and the low-level-sampl

Answer 1

I think all the right things have been said here, but I'm hoping we can consolidate some of the answers, and wrap this question up.

You haven't shared your code, which makes things more difficult, but many people use the RIM/BlackBerry provided PushDemo source, where a connection suffix is hardcoded in /pushdemo/com/rim/samples/device/push/PushUtils.java:

private static String getConnectionSuffix() {
    return ";deviceside=false;ConnectionType=mds-public";
}

I'm also guessing this from having read your other question.

By doing this, you've hardcoded the BlackBerry transport type of BIBS. BlackBerry supports many different transports, like BES, BIS, BIBS, or WAP. The BIBS transport will send the request from your device, out to BlackBerry's servers, which are on the internet. (Note: this part is probably confusing to an iOS/Android developer, since those platforms don't provide Apple/Google network intermediaries to relay normal HTTP/S traffic)

Then, the request is relayed to your server, which is at:

196.84.32.112:8443

I'm pretty sure that TCP/IP endpoint is not available from the Internet (I can't reach it). So, that's why it fails for you.

You can take this URL

https://196.84.32.112:8443/low-level-sample

and paste it into your BlackBerry device's browser, and it will work. Your device is configured for BES, which uses your company's internal servers. Those internal servers can reach the 196.84.32.112:8443 endpoint, so it seems to work for you. But, that's because you haven't hardcoded the transport, as you have in the push code that uses getConnectionSuffix(). The device browser is smart enough to figure out a transport that works, and BES works to reach that intranet server.

Hopefully, that explains the confusing part.

Solutions

As others have said, a solution is to get your company's IT people to make IP address 196.84.32.112 and port 8443 accessible through their firewall. That would allow the BlackBerry servers to reach it successfully.

Another solution would be to change the PushUtils.java code to avoid the BIBS transport:

private static String getConnectionSuffix() {
    return ";deviceside=false";
}

If you want really flexible code, then I'd suggest rewriting that PushUtils.java code, because it appears to use the pre-5.0 HTTP connection logic. ConnectionFactory in OS 5.0+ makes this easier, and more robust, when supporting multiple transports ...

To answer your question about supporting users with multiple transports, take a look at this blackberry.com example, specifically the MyConnectionFactory class. It allows you to select which transports your app allows, and which it tries first.

Ultimately, the decision to make your server public or not depends on how it's going to be used, and whether you'll have non-corporate internet clients trying to register with your corporate server.

Answer 2

Let me first explain the registration flow for BB Push Demo:

When you click on Register the device will

1. Inform your web application that the device wants to register. For this it will send the information about the device to your Web Application (the so called ContentProvider). You are expected to store that information in your database. This step happens in the ContentProviderProtocol.performCommand() method of the push demo.

2. Inform the BB Push Server that the device wants to register for receiving push notifications from your application. This happens in the BpasProtocol.register() method of the push sdk.

Step 1 is only necessary if you want to know who all are registered for push notifications (maybe if you want to send individual push notifications to each device and not broadcast the message to all registered users). In that case, you will probably need other information like that user's preferences etc for customizing the push anyway.

Now the error you are getting is from the step 1. For step 1 to succeed, your device should be able to connect to your web app which it is not able to.

To solve this problem, either you have to make your web app publicly accessible (and be ready to handle the load) or comment out the step 1 from the app by making ContentProviderProtocol.performCommand() return without doing anything.

PS: The webapp used in step 1 need not be same as your push initiator. The webapp is simply being used for tracking who all is registered for receiving the push and should ideally be located in the cloud on a distributed architecture if you expect a lot of users.