Did you miss or would like to re-watch any of our past developer webcasts? Below is a summary of where to find all the recordings posted to date, along with a couple that are coming soon.

NFC-related webcasts, specific webcast titles listed below:

• NFC overview (Native)
• NFC Tags BlackBerry® 10
• NFC Tags BlackBerry® 7

Cascades™-related webcasts, specific webcast titles listed below:

• Astonishing UIs using the new BlackBerry 10 framework
• Astonishing UIs using the new BlackBerry 10 framework continued
• Cascades – everything you’ve always wanted to ask about retrieving, storing and displaying your Data – but were afraid to ask
• Building Compelling 3D Apps using Cascades and OpenGL ES

Native-related webcasts, specific webcast titles listed below:

• BlackBerry Native Game Development

HTML5/BlackBerry® WebWorks™-related webcasts, specific webcast titles listed below:

• Using the Dojo Toolkit in a BlackBerry WebWorks app Full Webcast
• BlackBerry 10 WebWorks Applications with the Enyo.js framework Full Webcast
• Exploring the use of bbUI.js for building a BlackBerry UI with HTML5

Coming soon!

• HTML5 Gaming (WebGL (3D), Audio, Social Integration (BBM™), Web Workers, Web Sockets)
• Building BlackBerry 10 apps with jQuery Mobile & backbone.js

Built for BlackBerry-related webcasts, specific webcast titles listed below:

• 10k Developer Commitment
• Built For BlackBerry Part 1: User Benefit, User Experience, and System Integration
• Built For BlackBerry Part 2: Performance

Android-related webcasts, specific webcast titles listed below:

• Running Android Applications on BlackBerry® PlayBook™ and BlackBerry 10

Alpha-related webcasts, specific webcast titles listed below:

• Beta 3: Beta 3: BlackBerry 10 WebWorks SDK Update
• Beta 3: The Power of the Integrated Platform Emerges

Enterprise-related webcasts, specific webcast titles listed below:

• Enterprise App Developers: BlackBerry® Balance™ technology

The Marmalade webcast is hosted on the Marmalade site:

• BlackBerry game development with Marmalade SDK

C2 Development has opened up their application Kaxi for beta testing exclusively on BlackBerry® 10 Dev Alpha devices. Kaxi is a location-based app that simplifies the process of finding taxi companies local to the UK and USA. All you need is a GPS signal and a working network connection (Wi-Fi®/3G/4G). The app will then list local taxi companies nearest your location.

Sign up for the beta to gain access to the latest release before it reaches the BlackBerry App World™ storefront. Accepted beta requests will be given access to the Kaxi beta Portal which may be used to submit feedback and bug reports. The latest downloads will also be available via this portal.

Kaxi is currently only available for BlackBerry 10.

The first fix addresses an issue with the Invocation API. The invocation framework does not launch the target on the simulator. For all practical purposes, this means that if you create an invocation target application and install it on the simulator, no app will be able to invoke it. This functionality does already works on the device, so if you are developing your BlackBerry 10 app on the BlackBerry 10 Dev Alpha testing device, you should be fine. But for all those developers who are using the simulator for development, we felt it was necessary to provide a fix to this as soon as we could.

The other noteworthy fix is with regards to the Notifications API. When you develop an app with the capability of posting notifications, it gets vibrate set to ON and Badge set to OFF by default in the Notification Settings. It should actually be the other way around – vibrate should be set to OFF and Badge should be set to ON by default. Oops, reminds me of something Dr. Nick would do.

Other than that, there are no new features included in this patch. If these fixes are not important to your development, you can continue to use the Beta 2 version of the BlackBerry 10 Native SDK that you currently have installed.

You can download the latest BlackBerry 10 Native SDK here.

Cascades Beta 2 continues the path of C++, QT, QML and JavaScript®. You will recognize the UI controls, the event handling, the prepackaged data models and other features. You will also discover a couple of new features and lots of improvements to existing features.

We have also changed many APIs and we’ve provided you with a porting guide to help you upgrade your app from Beta 1 to Beta 2.

I’ve listed what I think are the most interesting new features and improvements here:

ActionBar, TabbedPane and Context Menu

We noticed that Tabs were very popular for dividing application content, but it wasn’t always very convenient to move to new pages when switching tabs. In many cases it was just better to stay on the same page but replace the content. Hence we changed the structure of the TabbedPane to allow tabs to work more than actions when needed.

The general appearance and interaction with the ActionBar, the Action Overflow menu and the Tab Sidebar has improved. We still have some way to go before we reach where we want to be, but you’ll see a major improvement in this release.

Application Menu

If you are a BlackBerry® PlayBook™ tablet user, you probably noticed that the previous version of Cascades didn’t include the application menu, widely used on the BlackBerry PlayBook tablet. It’s a menu that can be pulled down from the top using a swipe gesture, and we’ve now enabled it in Cascades. You would typically put less commonly-used functionality in the menu, such as application settings and help.

List

Since Beta 1, we have performed major refactoring of the listview control.

We now have a dedicated GridListLayout. You could do GridLists in Beta 1 as well by messing around with two level lists. However, this workaround is no longer possible, so you should use the dedicated gridlistlayout instead.

Sheets and Custom Dialogs

In Beta 1, we had the NavigationPane to create navigational flow. But there was no easy way of creating a modal UI, such as dialogs. In Beta 2 we have added two new concepts the remedy that.

Sheets are the way to put a navigation flow on hold and start a new temporary flow that needs to be finished before the underlying flow can be resumed. For example, if you need the user to edit some forms or compose something before continuing the normal navigational flow, sheets are ideal. They are full screen and can contain a complete navigation history of their own if they need to (i.e. include a NavigationPane or even TabbedPane). They are put on top of any ongoing navigation which cannot continue until the sheet is dismissed.

The BlackBerry® 10 platform already contains a bunch of standard system dialogs for the application developer to use. But for cases where an application needs to pop up a completely custom modal dialog, the CustomDialog class can be used. It’s pretty straightforward — put whatever UI you want in the dialog and it will be presented on top of existing UI (which will be dimmed out). The user can’t interact with what’s behind the dialog until it’s dismissed.

Scrolling and pinching

We have changed a little bit of how scrolling in a container works; one of the reasons being that we also want to make it play well with pinching, panning and rotating content. We have now introduced a separate scroll control handling this — the ScrollView.

We have enabled scrolling, zooming, panning by just setting a property as well as a full programmatic API to scroll around or zoom in and out in a scrollView.

Invocation and sharing from the ContextMenu and ActionBar

With BlackBerry 10, we are continuing the great BlackBerry tradition of connected, deeply integrated Super Apps. And it should be easy to create Super Apps!

In Beta 1 we showed how easy it is to include ActionItems on the ActionBar or the Context menu by just adding some small fragments of QML. It’s almost as simple to add sharing and invocation actions to your application. Add an invokeActionItem and point out the content to share, and you are more or less good to go.

Other

Generally Beta 2 should perform much better than Beta 1. We still have some of work left to get the performance we want, but we are getting there!

We’ve also made sure to include a bunch of new examples for you, and we’ve also updated the existing ones for your cut n’ paste pleasure.

Hopefully you’ll like the taste of this Cascades dough, and when you put your fingers into it this time, they are going to be less sticky. Let us know what you like and what we should change — this one is soon going in the oven!

The latest BlackBerry® 10 Beta SDKs are now available for download! They bring a whole lot more functionality, along with a software upgrade for the BlackBerry 10 Dev Alpha testing device for those who have received one at our BlackBerry Jam World Tour events or BlackBerry 10 Jam in Orlando this past May. This new device update now includes the BlackBerry App World™ storefront client application (the same version that is on the BlackBerry® PlayBook™ tablet). Yes, this means you can start to submit your BlackBerry 10 applications to BlackBerry App World and share it with fellow BlackBerry 10 developers to get early feedback.

So what’s next?

To keep the ball rolling for our developer community, we’ve scheduled a series of tooling and SDK releases that will be rolled out over the next few months. Each runtime (Native, HTML5, Adobe® AIR®, and Android™) will have incremental updates to functionality. Each runtime’s functionality won’t necessarily be in sync, as they each have different developer audiences where APIs are prioritized based on what each of these communities are asking for.

Each release is named Rn where R stands for “Release” and n stands for “number”. So for the first BlackBerry 10 Dev Alpha release, the SDK was R4 to match with 10.0.4.xyz version. We also sometimes do internal-only releases, which is why you’ll see some numbers skipped.

The BlackBerry 10 SDK Beta schedule looks like the following:

• R4: May SDK Beta Release (first beta)
• R6: July SDK Beta Release (just launched)
• R8: September SDK Beta Release (API Freeze, Binary Compatible with Gold)
• R9: October SDK Beta Release (bug fixes)
• R10: November Gold SDK Release (bug fixes)

But what’s coming in these releases?

We’re going to step out of the box and do something that we’ve never done before and quite frankly, something that I’ve rarely seen any tech company do in this industry. We’re going to share with you our feature release plan for each of the runtimes. We’ll be providing a list the top level line item deliverables — but not getting into the details of each feature, or else the list will turn into something as long as a DVD’s extended director’s-cut limited edition!

The beta roadmaps will be posted in the form of flight arrival boards so that you can see the feature, the flight/release it is on, the scheduled arrival time and the current status. These roadmaps should be available in a couple of weeks.

Now I’m going to give the usual disclaimer: These are “targets” and the usual laws of software delivery apply around priorities, dependencies and customer issue firefighting that can impact delivery schedules and scope. We’re being transparent as we can with you, our developer community, to help you better plan your app development leading up to the BlackBerry 10 launch. We want to ensure that we are releasing updates to the SDKs as frequently as possible leading up to gold. Once you have finished digesting and implementing what has been made available in one Beta update, there will be another one waiting for you with more goodies.

Before we talk about what’s new in BlackBerry 10, let us recap what is available for the BlackBerry Runtime for Android Apps for BlackBerry PlayBook OS 2.1. There were three major enhancements added to the Android Runtime in 2.1:

• Each Android app will now run in its own window. This greatly improves the user experience and consistency among the other application runtimes.
• Access to the cameras is now supported for Android apps, allowing many more application types to work on the BlackBerry PlayBook tablet.
• In-App Payments are now supported through the BlackBerry App World™ storefront, so Android applications can include virtual items for sale in their applications.

Building on this fantastic set of features, there is now support for telephony APIs for the Android Runtime in the BlackBerry 10 Beta. This includes support for cell location, and access to information about the network services on the device. For additional information, head on over to our API support page. We have completely revamped our Documentation and API Support page to make it easier to find the information you need! Let us know what you think.

All these features are now available for the Android Runtime on the BlackBerry 10 Dev Alpha device and simulator. How do you start using these great new features? Jump to the newly updated Runtime for Android Apps microsite. There is an updated 1.2 Beta release for the BlackBerry Eclipse™ Plug-in for Android Development Tools and Command-line tools to get starting using all these new Android Runtime features for the BlackBerry 10 Beta. For the Eclipse users, point your update site to https://bdsc.webapps.blackberry.com/android/downloads/eclipseplugin/beta/

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.

var viewer:Viewer = InvokeManager.invokeManager.invokeViewer( viewerRequest );
viewer.addEventListener( ViewerEvent.VIEWER_CREATED, viewerCreated );

private function viewerCreated( event:ViewerEvent ):void
{
   //viewer is created and ready to communicate with.
}

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:

InvokeManager.invokeManager.addEventListener(InvokeEvent.INVOKE, onInvoked );
private function onInvoked( event:InvokeEvent ):void
{
    if( InvokeManager.invokeManager.startupMode == InvokeStartupMode.INVOKE )
    {
        var invokeRequest:InvokeRequest = InvokeManager.invokeManager.startupRequest;
    }
    else if( InvokeManager.invokeManager.startupMode == InvokeStartupMode.VIEWER )
    {
        var viewerRequest:InvokeViewerRequest = InvokeManager.invokeManager.startupViewerRequest;
    }
}

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:

package
{
    import qnx.events.InvokeEvent;
    import qnx.invoke.*;

    public class Main extends Sprite
    {

        public function Main()
        {
            //NOTE: THIS MUST BE THE FIRST THING SET IN YOUR APPLICATION CONSTRUCTOR
            InvokeManager.invokeManager.addEventListener(InvokeEvent.INVOKE, onInvoke );
        }

        private function onInvoke( event:InvokeEvent ):void
        {
            if( InvokeManager.invokeManager.startupMode == InvokeStartupMode.INVOKE )
            {
                //invoked as an application/target.
                var data:InvokeRequest = InvokeManager.invokeManager.startupRequest;
            }
            else if( InvokeManager.invokeManager.startupMode == InvokeStartupMode.VIEWER )
            {
                //invoked as a viewer
                var data:InvokeViewerRequest = InvokeManager.invokeManager.startupViewerRequest;
            }
            else
            {
                //launched by the pressing on the icon on the home screen.
            }
        }
    }
}

Closing a Viewer

There are two different ways a viewer can be closed:

1. From the application
2. From the 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:

Viewer code

InvokeManager.invokeManager.viewerSendMessage( "select", {name:"Fred"});

App Code

__currentViewer = InvokeManager.invokeManager.invokeViewer(viewerRequest);
__currentViewer.addEventListener( ViewerEvent.VIEWER_MESSAGE, onMessage );

private function onMessage( e:ViewerEvent ):void
{
    trace( e.message, e.data ); //outputs "select Fred";
}

image from Indian Creek Web Design

I’ve spent many hours talking to members of our developer community both online and in person at our conferences and meet-ups, and I know you’re excited by these tools. Last week, I attended my first BlackBerry® 10 Jam in Toronto and I was blown away by the energy of the developers in attendance.

What to expect in this first Beta

The BlackBerry 10 SDKs don’t jump to awesomeness in their first iteration; it’s an evolution to greatness. In this first Beta we’ve provided the foundational building blocks and a great start for developers to see where we’re heading. The SDKs allow you to create the BlackBerry 10 user experience with core controls and a great application framework to build the necessities of your application around networking, storage and other foundational pieces. It’s not like we’re starting from scratch; all the functionality provided in the SDKs for the BlackBerry® PlayBook™ tablet is also available.

We’ve also made sure that the core UI controls in the Adobe® AIR® runtime have been re-skinned to provide the BlackBerry 10 look and feel along with updating bbUI.js for WebWorks developers to provide the same BlackBerry 10 experience as you find in Cascades™.

Did you just say “first Beta” – and what does it mean to evolve?

We’ll be providing a series of Beta releases on the road to the gold BlackBerry 10 SDK. I want to make sure I set expectations with the community on how we’re approaching the beta cycle. As we evolve each of the SDKs, it means that on top of adding functionality we may need to make changes to functionality released in a previous beta. We are making sure that we examine all the possible angles before we make changes that could affect your application’s code during the Beta and are trying to minimize these changes as much as possible. However, there are times when we’ll have to make changes to ensure that we have solid footings for moving forward with follow up releases. As we move closer to gold, our goal is to make sure that changes in the SDK do not affect compatibility with your code.

What about PIM, BBM, Share and Invocation Framework APIs?

RIM has a strong heritage in delivering fantastic deep integration into the core BlackBerry experience and providing a differentiating factor for your application on the platform, and this will continue with BlackBerry 10. As we evolve the BlackBerry 10 SDKs, these deep integration APIs will be made available, but they aren’t quite ready for 3rd party consumption yet.

These APIs are still seeing refactoring as we move through all the use cases of our core applications. We want to ensure that both our core apps are using the same APIs as 3rd party developers and that the APIs see minimal changes after they are made available in a Beta.

I won’t list all of the APIs that are coming, but I’ll list the hot topics where I usually get inquiries:

• BBM™
• PIM (Contacts, Calendar, Tasks, Notes)
• Messages/Email
• NFC
• Share/Invoke Framework
  • Adding your menu item to an existing app
  • Invoking and being invoked by another app
• String pattern registry
• Geocoding & reverse geocoding
• Bluetooth®

All these and more will be coming in follow-up Beta releases, so make sure you grab the SDKs and start building the core of your application to ensure that you’re ready to integrate these features as soon as they’re available!

Turns out I had locked the app’s orientation, but neglected to actually specify which orientation it should be locked to. On the BlackBerry® PlayBook™ tablet it was fine, since the default was landscape and that’s what I wanted, but the Blackberry 10 Dev Alpha is a portrait device. A quick change to add <aspectRatio>landscape</aspectRatio> to my app.xml (not even the code!), and I’m done.

Since I had specified the dimensions of the SWF in my main action script file, I didn’t even need to change any of the sizes of the menus or anything (though I probably should have just made everything scale dynamically in the first place). Either way, it only took me a couple minutes to sort out, and all I did was fix a legitimate bug. I didn’t even have to use the BlackBerry 10 SDK to compile it, since I wasn’t using any new APIs. So if you already have an Adobe AIR app, you are probably good to go. Congratulations on writing your first app for BlackBerry 10!

When we released our first Betas of the BlackBerry® 10 WebWorks™ SDK and Ripple Emulator at the BlackBerry 10 Jam conference in May, we spoke about our desire to bring frequent updates of these tools to you, our dedicated developer community. We want to keep fueling your creativity and desire to build the best BlackBerry 10 applications leading up to the official release. So, here is your next BlackBerry WebWorks and Ripple fix.

This update brings a few new APIs (and emulation thereof in Ripple) along with a host of fixes and a slight change to how we handle whitelisting of events.

First up is the addition of the blackberry.ui.dialog APIs that will be very familiar to existing BlackBerry WebWorks developers. This API provides two methods that allow you to launch asynchronous dialogs requesting feedback from the user. These dialogs leverage the standard system level dialogs so you can get a consistent look and feel for your application with the rest of the system. standardAskAsync provides a predefined set of buttons for your dialog, whereas customAskAsync allows you to customize the dialog buttons.

We have also added an API that, in conjunction with the standard HTML5 onLine API, will let you know just how connected you really are. The standard navigator.onLine property and online/offline events are supported to let you know if your application has connectivity in general. If you would like to know what type of connection you have and when the type of connection changes, check out our blackberry.connection.type property, and listen for the connectionchange event. This will tell you if you are on VPN, BlackBerry® Bridge™, WiFi®, etc.

Speaking of events, we have adjusted how these work slightly from the first release. In the initial beta, all events were defined in the blackberry.event namespace. Without getting into gory details, this proved to be somewhat inefficient on the final code size, so we have moved the event definitions into the namespace that contains the functionality related to that event – i.e. the battery events are now defined in the blackberry.system namespace. Note that you no longer need to whitelist blackberry.event, since it only has the add and remove listener functions (these will always be available to call), but you will have to whitelist any namespace that has an event you are specifically interested in. Please check out the API reference.

In terms of bug fixes, there are a couple of key ones that I want to call out. If you use a module loader, you can now also use BlackBerry WebWorks, hooray! In the first release, the last one included into your app would work but break the first. Now webworks.js and module loaders play nicely together.

In the first release, you also could not sign your application at the same time as enabling remote web inspector. You can now do this so you can test your application on secure devices without needing to worry about debug tokens. That said, be sure to turn off web inspector before you submit your application to the BlackBerry App World™ storefront.

The team here at Research In Motion® (RIM®) is hard at work on the next Beta refresh, currently slated to land in early July. If you are really eager/curious/have lots of free time, feel free to check out our progress in GitHub, and let us know whether we are heading in the right direction on new features and APIs.

For BlackBerry WebWorks SDK work, check out:

https://github.com/blackberry/BB10-Webworks-Packager

https://github.com/blackberry-webworks/BB10-Webworks-API

Ripple? Check out:

https://github.com/blackberry/Ripple-UI

Looking forward to a great summer of BlackBerry 10 and BlackBerry WebWorks coding!