About this group

The core value of this group is to bring developers up to speed with BB technology, concentrating on BB10.Exploring efficiency, beauty and power BlackBerry provides to its users by designing Apps that can be used globally and that improves developers life as it improves community life.

Contact Name: Michael Kimathi
E-mail:
  Contact the manager of this GroupSpaces group
Category: Other

News & Announcements

BlackBerry Developer Meet-up September (Built For BlackBerry Revitilized)

  • Saturday, 14th September 2013 at 3:30pm - 8:30pm
    Location: ihub Bishop Magua Building George Padmore Lane Nairobi, Nairobi KE

    Register Here

    • 12 people attended

Built For BlackBerry and Certification

  • Saturday, 3rd August 2013 (all day)
    Location: Ihub 4th Floor Bishop Magua Centre

    Now that everyone is looking forward to build application which qualifies for built for BB We…

    • 45 people attended

TAKE IT TO THE NEXT LEVEL

  • Saturday, 4th May 2013 at 10am - 5:30pm
    Location: IHub Nairobi

    It was amazing to get great ideas hit the floor as we get new developers started as well as…

    • 22 people attended

Previous items

RSS Feed

Messaging Out of the Box

The BBM Enterprise SDK provides a powerful, real-time, and secure messaging framework that can be used for much more than simple peer-to-peer text messaging. Message payloads are fully customizable, allowing an application to share all manner of information amongst groups of users.

Customizable Message Payloads

Each chat message in the BBM Enterprise SDK protocol carries a specific “tag” which can be used to filter messages. Furthermore, the message itself can carry any arbitrary JSON payload, allowing one to communicate all manner of data or meta-data that can be serialized to JSON, in a chat. The data can include anything, such as including base64 encoded binary data, up to a maximum of 70 KB for the message in its entirety (this includes other message properties, the “thumb” for file transfers, etc)

Example: Sharing Location Data

In the Location Sharing example, we take advantage of the BBM Enterprise SDK’s customizable message payload capability to share real-time location updates between chat participants. A custom tag “Location” is defined to identify these application specific data types, and messages are sent with a JSON payload that includes the user’s current location. The application then parses incoming messages, and renders the participant’s location data points on a map.

Send Location Updates to a Chat

To send a location update to a chat, we create a JSON serializable dictionary containing our location data and any other pertinent information. This information is then sent, as a message, to the appropriate chat.

//Construct a dictionary that can be serialize to JSON
NSDictionary *locationData = @{ @"latitude", latitude,
                                @"longitude", longitude }
                                @"userInfo", info }
BBMChatMessageSendMessage *msg = [[BBMChatMessageSendMessage alloc] initWithChatId:chatId tag:@"LocationUpdate"];
//The rawData property can be any dictionary that can serialize to JSON up to a maximum
//size of approximately 70Kb
msg.rawData = locationData;
[[BBMServiceLayer sharedInstance] sendCoreMessage:msg];

Extract Location Updates from a Chat

To handle incoming location specific updates, we create a filtered list of chat messages with the “Location” tag which will be updated automatically for us as new messages arrive.

BBMChatMessageCriteria *locationCriteria = [[BBMChatMessageCriteria alloc] init];
chatMessageCriteria.tag = @"LocationUpdate";
chatMessageCriteria.chatId = chatId; //Where the chatId is the chat we wish to extract the location messages from
NSArray *locationUpdates = [dataModel chatMessageWithCriteria:locationCriteria].observableArray;
for(BBMChatMessage *message in locationUpdates) {
    NSDictionary *locationData = message.rawData;
    NSString *latitude = locationData[@"latitude"]
    NSString *longitude = locationData[@"longitude"]
    NSDictionary *userInfo = locationData[@"userInfo"]
    //Render the location
}

Complete Flexibility

Location data is just one example of a custom message type that can be sent in a chat. The possibilities are endless:

  • A custom message can be inserted into a chat by the initiator whenever a BBM Enterprise audio or video call ends which can then be used to render a call log.
  • An application can observe the user’s calendar and automatically send upcoming meeting notifications in a chat.
  • An application can implement a custom shared whiteboard by sending vector drawing instructions in the message payload

A Note On Reactive Programming

The BBM Enterprise SDK provides a reactive programming framework to facilitate writing User Interfaces that are responsive to changes in the data model. The ObservableMonitor class provides a powerful way of reacting automatically to changes on “observable” properties. By simply wrapping the code that queries for the custom message in a monitor, we can have that code block execute automatically any time the list of messages changes.

self.chatMonitor = [ObservableMonitor monitorActivedWithName:@"locationMessageMonitor" block:^{
    NSArray *locationUpdates = [dataModel chatMessageWithCriteria:locationCriteria].observableArray;
    //The following code will now be run whenever objects are added to the list. The
    //property "observableArray" will trigger this block to run whenever it changes.
}];

In addition to ObservableMonitor, you can add an explicit listener to any LiveList or LiveMap that will run blocks of code on specific operations on that list or use built-in mechanisms such as KVO.

Next Steps

You can download the BBM Enterprise SDK and try the Location Sharing example mentioned above by visiting the BBM Enterprise SDK developer portal.


on 21st September
Receiving Push Requests in a BlackBerry Dynamics Application

In a previous blog post – Push and BlackBerry Dynamics – Stephen Leonard explained the various options you can use to push data to a BlackBerry Dynamics (BD) app. If you aren’t sure which technology to use to send your push, read through that article first. This blog post will explain some of the nuances of receiving push messages in a BD application, regardless of which push technology you use.

Receiving a Push Message

When a non-BlackBerry Dynamics application receives a push, the operating system notifies the application and delivers the payload for the application to process. The same scenario also applies to BD applications when they are running. But recall when a user starts a BD application, they need to unlock the application using a password (or other method). Unlocking the application allows the encrypted application container to be utilized. So, what happens when a push arrives and the container is locked?

Receiving a Push Message in a Locked Container

If a push message arrives while the container is locked, the application is unable to be started by the OS and will be unable to act on the push message until the user unlocks the container. This means the user must perform an action to unlock the container – such as entering their password – before the application can act on the push message. For many applications, this delay may not impact the user experience. The application can process the push message when the user unlocks it and display the data to the user. But what about applications that use push to receive timely updates that need to be processed immediately? These applications may require the BlackBerry UEM administrator to select the “No Password” policy for the app.

Receiving a Push Message with the “No Password” Policy

Version 3.2 of the BlackBerry Dynamics SDK introduced a new feature called No Password Policy.  This removes the requirement that the user set a password or other mechanism such as fingerprint scan to unlock an application. The No Password Policy can be assigned on a per application basis, so one application installed by a user may have this policy while another application on the same user’s device does not. Since no user action is required to start the application, the OS can start the app, allowing the app to process the push message when it arrives. In this scenario, the application will behave like non BD applications that receive push messages.

Account for Both Scenarios

The user experience of your BlackBerry Dynamics application should take both scenarios into account. You may recommend administrators that deploy your applications use the No Password Policy. However, some may choose not to, so you’ll need to be ready to handle the scenario where your application cannot process the push message as soon as it arrives.


on 14th September
New to the BBM Enterprise SDK? Here are Answers to Some FAQs

Welcome to the BBM Enterprise SDK! Whether you’re a seasoned veteran or never worked with Messaging Software Development Kits, I’ll be answering the most Frequently Asked Questions!

The Security

How are Messages Stored?

The BBME (BlackBerry Messenger Enterprise) Server stores encrypted messages, conversations and threads, and all message content is encrypted and decrypted by the clients only.  Messages on the clients are stored encrypted, and they only leave the clients encrypted. While in transit or stored on the server, they are still encrypted, and the server has no access to the keys or method to decrypt the messages.

Where are Users’ Public and Private Keys Stored?

In our Rich Chat sample, we store the user’s keys on the Firebase console attached to the user’s REG ID and Google Account, which is queried at login, allowing for data decryption.

How does BBME Secure the chat, and how is the data in motion protected?

The BBME Chats are encrypted by the client and stored encrypted on the BBME infrastructure. Only the metadata on the payloads is visible, so that they can be routed though the BlackBerry Network Operations Center (NOC) to their respective BBME server and  designated clients. Note:  encrypted payloads are stored in a database which itself is encrypted on the BBME Servers.

The Upshot:

How secure is the BBME SDK? We follow three security principles

  • Messages are digitally signed, so you’re assured of who sends each message in your app
  • Messages are encrypted, so you’re assured that only the intended recipient can read the message
  • Messages are subjected to integrity signature checks, so you’re assured the message isn’t modified in transit.

If you are interested in the cryptography that powers security in the BBM Enterprise SDK, check out this white paper on it.

The Users

You have users and you have keys –  they both have to be stored somewhere. Appropriately, in our RichChat sample, we use Firebase, so you might ask:

What is Firebase, and do I have to use it?

Firebase is a cloud platform, including database and push notifications, for application development on iOS, Android and Web. You DO NOT have to use Firebase with the BBME SDK. We only use it in our samples for simplicity’s sake.

You can use any identity, storage, and authentication provider of your choice to store contact, key or chat details. They just need to have a token Info endpoint for token introspection and a user Info endpoint for user detail capture.

Do I have to use Google as an authenticator?

No, you do not. We only use Google as an authenticator in our Rich Chat samples (iOS / Android) for consistency and simplicity. You can leverage any identity provider you like such as Facebook, Twitter, GitHub or your own custom internal system (as long as it conforms to the OpenID Connect and OAuth standard).

The Upshot:

Our sample Rich Chat utilizes Firebase with Google as an authentication system. They are used because they have quick setup times for learning purposes. You can use Firebase and Google if you’d like, but you can use any provider that conforms to the OpenID Connect and OAuth standard.

Here’s a helpful reference regarding these identity management platforms and protocols.

Other FAQs

What is a ‘Domain’?

In the case of BBME, the domain is a string that identifies a realm of messaging which you can control. The domain is also the medium through which all your applications (iOS, Android) will communicate securely. You create this domain here.

What are Token Info and User Info Endpoints?

These endpoint URLs are used for token introspection, a point on an authorization server used to authorize and verify tokens against their distributer. The User Info Endpoint URL can be leveraged to return a payload including user details.

Can I update my Domain?

Yes, you absolutely can! Once a domain is created, you can repurpose and update it to your heart’s content. Go here to do this.

You can always go back and update your domain to add features like Push Notifications, multiple Client ID support and much more. If you are creating it for the first time you may like to leave it bare bones and come back as you get features configured.

What is a ‘RegID’, and how does it work?

A unique hash identifier for individually registered users.

No two users share a REG ID. As shown in the Rich Chat samples, when the user logs in with their Google account, it pulls in their relevant data, which includes their decryption keys and REG ID. This REG ID is used to uniquely identify users under your domain when connecting to the BBME Servers.

Can I Setup Push Notifications through BBME SDK?

Yes, you can. At the bottom of the domain creation or update form there are both ‘Google Push Type’ and ‘Apple Push Type’ fields.

Why am I Getting the Setup State of ‘Ongoing’ in RichChat?

One of the most common pitfalls when trying to run the RichChat samples is misconfiguring your Google Sign-In information within your domain. If you have configured the RichChat samples and received the ongoing connect status label, you have misconfigured your connection variables.

Here’s an example of me problem solving this on iOS:

  1. I received an ‘ongoing’ status for my Setup State. I also did not receive a RegID, as the field is empty. What can I infer? This is a sign that the BBME servers are not able to authenticate the users with the identity provider you configured. I’ve likely misconfigured my Client ID’s, or another field during setup.
  2. I then realized that I had previously changed my domain’s client ID for another application. That means the current client ID that I am trying to establish the connection with does not match the other client ID in my domain. Furthermore, the client ID currently configured with the Domain is not the same as the one I initiated the connection with.
  3. I went to the ‘Update Domain’ form and saw that the client ID field contained a client ID that doesn’t match the one in my GoogleService-Info.plist.
  4. After updating the domain with the correct client ID from the GoogleService-Info.plist the connection was a success and I was delegated a REG ID.

The Upshot:

  • Look at every place you have a CLIENT ID, double check that they are correct.
    • Since there is more Client ID work on Android, it is more than likely that you have misconfigured them.
  • Check the configuration of your Domain, and what Client ID you placed there (to see your domain’s variables, ‘update’ it without changing anything).
  • Check your identity provider to see if valid tokens are being returned before you send them off to BBME Servers for Token and UserInfo authentication.

With a heightened understanding of the SDK’s jargon and technologies, you can apply your development skills with confidence towards your BBM Enterprise application. Download the SDK here. Happy coding!


on 12th September

Create a site like this for your own group.
Take a Tour or Sign Up

Members

Events

October 2017
 
« »
Mon Tue Wed Thu Fri Sat Sun
25 26 27 28 29 30 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

BlackBerry Enterprise Developers Kenya

Powered by GroupSpaces · Terms · Privacy Policy · Cookie Use · Create Your Own Group