code – BlackBerry Developer Bloghttp://devblog.blackberry.com
Fri, 09 Dec 2016 13:29:11 +0000enhourly1http://wordpress.com/http://1.gravatar.com/blavatar/9ef0a66c09615fa946c4179662398878?s=96&d=http%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.pngcode – BlackBerry Developer Bloghttp://devblog.blackberry.com
Android Install Error Codeshttp://devblog.blackberry.com/2015/03/android-install-error-codes/
http://devblog.blackberry.com/2015/03/android-install-error-codes/#respondThu, 19 Mar 2015 19:53:38 +0000http://devblog.blackberry.com/?p=19385/ Read More]]>The BlackBerry Runtime for Android apps provides a great opportunity for Android developers to expand their install base and support a new ecosystem, with minimal effort or resources. With the recent BlackBerry 10.3.1 software update, Android developers can now target Android 4.3 (API 18/Jelly Bean MR2) in addition to newly supported APIs for NFC, BTLE and BlackBerry Classic track-pad support. When targeting a new mobile ecosystem, or when working with different versions of an app, sometimes release management can prove to be troublesome.

The easiest way to troubleshoot deployment issues for Android apps on BlackBerry 10 is by using the BlackBerry Deploy tool, which is included in the BlackBerry command-line tools for Android apps. All that’s required to setup the SDK on your development machine is to download the archive here from our Android microsite, and extract it to a directory of your choice.

BlackBerry Command-line tools for Android apps

BlackBerry Tools for Android Development SDK

This same SDK also allows you to take advantage of a GUI, or use command-line arguments, to:

Deploy (install) a BAR file to a BlackBerry 10 device, by way of the BlackBerry Deploy Tool

Sign a BAR file with your BlackBerry ID account, with the BlackBerry Signer

With respect to the BlackBerry Deploy tool, after opening it from our SDK directory, we have the ability to input the IP address and password of the device we’re installing the specified BAR file on. If you’re deploying the BAR file over USB, the IP address should be 169.254.0.1 as shown below.

BlackBerry Deploy GUI tool after a successful deployment

However, sometimes an application is unable to be installed. When this happens, the BlackBerry Deploy tool outputs a failure message with an integer error code, which represents a corresponding value and description for the reason of failure. The negative value is a flag that the application which threw the error is an Android app, rather than an app developed natively for BlackBerry 10 using the Cascades or WebWorks SDKs. In order to understand the error code integer we receive, we can cross-reference the AOSP source code here. In particular, the PackageManager.java Class gives us the pertinent info of the error code thrown by our Dalvik instance.

Some of the more common instances of a deployment failure are described below.

Error Code

Value

Description

-4

INSTALL_FAILED_INSUFFICIENT_STORAGE

The device didn’t have enough storage space to install the app.

-12

INSTALL_FAILED_OLDER_SDK

The current SDK version is older than that required by the package.

-25

INSTALL_FAILED_VERSION_DOWNGRADE

The new package has an older version code than the currently installed package.

-102

INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION

The parser encountered an unexpected exception.

-103

INSTALL_PARSE_FAILED_NO_CERTIFICATES

The parser did not find any certificates in the .apk.

-104

INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES

If the parser found inconsistent certificates on the files in the.apk.

Some best practices to help improve the release management portion of your development experience are:

Store your certificates safely, and back them up, to avoid a situation where you’re unable to upgrade an application.

Be diligent with passwords and identities when using multiple certificates across different projects.

You know, working in the Developer Relations team at Research In Motion® (RIM®), you get to get to play around with some fun stuff. Recently, Near Field Communication (NFC) has been exercising my brain cells. Some of you may be familiar with the NFC-related articles and code samples that I’ve co-authored with my co-conspirator, Martin Woolley (@mdwrim), which you can find listed in our NFC Article and Code index.

Now, whenever you mention NFC in a conversation, people invariably think of payments. Using NFC to make secure payments is perhaps the most obvious use case. However, when I think of NFC I tend to think of workflows as well. “Workflows,” you say? What do you mean?

OK, let’s think about it anecdotally. How many times have you had the challenge of transcribing some data from an external source to your handset whilst holding a bag and trying to hold a conversation at the same time? How many times have you tried to share information on your handset with someone else and had to struggle with inputting email addresses whilst doing three other things at the same time? These use cases are examples of Workflows, or Business Processes, that stumble on the point of having to accommodate more “human” interaction than is really necessary. NFC can be used to help streamline simple workflows that involve human interactions on mobile devices and ultimately help achieve efficiencies.

So, having thought about this and how to demonstrate a simple but realistic use case (whilst also having some fun), we came up with the concept of the “Fun Run”.

Suppose you’re taking part in a charity “Fun Run” – not quite a marathon but something shorter for fun. The race organizers have developed a simple mobile application to allow you to register for the event and have placed NFC Tags in the starting and finishing areas. As you start you tap on one of the tags, your race timer is started as well as notifying the organizers that you have begun. When you pass the finish line, simply tap on one of the tags in the Finish area to stop your timer and notify the organizers of your finishing time!

In between the start and finish, there may be Way Points with NFC Reader devices that can be used to register intermediate times as the runner passes these points. Tap the handset to the NFC Reader and receive confirmation that the timing data has been transferred successfully.

OK, maybe it’s not 100% realistic, but as an example it is sufficient to demonstrate how a workflow process that involves having to record start and finish times and tracking progress can be made more efficient using NFC. The key learning point is to understand how integrating NFC technology into your application can be used to achieve efficiencies in similar processes.

The Applications

Let’s take a look at how we implemented this simple example using BlackBerry® 10 and BlackBerry® 7 NFC capable devices. There are really three use cases:

1. Tap your handset against an NFC tag at the start of the race to start your race timer.
2. Tap your handset against NFC readers at intermediate waypoints during the race to transfer your current race timer data to an application that manages the reader.
3. Tap your handset against an NFC tag at the end of the race to stop your race timer.

Acting on External Tag Events

To implement the first and last use case, we decided to provide two NFC tags that had specific NDEF messages as their content. There would be one tag that would start the timer at the start of the race and one tag that would stop the timer at the end of the race.

Why use this data? Well, firstly we choose an NDEF TNF (Type Name Format) for the NDEF Message because it allows us to define custom tag content that won’t clash with standard tag message types such as Smart Poster (“Sp”) or URL (“U”) or Text (“T”). We want to make sure that when one of these tags is presented, our application, and our application alone, is launched to process the tag.

Secondly, we choose a “Type” of “my.rim.com:myrecordtype“. Within the context of an External TNF record the Type can be arbitrary, but in order to prevent clashes with other organizations’ custom tag formats, we use the DNS naming scheme to set the namespace of the tag as “my.rim.com” to establish it as a RIM NDEF message. We further qualify it with a specific sub-type of “myrecordtype” since an organization may define a whole family of custom tag formats for its own use.

So, these settings ensure that these tags will only make sense to our application and not overlap with tags form elsewhere. The “Payload” of the two tags differs in that one has the string “start” and the other has the string “stop” to mark them as ones to be used to start and stop the timers respectively.

In the case of BlackBerry 10, our application registered with the Invocation Framework through the stanza in its “bar-descriptor.xml” file as shown in Figure 1. The “uris” attribute of the “<property … />” tag has been set to the value “ndef://4/my.rim.com/myrecordtype” which a URI format specification of the two tags just described above.

When a “start” or “stop” tag is presented to the handset, then our application is launched if it’s not already running, and the tag contents are handled as shown in Figure 2 — where the payload of “start” or “stop” is extracted once we’ve verified that it’s of the correct type.

So, what we’ve achieved here is the ability to use an external NFC tag to trigger a process in our application. In this case it’s simply the starting and stopping of a timer, but it could be extended quite easily to, say, call a web service and integrate the event into a larger workflow process.

What does this look like in practice? Well, here’s a short video of the BlackBerry 10 application in action:

Virtual Tag Emulation

Let’s get back to the original use cases. To implement the second one, we decided to have the BlackBerry handset emulate a virtual tag and allow the contents of the virtual tag to be read by an external NFC reader.
What format of tag should be emulated by the handset? This is what we chose:

a. That is the time displayed on the handset in:
Hours (hh)
Minutes (mm)
Seconds (ss)

The type of the virtual tag is exactly the same as for the “start” and “stop” physical tags for the very same reasons, except that the payload is a representation of the current race timer value (“hh:mm:ss”) as displayed by the application.

As shown in Figure 5, starting tag emulation in BlackBerry 10 is quite simple. It just involves calling “nfc_start_ndef_tag_emulation()”. In addition we can use BPS (BlackBerry Platform Services) to determine when a read on the virtual tag has been successful, as shown here in Figure 6:

So, what we’ve achieved here is the ability to transmit live information from an application in the BlackBerry handset in real time to an external application via an NFC reader. The external application simply displays the time displayed by the BlackBerry application, but it could easily be extended to integrate with some larger workflow process.

Take a look at the video here for a demonstration of this on BlackBerry 10:

If you’re interested, the virtual tag emulation functionality was tested using an NFC Reader attached to a PC controlled by a Python application using the “PyScard” (Python for Smart Cards) library available from SourceForge.net. (Python and Ruby are my favorite programming languages!)

The two versions of our NFC-enabled “Fun Run” applications are available with full source code from our GitHub repositories here:

Just in closing, it’s worth making one or two comments about the relative ease of developing applications to the same set of end user specifications in BlackBerry 10 Cascades™ versus BlackBerry 7 Java. I’ve been developing code in C/C++ for more years than I care to remember and for a shorter time in Java (but still since the language first saw the light of day), so I feel I’m qualified to make comparisons. I’ll be honest: I’ve found it much easier to develop applications using C/C++ and Cascades. The user interface elements are particularly easy to use, and I’ve found it possible to get a user interface up and running in Cascades much faster than I would have done in Java. It’s much easier to modify and extend since Cascades elements map directly to Qt/Cascades C++ classes and the SIGNAL() / SLOT() model makes it so easy to connect events to handlers.

After a bunch of hard work, bbUI version 0.9.4 is finally here. The focus in this release has really been around bug fixes, optimizations and additional JavaScript® interfaces. The previous versions of bbUI have been VERY declarative and haven’t allowed for much manipulation after the fact via JavaScript. This release takes a step in the right direction to allow you to create more dynamic user interfaces via JavaScript. While there are some improvements in this department with v0.9.4, we’re not finished yet and have much more planned for v0.9.5.

One of the best things I’ve seen lately is the number of people participating in the project. It’s absolutely fantastic to see members of the community grab items from the roadmap, implement them and send them back as pull requests. These pull requests are full on feature creation as well as bug fixes. A gigantic THANK YOU goes out to all those who are helping to improve bbUI!

Be sure to check out the full change log for this release to know what kind of adjustments you may need to make to your JavaScript in order to run v0.9.4, and check out the closed issues for details on bugs that have been fixed and features that have been added. The v0.9.4 JavaScript changes are fairly minor and are meant to make your life easier as we continue to move forward.

If you were calling bb.scroller.refresh() you will want to change your code to “if (bb.scroller) bb.scroller.refresh();”

More to Come

We’ve now created an additional v0.9.5 milestone for bbUI that contains additional BlackBerry 10 styling improvements, but also includes more JavaScript interfaces for dynamic screen creation and manipulation. If you’re interested in following the bbUI.js changes as they go, feel free to follow me on Twitter®.

]]>http://devblog.blackberry.com/2012/10/bbui-js-update/feed/0timneil1TITLE_IMAGEHello OggVorbishttp://devblog.blackberry.com/2012/08/hello-oggvorbis/
http://devblog.blackberry.com/2012/08/hello-oggvorbis/#respondTue, 07 Aug 2012 16:48:39 +0000http://devblog.blackberry.com/?p=10567]]>The audio portion of a native game or app has traditionally been a land of “#ifdefs” and low-level platform specific code. This is especially true when targeting different devices supporting differing audio formats.

OpenAL, from Khronos, is designed to solve that exact problem. It is an open source, cross platform 3D Sound API for use in games and multimedia apps. Thankfully, OpenAL 1.1 is readily available on BlackBerry® 10. It is supported on multiple platforms and due to its API looking strikingly similar its 3D graphics cousin OpenGL API, it has proved to be very easy to learn and integrate. OpenAL, however, does not directly support compressed audio formats out-of-the-box. This could result in games having bigger audio files and hence a bigger memory footprint.

Enter OggVorbis.

There are several compressed audio formats and associated libraries available and I recommend OggVorbis for the following reasons:

This blog post uses a sample project to show how to set up and use OpenAL and OggVorbis with the BlackBerry 10 Native SDK. The sample is forked off the famous “cascades cowbell app” and minor modifications have been made to show how to load and play .ogg and .wav files. Assuming you are already familiar with the BlackBerry 10 Native SDK, here are the main steps to follow:

Convert your assets

Add the OggVorbis library to your project

OggVorbis is already ported and available at the BlackBerry Github community, so go ahead download the source code() and compile it using BlackBerry 10 Native SDK. Once compiled, add the library (example: libvorbis.a) and the headers into a folder inside the cowbell application project directory. Let’s call it “external-lib”. Now modify the cowbell.pro project to include the header and library files.

Calculate the unpacked audio file size

In order to load the uncompressed data into an OpenAL buffer, we need to store the audio data in a temporary buffer. The size of the audio buffer can be found using a simple formula: (number of channels) * (number of samples) * (number of bytes per packet)

The number of channels info can be retrieved into vorbis_info using the ov_info function. The number of samples can be found using the ov_pcm_total function.

We’ve been receiving lots of great feedback on the bbUI framework as we’ve been continuing the BlackBerry® 10 Jam World Tour. Thank you all for your constant collaboration and continuous feedback! We even had a chance to receive a feature request during the morning of the Toronto stop and implement a new scrolling panel feature by the end of that same day

This release looks to further close the gap between what’s being offered in the Cascades™ UI framework and what’s available in bbUI.

Be sure to check out the full change log for this release to know what kind of adjustments you may need to make to your markup in order to run v0.9.3 and check out the closed issues for bugs that have been fixed. The v0.9.3 markup changes are fairly minor and are meant to make your life easier as we continue move forward.

Changes to your code:

I mentioned that there were a few changes that were made that will affect your application markup so let’s talk about those.

Default control color for BlackBerry 10 has been changed from dark to light. You should explicitly state your color choice in the bb.init() function to suit your application’s style

The progress bar’s pause() function has been removed and replaced with setState() to allow for normal, warning and error states

You now must explicitly state which actions/tabs on the Action Bar are to show on the overflow menus

Arrow List control has now been merged as a feature of the image list. You will have to change your existing arrow list markup to image list markup with the proper style attribute

By default a screen’s background color is now white unless you explicitly set its style. This was needed in order to implement the sliding transitions

BlackBerry 10 buttons no longer stretch by default. To stretch you need to set the data-bb-style=”stretch” attribute

Default font has been changed from Slate to Slate Pro for BlackBerry 10

More to Come:

We’ve now created an additional v0.9.4 milestone for bbUI that contains additional BlackBerry 10 controls but also includes more JavaScript interfaces for dynamic screen creation and manipulation. It also contains some updates around Tablet user experience. If you’re interested in following the bbUI.js changes as they go, feel free to follow me on Twitter®.

Okay…now that we’ve covered what’s new and what’s changed, I think it’s time for some of that good old eye candy

Beta 2 of the BlackBerry® 10 SDK for Adobe® AIR® now has support for participating in the BlackBerry 10 Invoke Framework. You can find all of the APIs in the QNXDevice.ane and they are all documented.

Invoking a Application

By leveraging the Invoke API, you can invoke virtually any other application on the BlackBerry® smartphone through some simple API call, where you’ll set a parameter for the app you want to invoke and then pass in any parameters that application is expecting. A typical example would be that your application can invoke the BlackBerry® Maps application when it comes across an address. InvokeManager.invoke() will invoke an application.

When the application has been successfully invoked, an InvokeEvent.INVOKE_TARGET event will be dispatched. If there was an error invoking the target, an ErrorEvent.ERROR event will be dispatched. Please refer to the following Knowledge Base article for details on some known issues which will be addressed in an upcoming patch.

Invoking a Viewer

InvokeManager.invokeViewer() will invoke a viewer. A Viewer class is returned and is used to communicate with the viewer.

Let’s say you have an image viewer application and you want to invoke it from the main application you’re working on. In the main application, you want to pass the image file that the imager viewer app will open when invoked.

Below is a sample of how you can invoke a viewer and wait for it to be created. This example assumes that you have created the viewerRequest object with the correct data for your viewer.

Making your Application an Invoke Handler

If you are developing an application that can be invoked by another application, you will want to add a listener for the invoke event at the very start of your application. These should be the first lines of your application.
Once you have received the invoke event, you can check the startup mode and get the data that you were invoked with.
Below is a sample of how you would accomplish this:

Query a list of targets

You can also query a list of targets or viewers on the device by calling the InvokeManager.queryTargets() method. At some point in the future, this will make a pop-up list in your application that will allow users to select items from the list. For now, it returns the results and it is up to you to use those values in your invoke() and invokeViewer() calls.

InvokeEvent

No matter how your application is started, you will receive an InvokeEvent dispatched by the InvokeManager. In order to determine how your app was started, you can check the InvokeManager.startupMode in your InvokeEvent handler. So, your application would look something like the following, assuming that your application can be launched as a target and a viewer:

Closing a Viewer

When an application wishes to close a viewer that it has created, it can simply call the Viewer.dispose() method. This will cause the viewer to be removed immediately.

A viewer can request to be closed by the application and should never actually attempt to close itself directly. Viewers can call the InvokeManager.requestViewerClose() method. This will send a message to the application requesting that it be closed. The Viewer instance in the application will dispatch a ViewerEvent.VIEWER_CLOSE_REQUEST event. When application receives this event, it should call the dispose() method on the viewer to close it. The reason this doesn’t happen automatically is so that applications can transition viewers out before removing them. We may make this a bit more automated in the future, and we’ll let you know when this happens.

Viewer message relay

Viewers can send data to applications using the InvokeManager.viewerSendMessage() method. The Viewer instance will then dispatch ViewerEvent.VIEWER_MESSAGE events with the message and data properties set to what was passed into the viewerSendMessage(). Here is an example of how you would use this:

In today’s post, I’ll talk about property aliases and why they’ll be your friend when creating custom components in QML. I’ll give you an introduction to the topic by creating a Header component, which consists of a Label and a Divider wrapped inside a Container.

I assume that you already know how to create custom components in QML. Basically you create a new file and name it to whatever the name of your component is, for example ‘Header.qml’. So say we have a file ‘Header.qml’ with the following content:

To create a Header instance from another QML file, we simply write the following lines:

...
Header {
}
...

Looks good, but I assume that we also want to set the title to something more appropriate for the context where the header is to be used. Because we don’t have direct access to the Label’s text property from outside the Header component (you can only access top level properties), we need to add a new property to the Container in the Header component:

The Label’s text property binds to the newly added titleText property. Now we can specify a title by setting the titleText property:

Header {
titleText: “My Header”
}

Looks nice and works great, but I’m still not satisfied. I had to introduce a new property just to be able to specify a title text. What I actually want is to expose the Label’s text property to users of the Header component. Fortunately there’s a solution for this, and the name is property alias:

Much better. We got rid of the titleText property by simply making it an alias to the titleLabel’s text property instead. Even the instance of the Label can be exposed as an alias, which gives you access to all of the Label’s properties, if that’s what you need:

]]>http://devblog.blackberry.com/2012/07/qml-tip-property-aliases/feed/0Alex K.Be Social – Integrate your apps with Facebook and Twitterhttp://devblog.blackberry.com/2012/06/integrate-apps-with-social/
http://devblog.blackberry.com/2012/06/integrate-apps-with-social/#respondWed, 06 Jun 2012 13:33:03 +0000http://devblog.blackberry.com/?p=9669]]>One of the unsung heroes of BlackBerry® 7 Java SDK is the Send Command Framework. Although the name doesn’t say much, this API lets you seamlessly integrate with existing apps on the device to share data. Thankfully the native Facebook® and Twitter® apps are two of many!

So this is it folks — no more hair-pulling to figure out how to talk to social networks directly. There are already apps for them, so let’s learn how to leverage those apps from ours instead of reinventing it.

The first step is to create the data or context we would like to share. This context is simply a JSON object that encapsulates our data. Here is an example:

I intentionally commented out the PATH type data because we cannot use PATH data in a context that also has TEXT or SUBJECT types. But I still wanted to highlight that we can also share a file path (e.g. a photo).

Once we have our data context nicely wrapped up in a JSONObject, we need to create SendCommand objects that point to specific apps with a specific context. So how do we get these SendCommands? Easy peasy — we simply query the Send Command Framework with our context data. Here’s how:

Notice that the 3rd parameter above is a Boolean. If true, the query returns all commands regardless if their associated applications can be opened; if false, it returns only commands whose associated applications can be opened. Ideally we would set it to false; however, in this post we will see how we can get them all and filter them in our own application logic.

Each SendCommand object has an ID that uniquely identifies the target app and the context. Note that the IDs are not documented as there could be so many of them, but it is fairly easy to figure them out by experimentation. Since our target is the Facebook app and the Twitter app, let me save you the work by telling you what their IDs are.

BlackBerry® evangelists met with Android™ developers last week at AnDevCon III in Burlingame, CA to talk about the cool development options of bringing Android apps to the BlackBerry platform, and how to publish them on the BlackBerry App World™ storefront to reach a global audience. The word of how easy the process is started to spread out quickly among conference participants at two full-house events on day one of the conference – the Lightning Talk presented by Larry McDonough, Head of Developer Evangelism Americas at Research In Motion (who talked about bringing existing Android apps to the BlackBerry® PlayBook™ tablet), and at the class taught by Rajeev Mohindra, Director, Handheld App Architecture (about running Android applications on BlackBerry).

More BlackBerry development action was happening at the RIM booth, where developers signed up as vendors to BlackBerry App World and learned from BlackBerry experts how to use some of the tools for BlackBerry Runtime for Android apps to convert their Android “apk” files into BlackBerry-compatible “bar” files. Those developers who completed both these steps became the happy recipients of a free BlackBerry PlayBook tablet on which to continue their development work. That they were all excited to convert their Android apps for the BlackBerry platform is an understatement — not to mention how pleasantly surprised they were to see how easy it was to make their apps work on the BlackBerry PlayBook tablet without having to change any code. The BlackBerry team saw all kinds of interesting apps – ranging from games to educational – all successfully ported to the BlackBerry platform.

To top it all off, a BlackBerry PlayBook tablet was in the mix for the AnDevCon III Winner’s Circle Prize, and was won by Erol Yesin from Navman Wireless. Congratulations to Erol and to all the other developers from whom we are waiting to hear back soon with progress updates.

]]>http://devblog.blackberry.com/2012/05/andevcon-android-blackberry/feed/0veronchiquitaTITLE_IMAGEBringing your BlackBerry PlayBook apps to BlackBerry 10http://devblog.blackberry.com/2012/05/blackberry-playbook-apps-on-blackberry-10/
http://devblog.blackberry.com/2012/05/blackberry-playbook-apps-on-blackberry-10/#respondWed, 09 May 2012 17:32:51 +0000http://devblog.blackberry.com/?p=9160]]>While all the SDKs for BlackBerry® 10 are amazing, our pride and joy is the BlackBerry 10 Native SDK. If you’ve built native apps for the BlackBerry® PlayBook™ tablet, then you’ve used our BlackBerry Native SDK for Tablet OS. The new BlackBerry 10 Native SDK has the same underlying framework as the NDK platform and exposes many new APIs and tooling that will make your development experience even better. If you haven’t had a chance to download and write apps for the BlackBerry PlayBook tablet yet, now is a great time to start building some apps.

One of our priorities is to make sure that apps written with the BlackBerry Native SDK for Tablet OS will transition with minimal hassle to our BlackBerry 10 platform. We don’t want you, our developer community, to have to reinvent the wheel or tweak significant amounts of code. We also want to make sure that our developers are aware of changes coming to the platform that may impact them so they can prepare accordingly. With that in mind, I want to talk about two important upcoming changes to the BlackBerry 10 Native SDK in order to help developers prepare for upcoming releases. The motivation for both changes is to help developers scale their apps from tablets to phones.

The first change has to do with multi-icon support. We want to create a seamless way for developers to port their BlackBerry PlayBook tablet applications to the BlackBerry 10 smartphone. As we support two device screen sizes, applications may need to provide more than one icon size depending on the device they are being installed on. Developers will now be able to specify a list of icons and splash screens per locale and per resolution in the bar descriptor. These would be of various sizes to suit the different target displays. The runtime will then choose the icon and splash screen that matches the given display. We will be maintaining backwards compatibility, so existing apps written for the BlackBerry PlayBook tablet should not have to modify anything. However, if you are moving your app to a BlackBerry 10 device, you will have to specify icons and splash screens with alternate sizes.

The second important change is with respect to orientation. On BlackBerry 10, native applications will not be able to get the width and height values that they need for sizing their windows and determining orientation by querying the ‘WIDTH’ and ‘HEIGHT’ environment variables. If the width is greater than the height, the application will know it is running in landscape mode and vice versa. This behaviour has changed from BlackBerry PlayBook OS 2.0. On BlackBerry PlayBook OS 2.0, an application would query the screen APIs to get its width and height. For applications running on BlackBerry PlayBook OS 2.0, they can continue to rely on this behaviour as this is now going to change. On BlackBerry 10, however, applications are discouraged from querying for their width and height using the screen APIs. The following code snippet illustrates how an app can query for its width and height:

Applications written for BlackBerry 10 should not set the SCREEN_PROPERTY_ROTATION value, as Navigator will set this for the application automatically when it posts its window.

Furthermore, if you were writing native apps on BlackBerry PlayBook OS 2.0, you would have had to write extra logic to rotate your window based on what you read out from the “ORIENTATION” environment variable. The box below shows an example of how orientation was set up in the BlackBerry PlayBook OS 2.0 setup. This code can now be removed, thereby simplifying your setup logic.

When it comes to determining current orientation, applications should always rely on the navigator to present current orientation. You should never use the accelerometer to determine orientation. The navigator will also inform the application when it needs to rotate and will initiate the rotation sequence by sending the application a rotate (PORTRAIT or LANDSCAPE) message. These new “rotate” messages are replacing the “orientation” messages on the current 2.0 Navigator. It is to be noted as well that the old orientation messages used to specify rotation in angles, while rotation will be specified as Landscape or Portrait in the new messages. These new units are much more intuitive in my opinion and map more closely with how we think of orientation on the device.

As a native app developer, there are several things you need to consider:

Continuing to support your application on BlackBerry PlayBook OS 2.0 won’t require any change – things will continue to work as before.

If you are developing a native app only for BlackBerry 10, you should make sure to use the new method of getting width and height parameters from navigator as well as using the new rotate messages.

If you already have an app on BlackBerry PlayBook OS 2.0 and want to move it to BlackBerry 10, you will have some minor changes to make to port your app over. Your code on BlackBerry PlayBook OS 2.0 will not be able to get the width/height parameters via environment variables, so you will continue to use the old methods. On BlackBerry 10, you should use the parameters you receive from navigator for this.

These changes are not drastic, and our hope is that you will be able to migrate from BlackBerry PlayBook OS 2.0 to BlackBerry 10 with minimal fuss. In passing, I should also point out that these changes target developers who are writing applications right on top of our low-level windowing framework, so these changes mainly impact game developers. If you are writing a Cascades™-based application, you should also be abstracted from most of these changes and should consult your Cascades documentation.

I am personally excited about these changes as they will enhance the development capabilities of the BlackBerry 10 Native SDK when it comes to supporting multiple resolutions and orientation. When the time comes for you to start developing or moving your app or game over to the BlackBerry 10 platform, you should definitely consult the developer documentation for more details on these two features and how they will impact your application.

One of the true pleasures of my job is talking with developers. Creative, outspoken, funny, smart, artistic, genuine – they’re just some of the best people in the world to hang with. BlackBerry® 10 Jam was amazing last week. The code demos, AppCircus, the lunches and down time with people at the bar – these were the highlights for me.

As you know, I publish my email address everywhere (alec.saunders@rim.com), and people write to me. Nobex Chief Software Architect Jamie Julius wrote me the following last Friday, and gave me permission to share it with you all:

Hi Alec,

I wanted to thank you personally for such a great BB 10 Jam.

Last November, a letter that I had sent to someone at RIM was forwarded to you. In it I described my feelings after attending DevCon last fall in San Francisco.

Well, things have definitely changed. The difference between that DevCon and this Jam is like night and day.

Over the last three days, in keynotes and in sessions, the messages coming from RIM were very clear. Not only do we now see more clearly where RIM is going, but also what we should be doing as developers. As opposed to a vague range of technologies to be supported, it has now been made more clear which will work best for what.

For Nobex Radio, for example, all the RIM technical representatives made it very clear to me why Cascades is the way for us to go. The list of reasons is long. We never received such a clear message before.

I came away feeling that BB10 is now tangible. And I don’t just mean that I can hold the Dev Alpha device in my hand. I see real API’s! Even if some aren’t ready yet, I see them coming. I know what they will cover. That makes a really big difference. I also have an IDE with which to start writing real code. That makes a big difference too.

Back in November, games were over-emphasized. Not anymore. I think RIM has re-focused its identity. Games should definitely have an important place on BlackBerry smartphones, but not blown out of proportion.

So, a big congratulations to you and your team for doing such a great job putting together BB 10 Jam.

The enormous investment that RIM is making in dev relations has not gone unnoticed.

THANK YOU!

Jamie Julius
Chief Software Architect
Nobex Technologies

Thanks Jamie.

There are still lots of milestones to cross on the road to BlackBerry 10, but last week was a major step forward for RIM and the development community. We hope everyone who came to BlackBerry 10 Jam walked away with the same experience as Jamie, and we’re counting on you all, so let’s go write some code together!

]]>http://devblog.blackberry.com/2012/05/blackberry-10-jam-nobex/feed/0asaund1BlackBerry 10 Jam Super Session, Cypress 3Payment Service SDK v1.8 for BlackBerry Java has been released!http://devblog.blackberry.com/2012/05/payment-service-sdk-new-release/
http://devblog.blackberry.com/2012/05/payment-service-sdk-new-release/#respondMon, 07 May 2012 18:54:49 +0000http://devblog.blackberry.com/?p=8728]]>I am pleased to announce that the Payment Service SDK version 1.8 (“Version 1.8”) is now available for download. This update is specifically for BlackBerry® Java® development and adds three new features:

Asynchronous Retrieval of Purchase History

The DigitalGood Class

Asynchronous Retrieval of Digital Goods Available for Purchase

Asynchronous Retrieval of Purchase History

In the previous Payment Service SDK version 1.5 (Version 1.5), only synchronous retrieval of purchase history was possible. This meant that when retrieval was occurring, the user interface would be unusable – a busy indicator would be displayed. This was acceptable for some situations but it could really impede usability of the application. With Version 1.8, you can now program your application to perform this pull request asynchronously using the following line of code:

The huge benefit here is that it is very easy to retrieve the purchase history of a user in the background without causing any impact to the user interface.

The DigitalGood Class

In Version 1.5, digital goods existed only in the BlackBerry App World™ storefront client. There are no actual classes in the Payment Service SDK to encapsulate what a digital good object actually is. Version 1.8 adds a DigitalGood class to do just this. The new DigitalGood class allows the application to retrieve information about the goods hosted on BlackBerry App World available for purchase by the user, where the Purchase class previously used only provides information about the actual purchase. The big benefit of this class: a developer can add new items to the Vendor Portal without needing to release a new version of their application. This new addition is also greeted with a way to retrieve all available digital goods asynchronously (continued in the next section).

Asynchronous Retrieval of Digital Goods Available for Purchase

The method to retrieve a list of digital goods available for purchase by the user is very similar to that used above to retrieve the PurchaseHistory. First, call the DigitalGoods#get() method passing in your DigitalGoodsListingListener:

This is virtually identical to the PurchaseHistoryListingListener implementation; however, the success() method receives an array of DigitalGood objects as opposed to Purchase.

The above three new features are easy to implement and should help simplify the development logic as well as improve the overall user experience of your application. You can find the new Payment Service SDK version 1.8 available for download here. The download includes full JavaDocs, and additional documentation (developer’s guide, release notes) can be viewed here.

]]>http://devblog.blackberry.com/2012/05/payment-service-sdk-new-release/feed/0gbeukZXing and CppUnit ported for BlackBerry 10http://devblog.blackberry.com/2012/05/zxing-and-cppunit-ported-for-blackberry-10/
http://devblog.blackberry.com/2012/05/zxing-and-cppunit-ported-for-blackberry-10/#respondMon, 07 May 2012 18:32:10 +0000http://devblog.blackberry.com/?p=9295/ Read More]]>Hope your Monday is going great. Here’s a guest post from Clifford Hung (hungc on Github) on two new contributions to the BlackBerry Open Source community.

ZXing (pronounced “zebra crossing”) is an open-source, multi-format 1D/2D barcode image processing library implemented in Java, with ports to other languages. It decodes barcodes on the device without communicating with a server. ZXing currently support these formats:

UPC-A and UPC-E

EAN-8 and EAN-13

Code 39

Code 93

Code 128

ITF

Codabar

RSS-14 (all)

QR Code

Data Matrix

PDF 417 (alpha)

Aztec (beta)

The port of ZXing 2.0 for BlackBerry® 10 devices is available in our ZXing repository at GitHub; note that only the C++ source under zxing/cpp/core was ported. See the README.md for build instructions.

The ZXing unit test suite uses CppUnit, so a port of version 1.12.1 of this C++ unit testing framework was also done for BlackBerry 10 and it is available at the CppUnit repository. Build instructions are listed in the README.md.

]]>http://devblog.blackberry.com/2012/05/zxing-and-cppunit-ported-for-blackberry-10/feed/0eduardopele640px-Equus_grevyi_(aka)The right tool for the right job: Developer microsites get a facelifthttp://devblog.blackberry.com/2012/02/developer-microsites-facelift/
http://devblog.blackberry.com/2012/02/developer-microsites-facelift/#respondFri, 10 Feb 2012 19:58:10 +0000http://devblog.blackberry.com/?p=8423/ Read More]]>

Giddy-up! We just launched new microsites to better serve the BlackBerry® developer community and have given BlackBerry Jam Zone a facelift to make it easy to navigate to the tools you want.

We wanted to re-build the main page to bring you the answers you’re looking for:

How do I make money?

What are the development platform options and which one is right for me?

How do I participate in the community and collaborate with others?

Now new sites have been introduced for Adobe® AIR® and BlackBerry Java. Oh, and a BlackBerry Theme Studio website is on the way as well, so stay tuned…

Bring all of the documentation, samples, tutorials, downloads and API references into one convenient, integrated location

Ensure that the information is presented and organized in a way that makes sense for the community who is using the technology

Keep it simple! We’ve been working with the design groups from TAT to create a streamlined design to get you the information you’re looking for FAST!

These microsites will continually evolve based on your feedback, what’s important to you, and how you approach developing apps. You’ll see lots of improvements to all of our websites as we continue to focus on getting you the information you want, the way you want it. So, don’t be shy. Let us know what you would like to see.

]]>http://devblog.blackberry.com/2012/02/developer-microsites-facelift/feed/0timneil1Open Source and the BlackBerry PlayBook OS Platformhttp://devblog.blackberry.com/2011/10/open-source-playbook-os/
http://devblog.blackberry.com/2011/10/open-source-playbook-os/#respondTue, 18 Oct 2011 16:54:00 +0000http://devblog.blackberry.com/?p=7282]]>Today, Research In Motion® (RIM®) announced the 1.0 release of our Native SDK (NDK) for BlackBerry® PlayBook OS. What does that mean? Native means C/C++, BlackBerry PlayBook OS is our advanced platform for tablets and smartphones based on QNX, and the 1.0 refers to the version of that platform, as exemplified with BlackBerry PlayBook OS v1.0.

The goal of the NDK is to make you, the developer, more productive in creating Native Applications for the BlackBerry PlayBook tablet. To accomplish this, the NDK includes tools: a compiler, a linker, the Eclipse-based QNX’s Momentics IDE, and command line tools as well as samples, documentation, and libraries, and is paired with the Developers/Native micro-site. The micro-site is brand new (we also released Android and HTML 5 micro-sites) and provides information on most common actions, and… it also provides pointers to Open Source Components!

As is the case for BlackBerry® WebWorks™, Open Source is a key part of our native story. We use Open Source licenses, and transparent development, to deliver samples that developers can use to kick-start development, or to learn from in general. The NDK comes with a small (4) set of samples, available under an Open Source license. But the micro-site mentioned above links to a larger and growing set of samples all hosted at our GitHub Organization and ready for you to use, or fork and modify.

We are also porting popular Open Source libraries to complement those that are already included in the BlackBerry PlayBook OS. Libraries already available include physics engines like Bullet Physics and Box2DX, scripting languages like Lua, multimedia libraries like OpenAL and SDL, gaming frameworks like Cocos2DX and general-purpose libraries like Boost and Qt. We will continue growing the list and welcome your suggestions!

Also available under an Open Source license are a few new libraries like GamePlay, a new 3D native gaming framework, and TouchMapOverlap.

We are using GitHub to anchor this and other initiatives. All libraries have a homepage that provides additional information on how they apply to the BlackBerry PlayBook OS. In most cases there will also be a code repository that holds the specifics for the port. For example, the OpenAL home page isblackberry.github.com/ndk/components.html#OpenAL and the repository is github.com/blackberry/OpenAL. Ideally the port specifics will be accepted into the upstream community; what we want is for the library to work on the BlackBerry PlayBook OS out of the box.

We will continue to expand our involvement in the Open Source community; it’s more efficient for us, better for the developers, and creates a much more open communication channel for everyone. For more details on RIM’s Open Source activities, visit http://blackberry.github.com.

P.S. Also check out George’s announcement at WebKit-Dev about our renewed public participation in WebKit!

Do you use GitHub to develop? Have you checked out the BlackBerry GitHub page? Share in the comments!

Have you been wondering what you can do with the touch-sensitive bezel around the screen of the BlackBerry® PlayBook™ tablet? When a user swipes down from the top edge of the screen, the BlackBerry® Tablet OS reports that gesture to the active application.

What you do with that gesture is up to you, and depends heavily on the context of your application. One idea is to display an application menu. This gives you the opportunity to enhance your UI without crowding your limited screen real estate. Let’s create a simple app that drops a menu down from the top edge of the screen when a user swipes down, and hides it again when they touch anywhere else.

Our application needs two classes:

A main application class that simulates the primary application UI and listens for the QNXApplicationEvent.SWIPE_DOWN event.

A MenuBar class that contains our UI controls. Our MenuBar should also hide and show itself on demand.

Application class

In your editor, create a file named AppMenuDemo.as. In AppMenuDemo.as, start by importing the packages we’ll need.

Since we’re overlaying two active UI components (the main UI and the menu bar), we need to decide how to process user interactions when they’re both visible. Let’s add an event listener to the main UI. In our case, we created a Sprite for our UI (ground), so we’re adding the event listener to that object.

Instantiate your MenuBar object and add it to the screen. We add it last so that it is the element that displays on top.

_menu = new MenuBar();
addChild(_menu);
}

Create a showAppMenu() method to respond to a SWIPE_DOWN event.

public function showAppMenu():void
{

If the menu is not currently visible, tell the menu to display itself. Otherwise, do nothing.

if(! _menu.isVisible())
{
_menu.show();
}
}

Create a groundClick() method to decide what to do when a user interacts with the application’s main UI (the ground object we created above). If the menu is visible, let the logic in the MenuBar class decide how to process the event. Otherwise, pass it to the main logic of your application.

MenuBar class

The menu bar is another Sprite that we overlay on top of our main UI. We animate the menu bar sliding down from the top edge of the screen when we display it, and back up into the top edge of the screen when we hide it. We control the animation using the Tweener class in the caurina.transitions package, which is included in the BlackBerry Tablet OS SDK for Adobe® AIR.

In your editor, create another file named MenuBar.as. Again, in MenuBar.as, let’s import the packages we need.

In our application class, we allowed the MenuBar to decide how to handle touch events that were not directed at the menu. This allows us to make the menu bar modal by ignoring clicks outside the bounds of the menu when it’s active, or close it, or whatever. In this case, we close the menu.

You can test your application now in the simulator. When the application starts, the screen area is blue. Swipe down from the top bezel. You should see a menu slide down from the top edge, and look like this:

Our implementation is simple, but hopefully helps get you started with the SWIPE_DOWN event and simple animations. The source files are available for download. There’s still time to submit your application to BlackBerry App World™ for the free BlackBerry PlayBook tablet offer, so don’t miss it!

What have you been doing with the swipe down gesture?

]]>http://devblog.blackberry.com/2011/01/blackberry-playbook-tablet-app-menu/feed/4ricardole1Creating an app menuCreating an app menuUsing Invoke APIs in your BlackBerry widgethttp://devblog.blackberry.com/2010/06/using-invoke-apis-in-your-blackberry-widget/
http://devblog.blackberry.com/2010/06/using-invoke-apis-in-your-blackberry-widget/#commentsFri, 11 Jun 2010 05:00:00 +0000http://devblog.blackberry.com/?p=1670]]>One feature of Super Apps is that they integrate with the native applications on BlackBerry® smartphones. So, how do you go about doing this? For BlackBerry® Widgets, it’s actually pretty simple. The BlackBerry® Widget API provides the Invoke object, which allows you to design your application to seamlessly work with the other applications on the BlackBerry smartphone. This results in a richer BlackBerry smartphone user experience.

By leveraging the Invoke API, you can invoke virtually any other application on the BlackBerry smartphone through a simple API call, where you’ll set a parameter for the app you want to invoke and then pass in any parameters that application is expecting. Right out of the box, the BlackBerry API contains these APIs to invoke:

By leveraging these APIs, you can come up with a compelling user story or use case to design your application as a one-stop shop for anyone looking to organize their daily tasks through your app. Open an email, save a meeting invite, set GPS to locate the meeting room, associate tasks with that meeting – these are just a few of the countless ways you can easily leverage the Invoke APIs, taking your BlackBerry Widget to the next level and embracing the Super App concept!

Have you leveraged any of the Invoke APIs yet? Please share your stories with us here in the comments.

We will identify some common – and sometimes unexpected – causes of user interface lag in both coding and design. See what BlackBerry smartphone end users expect from a Super App and compare how your application fits the bill. Learn what it takes to create a Super App for BlackBerry smartphones that are fast and responsive with several examples and sample code.

BlackBerry® Widgets can be written entirely using web technologies like HTML and JavaScript®. However, a compiled BlackBerry Widget is simply a regular Java®-based BlackBerry® application. BlackBerry Widget developers must therefore be aware of an important requirement for deploying an application onto an actual BlackBerry® smartphone – code signing.

Has the following scenario happened to you?

After working tirelessly to create a beautiful looking BlackBerry Widget application, and having used a BlackBerry Smartphone Simulator to perform extensive testing on the many application features you have created, you eagerly load your application for the first time onto a real device. Anticipating a surreal and mind-blowing experience, you quickly search for your application’s icon to open it for the first time…

…and you get this:

Figure 1: Secure API prompt

I never saw that message during testing, what does this mean?

Don’t worry, you didn’t do anything wrong. This message simply means your application has not yet been assigned a RIM authorized code signature. The BlackBerry® Device Software has recognized that your application needs to use core BlackBerry® application program interfaces (APIs), but has not been granted the appropriate permission from RIM to do so, and therefore prevents your application from starting.

The reason you didn’t receive this message when loading your application onto the BlackBerry Smartphone Simulator is that the simulator does not perform this security check (this enables efficient deployment for testing purposes).

Why do BlackBerry Widgets need to be signed?

RIM must track the use of some BlackBerry APIs for security and export control reasons. If you use these controlled classes in your BlackBerry applications, your application must be signed using a signature key (provided by RIM) before you can load the application .cod files onto the BlackBerry smartphone.

APIs requiring signing are used during the compilation of BlackBerry Widget applications. If you have ever looked at the BlackBerry API reference document, you can see that any APIs requiring signing are indicated by a lock icon, or are otherwise noted as “signed”. Here is an example of one of the secured APIs used in packaging a BlackBerry Widget:

Figure 2: BlackBerry API Java Docs definition of secure API

How do I sign my BlackBerry Widget?

Setting up and signing a BlackBerry Widget application involves three steps:

BlackBerry code signing keys must be purchased from and registered with RIM. These keys are uniquely assigned to a developer and are good for life. During the registration process, you will set a password that you provide each time you make a code signing request.

The identity of the registered user is recognized each time any of the signature keys are used to sign an application. As such, it is very important that they are not shared among developers, as the registered user assumes responsibility for the implementation and use of the application that is signed. Never publish these keys online, as you have no way of knowing how they may be used if downloaded.

Finally, through the use of the BlackBerry Signature Tool, you can sign your BlackBerry Widget using any of the following development tools:

Your application can automatically be signed each time you build it using the BlackBerry® Web Plug-in for Microsoft® Visual Studio® 2.0 by changing the active solution configuration from ‘debug’ to ‘release signed’. You can change this configuration through the Configuration Manager menu item, found in Microsoft Visual Studio’s Build menu.

Figure 4: Changing active configuration through Configuration Manager

After making this configuration change, the next time you build your Widget, you will be prompted to enter your signing password:

Figure 5: Prompt to enter signing password

Code signing using BlackBerry Web Plug-in for Eclipse 2.0:

When building your BlackBerry Widget project using the BlackBerry® Web Plug-in for Eclipse® 2.0, you can right click on your project name in the Package Explorer window to open a contextual menu. At the bottom of the menu are two options for building, including one that will apply code signatures to your COD file(s).

Figure 6: Menu item for signing a BlackBerry Widget

After selecting this menu option, you will be prompted to enter your signing password, after which your application will be built, and signed.

Figure 7: Prompt to enter signing password

BlackBerry Signature Tool

When the BlackBerry Signature Tool signs your Widget application, you will see the following screen open. This screen displays the list of APIs requiring signing that are used by your application. Each required signature will be applied, and you will see the value in the “Status” column change from “Not Signed” to “Signed”:

Figure 8: BlackBerry Signing Authority Tool

This is great! Now what?

Take a deep breath and smile. Your BlackBerry Widget is now ready to be used and can now be deployed to your users through venues like BlackBerry App World™. Congratulations! In the comments, tell us about the latest BlackBerry Widget you developed.

Eclipse is a trademark of Eclipse Foundation, Inc. Microsoft and Visual Studio are trademarks of Microsoft Corporation. Java and JavaScript are trademarks of Sun Microsystems, Inc.

]]>http://devblog.blackberry.com/2010/03/blackberry-widgets-and-code-signing/feed/7adamstan1Menu item for signing a BlackBerry WidgetSecure API promptBlackBerry API Java Docs definition of secure APIPackaging and Signing a BlackBerry WidgetChanging active configuration through Configuration ManagerPrompt to enter signing passwordMenu item for signing a BlackBerry WidgetPrompt to enter signing passwordBlackBerry Signing Authority ToolExplaining Digital Rights Managementhttp://devblog.blackberry.com/2009/12/explaining-digital-rights-management/
http://devblog.blackberry.com/2009/12/explaining-digital-rights-management/#respondFri, 04 Dec 2009 10:30:08 +0000http://blackberrydev.edstaging.com/?p=75/ Read More]]>I get asked about digital rights management (DRM) often enough that it’s probably high-time I do some writing about it. For those who don’t know, DRM generically refers to access control software used for limiting usage of digital media. For those that want to know more about what DRM options are available to them on BlackBerry® smartphones, this post will give you everything you should need.

Of the many DRM formats available, BlackBerry supports OMA DRM 1.0 forward lock. If a file protected with OMA DRM 1.0 forward lock is downloaded and installed to the BlackBerry smartphone via the BlackBerry Browser. It will then automatically be encrypted into a format such that the file can only be opened by the BlackBerry smartphone that created the file.

To achieve similar functionality in your own application, in BlackBerry OS 4.2 and above, open a FileConnection, cast it to an ExtendedFileConnection, call ExtendedFileConnection.enableDRMForwardLock() to enable the encryption on the file, create the file, then write out the contents.

What about applications that need DRM on streaming media or that want to implement their own DRM solution? As you would expect, there’s a little more work involved, but it’s definitely possible. In this case, you’ll need to extend the DataSource class and implement the SourceStream interface. Pass your DataSource instance into the media player, and the device will make calls to your SourceStream’s read() method as it needs to read more media data. So that means that you need to open the connection to your encrypted media data (either local or remote), decrypt and/or buffer it, then simply supply the decrypted data to the read() calls.

To see a sample DataSource / SourceStream implementation, check out the bufferedplaybackdemo in the JDE’s samples directory.