Push notifications via BES / BIS, BlackBerry

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

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

To record when I registered for push notifications here, I registered using the BIS option. Now that I was actually given a blackberry, they told me that she was using BES (I don’t think this is the root of the problem I’m going to describe ..).

On the device, in the sample application, I placed all the correct settings specified in the received email.

Both of my computers running the tomcat server and my phone are connected to the same Wi-Fi.

I try to connect to the server from the device’s browser, for example https://196.84.32.112:8443/low-level-sample

and the browser opens the page in normal mode, which means that I can connect to my server from a mobile.

Now, when I click the register from the device application example (I tried both BIS / BES settings in the settings), I always get the following error:

Registration request failed. Reason java.io.IOException: Failed to perform network operation [Subscriptions]. Make sure the content provider URL is accessible.

In the log I get:

Incoming URL: my server URL is added with information like username / password / model / connection type, etc. Failed to connect to the network command of the content provider [Subscription], due to the inability to connect to 196.84.32.112:8443 Error "register" of the command with the error: java.io.IOException: network operation [Subscription] failed. Make sure the content provider URL is accessible.

The idea is that I have to register again for new push keys and use the BIS / BES parameter instead of BIS, but here the problem is not with the local server, and not with the RIM server. I already tried to register, and I'm waiting for mail with the new settings.

Also I'm a little confused with the BIS / BES option. I have no idea if my users can enable BIS or BES, and what can I add to my code ?! In the sample application, he asks me to choose between BIS or BES, but when the application is going to production, and I need to programmatically make this choice, what will I choose ?! Or is this choice made only for evaluating / developing the application, but is there another server in production?

+4
source share
2 answers

I think all the right things were said here, but I hope that we can combine some of the answers and wrap this question up.

You didn’t share your code, which complicates the work, but many use the RIM / BlackBerry source provided by PushDemo, where the connection suffix is ​​hardcoded in /pushdemo/com/rim/samples/device/push/PushUtils.java :

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

I also assume this read your other question .

Thus, you hardcoded the transport type of BlackBerry BIBS. BlackBerry supports many different transports , such as BES, BIS, BIBS, or WAP. BIBS Transport will send a request from your device to BlackBerry servers that are located on the Internet. (Note: this part probably confuses the iOS / Android developer, as these platforms do not provide Apple / Google network intermediaries for relaying normal HTTP / S traffic)

Then the request is sent to your server, which is located at:

 196.84.32.112:8443 

I am sure that the TCP / IP endpoint is not accessible from the Internet (I cannot reach it). So why does this fail for you.

You can use 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. These backend servers can reach the endpoint of 196.84.32.112:8443 , so this seems to work for you. But this is because you did not hardcode the transport, as in your push code that uses getConnectionSuffix() . The device’s browser is smart enough to figure out which transport works, and BES works to get to this intranet server.

Hope this explains the confusing part.

Decision

As others have said, the solution is to get your company's IT staff to make the IP address 196.84.32.112 and port 8443 accessible through their firewall. This would allow BlackBerry servers to successfully achieve this.

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

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

If you need really flexible code, I would suggest rewriting this PushUtils.java code because it uses HTTP connection logic up to 5.0. ConnectionFactory on OS 5.0+ makes this easier and more reliable with support for multiple transports ...

To answer the question about user support for multiple vehicles, see this blackberry.com example , in particular the MyConnectionFactory class. It allows you to choose which transport your application is transporting, and which it tries first.

Ultimately, the decision to make your server public or not depends on how it will be used and whether you will have non-corporate Internet clients trying to register on your corporate server.

+3
source

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

When you click "Register device",

  • Tell your web application that the device wants to register. To do this, it will send device information to your web application (the so-called ContentProvider). You are expected to save this information in your database. This step occurs in the push demo's ContentProviderProtocol.performCommand() method.

  • Tell the BB Push server that the device wants to register to receive push notifications from your application. This happens in the BpasProtocol.register() push sdk method.

Step 1 is only necessary if you want to find out who is all registered for push notifications (perhaps if you want to send individual push notifications to each device and not broadcast the message to all registered users). In this case, you probably need other information, such as user settings, etc., to configure push anyway.

Now the error you get is step 1. To successfully proceed to step 1, your device must be able to connect to your web application, which it cannot.

To solve this problem, either you need to make the web application public (and be ready to handle the load), or comment on step 1 from the application, making ContentProviderProtocol.performCommand() return without any action.

PS: The webapp used in step 1 should not be the same as your push initiator. Webapp is simply used to keep track of who is all registered to receive push, and ideally should be located in the cloud on a distributed architecture if you expect a large number of users.

+2
source

All Articles