http://giphy.com/gifs/TznYiZCFXeLle

Multimedia on BlackBerry 7 was based on the multimedia JSR (135). There were a lot of limitations regarding supported formats, how many sounds could be played at the same time, and even what worked on which device.

In BlackBerry 10, there are a wide range of supported codecs, containers, and protocols.

For video, we recommend an MP4 containing H.264 video at 720p and AAC audio. For audio, it depends a lot on your use case. In addition to mainstays such as MP3 and AAC, we support things like FLAC and Ogg Vorbis.

To actually play your multimedia, you should be looking at the MediaPlayer class. That will handle audio or video. You can also easily play the built in system sounds with the SystemSound class.

• Tutorial: Playing Audio or Video
• Tutorial: Playing SystemSounds in an app

Recording audio is through the AudioRecorder class. You can record a few different formats, including AAC (.mp4) and PCM (.wav).

• Recording Audio

This is all pretty straightforward and should be pretty easy to adjust to if you are used to the Java way of doing things. There are a few key differences that you might not be expecting though.

The first is the NowPlayingConnection. If you are building any sort of media player type application: use it. What it does is let the user control the volume and playback of your app from in another app, using the volume keys on the side. You can also provide a bit of data like a thumbnail image and the current song playing. No user is going to want to have to go back into your application just to change the volume, and it’s really easy to implement.

• Working with NowPlayingConnection

Secondly, unlike in BlackBerry 7, in BlackBerry 10 you can enable echo cancellation in order to do VoIP. There is no convenient Qt API to do this, but you can use QSA and open a connection to the “voice” PCM audio interface.

• BlackBerry 10 VoIP

The other big difference is that you can’t just feed bytes directly into the media player. You need to have an actual file to play, or be using one the streaming protocols supported. Of course, there is nothing stopping you from dropping down to OpenAL/ALUT and doing whatever you need if that’s your style. You also have QSA available as mentioned before, as well as mm-renderer (which is what MediaPlayer is using), but that is all beyond the scope of this article.

Networking in BlackBerry 10 is done through the QNetwork module. You no longer need to worry about transport selection. Your typical HTTP communication can be handled through QNetworkAccessManager. It provides methods such as get() and post(), which take a QNetworkRequest and then asynchronously return a QNetworkReply.

For example:

QUrl *url = new QUrl("http://www.iana.org/domains/example/");

    QNetworkAccessManager *manager = new QNetworkAccessManager(this);

    connect(manager, SIGNAL(finished(QNetworkReply*)),
    		this, SLOT(replyFinished(QNetworkReply*)));

    manager->get(QNetworkRequest(*url));

And then in your replyFinished slot:

void App::replyFinished(QNetworkReply* reply) {
	qDebug() <readAll();

	// Call deleteLater to make sure the reply gets cleaned up
	reply->deleteLater();
}

You can also do TCP with QTCPSocket and QTCPServer, UDP with UDPSocket , and FTP with QFtp.

And of course, lower level libraries such as cURL are available if you should require them.

Now it has to be said that it wasn’t the best summer here in the UK (though fortunately the weather gave us a break just in time for the Olympics!) and so I occasionally found myself at the weekend with “fine weather-dependent plans” cancelled and time on my hands. One such weekend, I was thinking about NFC and my thoughts turned to discussions I’d had with John about whether NFC could enrich games and the gaming experience in some way.

The world of computer games has changed somewhat in the 30-something years I’ve been playing them! It’s gone from text-based adventure games (“go north!”) played on a PDP-11 with a teletype and no screen, through the block graphics of Lunar Lander on a Commodore Pet, and onwards through Space Quest, Civilisation I, the Monkey Island series and (many) more favourites.

In the beginning and for many years, games were single-player — or at least they were single machine games. More than one player could play, but you’d have to share the keyboard or take turns. Then came LAN games, and this evolved into Internet-based gaming with huge online gaming communities (without whom, I have no doubt, the world would now be over-run with zombies). The truly great thing about online gaming is that you need never know that “goreslayer765” who just destroyed you in your favourite game is actually a 9-year-old with far more knowledge of automatic weapons than can possibly be healthy. I mean, whose fragile ego could handle knowing that?

So, both extreme ends of the single player vs. multiplayer spectrum are well catered to these days. But in what way might NFC enrich the gaming experience, and in what kind of games? I had a quick brainstorm with John on IM and we came up with a few use cases:

But why would you want to do this? After all, there are plenty of other ways to trigger “new game” or “it’s your turn now” and to share data across a network. Well, the appeal of using NFC is simply this: it adds a physical, tactile element to the game. You’re sitting right next to the person you’re playing with, and having to touch devices at intervals in the game could add a novel and fun element to the experience.

We then realized our most important task. We needed a name for the phenomenon of NFC-enabled games that we were now thinking about. In a flash, I had it! Please welcome “Proximity Gaming” to the world!

Armed with a few ideas, we decided to develop a game as a proof of concept and set about thinking about what the first game would be and how it would work. We decided we’d develop an NFC-enabled version of “tic tac toe” or “noughts and crosses” as it’s known in the UK.

We decided to use NFC in two places. Firstly, players would have to touch devices to start a game, and secondly, they’d touch devices to indicate “it’s your turn now”.

We had to consider a few issues regarding the implementation. It was immediately apparent that we’d have to pass some kind of message from device A to device B and that we’d probably need several message types. In other words, we’d need a simple protocol.

We could also see several technical ways of sending a message from one device to another. We could use virtual target emulation in theory, or maybe we could use one of the two NFC peer-to-peer APIs, SNEP (Simple NDEF Exchange Protocol) or LLCP (Logical Link Control Protocol).

We dismissed target emulation and focused on the peer-to-peer options, since this was clearly a peer-to-peer scenario. We concluded that either SNEP or LLCP could be used, but that SNEP would be a little easier to work with — LLCP being a lower-level connection-oriented protocol whereas SNEP is a higher-level message-oriented protocol. We’d worked with both in the past, so we had a pretty good feel for what the coding would be like.

In conclusion, we decided to invent a simple message-oriented protocol and use SNEP as the NFC protocol, which would transport game messages between devices. The UI design was to be basic: an initial screen that prompted players to touch devices to start a new game; a screen for “player 1” to choose either noughts or crosses; and the main game screen upon which to place noughts and crosses.

We also decided to implement the game for both BlackBerry® 7 OS using Java®, and our BlackBerry® 10 Dev Alpha devices using C++/Qt/Cascades. Being able to play the game between a BlackBerry 7 device and a BlackBerry 10 device would be a nice proof of the interoperability of NFC between generations of BlackBerry technology.

Here are some screen shots from the proof of concept game, first from the BlackBerry 7 version of the game:

Figure 1 – New game screen

Figure 2 – Player 1, choose nought or cross

Figure 3 – Main game screen

And here are some screen shots from the proof of concept game, from the BlackBerry 10 version of the game:

  
Figure 4 – New game screen; Figure 5 – In game; Figure 6 – Game over

Thoughts on the “game protocol” crystalized properly as we worked through prototyping the game and we found we needed the following message types in the simple protocol:

We’d like to tell you how we went about coding the game.

If you want to know how to use SNEP in general terms, we’ve written articles on the subject for both BlackBerry 7 and BlackBerry 10 and sample code too. You’ll find details here:

BlackBerry 7 – Peer to Peer Communication with SNEP
BlackBerry 10 – Peer to Peer Communication with SNEP

There’s a key point here: you could implement your Proximity Gaming ideas for either BlackBerry 7 or BlackBerry 10 because both have the specific types of NFC peer-to-peer capabilities that you will need.
Harnessing NFC SNEP in the way we wanted for our game was easy. The APIs themselves are very straightforward to use. For BlackBerry 7 we designed some Java classes, which represent the various message types in the game protocol. This was standard stuff if you’re accustomed to working with protocols, and we ended up with an abstract class called ProtocolMessage and a series of concrete sub-classes, one for each message type. Each of these classes implemented a marshall and demarshall method so that we could easily swap between byte array representations, which would be exchanged over NFC SNEP and Java objects for internal use in the application.

Here’s an example of one of the protocol message classes:

public class ProtocolMessageMasterBid extends ProtocolMessage {

    private int bid;

    public ProtocolMessageMasterBid() {
        message_id = Constants.PROTOCOL_MASTER_BID;
        Random rand = new Random(System.currentTimeMillis());
        bid = rand.nextInt(1000000);
    }

    public byte[] marshall() {
        byte [] bid_bytes = Utilities.toBytes(bid);
        byte [] bytes = new byte[1+bid_bytes.length];
        bytes [0] = message_id;
        System.arraycopy(bid_bytes, 0, bytes, 1, bid_bytes.length);
        return bytes;
    }

    public void demarshall(byte[] bytes) {
        if (bytes.length != 5) {
            Utilities.log("XXXX invalid parameter length passed to ProtocolMessageMasterBid demarshall:"+ bytes.length);
            return;
        }
        message_id = bytes[0];
        bid = Utilities.toInt(bytes,1);
    }

    public int getBid() {
        return bid;
    }

    public void setBid(int bid) {
        this.bid = bid;
    }

    public String toString() {
        String string = super.toString() + ",ProtocolMessageMasterBid" + ",bid="+bid;
        return string;
     }
}

We also implemented classes called NfcReceiver and NfcSender, which implemented NDEFMessageListener and NDEFMessageBuilder respectively and provided the basic mechanism for sending and receiving my protocol messages.

For BlackBerry 10, life was actually simpler and we just needed to create message using the Qt QbyteArray class and then utilize the BlackBerry 10 native APIs for NFC, as shown below:

void NfcWorker::sendTurnData(bps_event_t *bps_event) {
	nfc_event_t *nfc_event;
	nfc_target_t* target;
	nfc_ndef_record_t* myNdefRecord;
	nfc_ndef_message_t* myNdefMessage;
	// Obtain NFC target object from our BPS NFC event object
	//------------------------------------------------------------------------------
	CHECK(nfc_get_nfc_event(bps_event, &nfc_event));
	CHECK(nfc_get_target(nfc_event, &target));
	//------------------------------------------------------------------------------

	QByteArray ba;
	ba.resize(9);
	ba[0] = 2; // turn over message ID
	// tile changed
	ba[1] = 0;
	ba[2] = 0;
	ba[3] = 0;
	ba[4] = _state->lastSelection();
	int ls = _state->lastSelection();
	// symbol changed
	ba[5] = 0;
	ba[6] = 0;
	ba[7] = 0;
	ba[8] = _state->mySymbol();
	int ms = _state->mySymbol();
	_state->mySymbol();
	myNdefRecord = makeTurnOverRecord(ba.constData());
	//------------------------------------------------------------------------------
	CHECK(nfc_create_ndef_message(&myNdefMessage));
	//------------------------------------------------------------------------------
	CHECK(nfc_add_ndef_record(myNdefMessage, myNdefRecord));
	qDebug() << "XXXX Pushing NDEF message over SNEP";
	//------------------------------------------------------------------------------
	CHECK(nfc_push_ndef_message(target, myNdefMessage));
	//------------------------------------------------------------------------------
	CHECK(nfc_delete_ndef_message(myNdefMessage, true));
	CHECK(nfc_destroy_target(target));
}

So, having designed and implemented a message-oriented protocol and coded classes which used NFC SNEP to transport those messages between devices, the rest of the effort that rainy weekend was spent on standard game development issues like creating the UI. The UI was really easy to create for the BlackBerry 10 version using Cascades™, and took a fraction of the time and effort we spent on the BlackBerry 7 Java version of the game. In both cases, the NFC part was also quite easy and took relatively little effort as a portion of the whole application.

The next step was to find some guinea pigs to test the application out. (Not real guinea pigs, of course — their paws are too small and they have claws that make working with a touch screen problematic. So instead, we decided to use humans — our respective friends and family to be precise. )

Testing was informal. In my case, I explained I’d developed a two-player game that allowed you to take certain actions just by touching the two devices back to back. My guinea pigs generally looked a bit blank or even cynical at this point. “Just touch them together? Really?!” But with a little coaxing I got them started and watched them carefully.

At the very start of the game, the two players are instructed to touch devices to start the game. Looking a little unsure at first, the players touched devices and held them together for a second. The devices responded, vibrating to indicate an NFC message had been received, and the game moved on to the next screen to allow the selected Player 1 to choose noughts or crosses. At this point, the expressions on the players’ faces changed — from expressions that suggested they were being asked to participate in a black magic ritual to sheer delight with big smiles all around! And from that point, there was no stopping them. They were each playing on devices with touch screens – the BlackBerry® Bold™ 9900 and 9790 smartphones, to be precise – so selecting a place to put their mark on the game “board” was simply a case of touching the screen. And passing turns to the other player? They just touched the devices together, of course!

Here’s a video showing the game in use:

[ YouTube link for mobile viewing ]

The verdict was very positive. Players liked the idea in general and enjoyed the tactile element of the game play. It seemed that Proximity Gaming was a big hit!

The two versions of our NFC-enabled tic tac toe games are available with full source code from our github repositories here:

https://github.com/blackberry/Samples-for-Java/tree/master/NFC/TouchTicTacToe
https://github.com/blackberry/Cascades-Community-Samples/tree/master/TouchTicTacTen

So over to you, BlackBerry developers! How could you use NFC in your BlackBerry smartphone game?

On October 4th at 10:00 AM EST, we kick off the first in a series of webinars on the subject of Near Field Communications (NFC).

NFC is in the media a lot these days, but usually in the context of contact-less mobile payment solutions. Through our series of webinars, we plan to explain and demonstrate how NFC has great potential for allowing the user to interact with the physical world in all manner of scenarios, and that applications of all types can benefit from a sprinkling of NFC magic. Non-developers will learn all about the concepts around NFC and the ways in which it can be exploited. Developers will learn how to code various types of NFC function for the BlackBerry® 7 OS and BlackBerry® 10. We’ll be leaving no NFC stone unturned as we make a structured and thorough journey through the many aspects and capabilities of NFC!

On October 4th, we’ll start the ball rolling with “An introduction to NFC on BlackBerry”. This session is aimed at non-developers and developers who want to start from scratch and learn about the most fundamental aspects of NFC; what it is, what you can do with it, how much effort is required, skills required, and so on. Developers are more than welcome (as always!) but this session will not look at code. The sessions that follow will include plenty of code and demonstrations too.

After this, initial kick off session, we have the following two sessions scheduled:

18th October (10:00 AM EST) – Working with NFC Tags on BlackBerry 10, presented by my learned colleague, John Murray. John is another member of the BlackBerry Developer Relations team who specializes in NFC.

25th October (10:00 AM EST) – Working with NFC Tags on BlackBerry 7, presented by myself, Martin Woolley.

After that, we’ll be scheduling other sessions to cover other aspects of NFC such as peer to peer mode. Watch this space for further news on this.

It’s forecast that there will be a quarter of a billion mobile NFC users by 2015. Make sure your apps are ready to exploit the NFC phenomenon and join me on October 4th for an introduction to this exciting technological development!

Sign up here!

Download the sample app

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:

JSONObject context = new JSONObject();
try {
context.put(SendCommandContextKeys.TEXT, "Your Text");
context.put(SendCommandContextKeys.SUBJECT, "Your Text");
// context.put(SendCommandContextKeys.PATH, "file:///.....");
} catch (JSONException e) {
System.out.println(e.toString());
}

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:

SendCommand[] commandsAll =
SendCommandRepository.getInstance().get(SendCommand.TYPE_TEXT, context, true);

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.

Now let’s filter:

for (int i = 0; i < commandsAll.length; i++) {
if (commandsAll[i].getId().equals("Twitter_text")) {
commands[0] = commandsAll[i];
}
if (commandsAll[i].getId().equals("Facebook_text")) {
commands[1] = commandsAll[i];
}
}

…and we are done. We have our SendCommand objects and we are free to call their run() method anywhere in our app. Be it a Button click or a Menu selection, knock yourself out!

As noted during BlackBerry DevCon Americas, there would continue to be BlackBerry smartphone releases based on BlackBerry® 7 OS.  Today we’re pleased to provide you with a new developer tool to prepare for this: the BlackBerry® 9220 smartphone simulator.

We have a new simulator available for download on our simulator download page, or you can download it directly using this link:

• BlackBerry 9220 smartphone simulator

Alongside the launch of the new simulator, we have also opened up the BlackBerry App World™ storefront to allow you to start posting your applications for sale. Many applications designed for the BlackBerry® 9300 smartphone series should be easily ported to this new device with little to no change in the application.

We encourage you to test your applications as soon as possible using the new simulator, and then navigate to the BlackBerry App World vendor portal to post your applications for the BlackBerry 9220 smartphone running BlackBerry® 7.1 OS.

The BlackBerry 9220 will support Bluetooth® 2.1 and include the following profiles:

• Headset Profile (HSP)
• Hand Free Profile (HFP)
• Address Book Integration using AT commands or OBEX (Object Push)
• Phone Book Access Profile (PBAP)
• Dial-Up Networking (DUN)
• Bluetooth Stereo (A2DP / AVRCP)
• Serial Port Profile (SPP)
• Secure Simple Pairing (SSP)
• A/V Remote Control Version 1.3
• Bluetooth Message Access Profile (MAP)

BlackBerry 9220 – Device Info

• 320 x 240 resolution, 164 dpi
• Application Icon size: 46 x 46 pixels
• Memory: 512 MB Internal Persistent Storage, 512 MB RAM
• 2 MP Camera, 5 X digital zoom
• QWERTY keyboard
• Networks: EDGE, GPRS, GSM
• FM Radio
• Wi-Fi® 802.11 b/g/n
• Mime Type: Mozilla/5.0 (BlackBerry; U; BlackBerry 9220; en-GB) AppleWebKit/534.11+ (KHTML, like Gecko) Version/7.1.0.316 Mobile Safari/534.11+

BlackBerry 9220 – Multimedia Capabilities

The first thing that needs to be done is to retrieve the pz_ directory and the pz_ properties file from the Windows temp directory after BlackBerry Theme Builder exports these files , but before the files can be deleted. Doing this manually would likely not work ; it happens very quickly, so you may need to apply permissions to the directory to prevent file deletion.

(Note: When changing any system permissions it is extremely important to fully understand the repercussions and only make changes at your own discretion.)

After you have these files saved to a safe place, such as your desktop of a common development directory, you can copy the pz_ properties file to the pz_ directory to keep them all in one place.

Next you will need to open the various SVG files in the directory you save and make manual changes to support the resolution and desired layout on the target device. For example, the main SVG wrapper element has width and height attributes; these can be set to the width and height of the target device’s resolution. For any other elements, the width, height, x and y values may need to be set. Here is a list of some elements which can be accessed and modified:

• xlink:href
  • CurrentDateTime
  • AlarmIndicator
  • BatteryLevel
  • Coverage
  • SystemStatus
  • GridIndicators
  • Roaming
  • SignalLevel
  • WLANSignalLevel
  • GPSMode
  • Image
  • OwnerInfo
  • ProfileIndicator

• Id
  • hs_profile_underlay
  • hs_profile_entry_icon
  • hs_profile_focus_entry_icon

• • Id
  • wifi_bullets

A forum post will be started where users can contribute additional elements and attributes in the BlackBerry® Themes & Animated Graphics board.

After you have modified all of the SVG files, you will need to compile the theme files into CODs that can be installed to your device.

First, you will need to modify the ThemeBundler.contentDir element of the pz_.properties file to point to the current directory. Then you can run the following two commands from a command prompt:

\bin\svgc.exe *.svg
\bin\tbbundle.exe pz_.properties


Make sure to watch the console for any errors when parsing the SVG. If all is successful then the theme CODs should be output to the directory specified in the ThemeBundler.outFileDir element of the pz_.properties file.

Your theme is now ready to be loaded for testing onto an actual BlackBerry smartphone!

However, this method of theme creation is not an exact science. The layout of all elements and items will take some time to get right and not all portions of the theme will be fully supported. It may take some time to get it right with several testing iterations:

while (theme != perfect)
modify SVG → compile code → load onto device → test thoroughly


It would be a good idea to progress with a small number of modifications until you reach the desired theme state. A few things to note:

1. There is a 5MB file size limit for themes on the smartphone , any themes greater than this will be rejected by the target device
2. All images exported by Theme Studio using this method will be of an incorrect size as you are targeting a different handheld. To optimize the user experience you will need to change each image to the size expected by the target device.

Once you are satisfied, you can then distribute your theme using your preferred distribution channels, including the BlackBerry App World storefront.

Have you had success creating themes this way? Let us know in the comments!

1. The first thing we need to do is modify the device_profiles.properties file to include information for the BlackBerry® smartphone model/series for which we will be creating a theme.

Example:
plazmic.device<NUM>.name=BlackBerry <Model> [Series]
plazmic.device<NUM>.shortName=<Model>
plazmic.device<NUM>.modelName=<ModelName>
plazmic.device<NUM>.file=blackberry/BB<Model>.properties
plazmic.device<NUM>.thumbnail=blackberry/images/BB<Model>_thumbnail.png

<NUM> Each device listed in this file is incremented in this element. Any new element added should be exactly one higher than the previous listed.

<Model> The smartphone model you will be creating the theme for (ie. BlackBerry® Bold™ 9900 smartphone)

[Series] If there are multiple smartphones with the same UI characteristics (ie BlackBerry Bold 9900 smartphone and BlackBerry® Bold™ 9930 smartphone) you can include “Series”

<ModelName> The commercial name for the smartphone (ie. Bold™, Curve™ or Torch™)

2. Next we need to create the BB<Model>.properties file referenced by the device_profiles.properties file. The easiest way to do this would be to copy an existing BB<Model>.properties of a BlackBerry® 6 device, then simply rename the file to reflect the target model and update the resolution (screen.size) with the resolution of the target device.

3. We also need to create some files to let BlackBerry Theme Builder know which theme types are supported for our new device. To do this, copy an existing device’s .properties file:

Example:
<ThemeStudio>\resources\theme\BlackBerry6_480x360\9780BlackBerry6.properties

From there, rename it to suit the model of device being targeted but keep it in the same directory.

4. Finally, open this file in a text editor and change the following values:
theme.name = <Model> BlackBerry®6 Custom
theme.device = <Model>
theme.base = BlackBerry®7_<Resolution>_b
theme.alternateBase = //Remove this line entirely from the file, it is not needed
theme.supportedHandheldOs = 6.0,7.0
theme.preferredHandheldOs = 7.0

<Resolution> – The resolution of the target device’s display

After this is done, you should be able to launch BlackBerry Theme Builder and select the model of device you have just added as well as the theme layout. If this works, then you have successfully modified BlackBerry Theme Builder!

(Note: Functionalities such as previewing on device and/or simulator will not work. Test themes need to be loaded outside of BlackBerry Theme Builder for testing using methods such as JavaLoader or BlackBerry® Desktop Software.)

Exporting the theme file at this time and trying to load it onto a device will cause some usability issues, as the theme has been created for a device with a different resolution from the target device. There is a bit more work that will go into customizing the theme before it can look and function properly. This will be covered in Part 3 – Manipulating Themes. Watch for this blog post soon!

Let us know if you have any questions so far!

Will Research In Motion (RIM®) let me modify BlackBerry Theme Studio to create themes for OS 7 devices?

Absolutely! Note that the method proposed in this workaround is by no means easy. It will require considerably more effort to get even basic themes working, but it can be used as a means to create themes until an official BlackBerry Theme Studio is released that supports BlackBerry 7 OS devices. Although these steps are being provided, this method of creating themes is essentially unsupported. Theme creation and stability will entirely be the responsibility of the developer; no bugs will be logged against this method of creating themes.

If Liquid Graphics broke theme support, then how can themes be made?

For the most part, the anatomy of a theme has stayed relatively unchanged between OS releases. With the introduction of BlackBerry 7 OS, several screens now use a completely new mechanism to create the UI, known as Liquid Graphics. Because of this large change, some features and functionalities supported in previous OS themes may be unsupported. This would be a limitation of BlackBerryTheme Studio 6.0 not being aware of how themes are expected in BlackBerry 7 OS. For example, both the phone and home screens previously used SVG for layouts and actions; in BlackBerry 7 OS, the phone screens no longer use SVG at all, while the home screen only uses SVG for layout purposes. All animations on the home screen and the layout of the phone screens are handled by Liquid Graphics.

Understanding how BlackBerry Theme Builder works

For the sake of simplicity, I will be referring to the BlackBerry Theme Studio 6.0 installation directory (wherever you may have chosen to install it on your system) as <ThemeStudio>.

Once BlackBerry Theme Builder is launched, it starts off by determining which devices and theme types are supported by reading bundled property files:

1) <ThemeStudio>\resources\devices\device_profiles.properties
This file contains a list of information for all supported BlackBerry smartphone models, including a link to a file which describes the characteristics of each device and a thumbnail view of the device.

2) <ThemeStudio>\resources\devices\blackberry\BB<Model>.properties
One of these files is included for each device model/series supported by BlackBerry Theme Studio. It lets BlackBerry Theme Builder know information about the device, such as display resolution, supported fonts, et cetera.

3) <ThemeStudio>\resources\theme\<ThemeDir>\<Model><ThemeType>.properties
Once BlackBerry Theme Builder reads the list of supported devices (1) and determines their properties (2), the next step is to determine which themes are available for each device. All found theme types will be displayed in the splash screen’s Select Layout Type drop-down. These themes will be based off the .thm file located in the same directory as this file.

After BlackBerry Theme Builder launches, and you make your changes to the theme and export your created masterpiece, BlackBerry Theme Builder does the following:

1) Analyzes the theme for any changes from the base theme (the default theme loaded by BlackBerry Theme Builder before any modifications are made).

2) Any changes found results in certain files being created during the export process by BlackBerry Theme Builder.

• Layout changes: SVG and associated PME files are created.
• Image changes/additions: New image files are included.

The more modifications that are made, the more files that will be exported (one image file for each image that is added). The SVG files are used to specify the layout, behavior, and reference the appropriate image files for the various icons, backgrounds, and other UI components.

3) These files are exported to the current user’s Windows® temp directory in a folder named with the following format:
pz_<5-RandomLetters>

Also, a properties file will be exported to the temp directory in the following format:
pz_<5-RandomLetters>.properties

4) BlackBerry Theme Builder then compiles these files into the theme COD file and stores that COD in another folder in the Windows temp directory with the same naming format.

5) BlackBerry Theme Builder then copies the COD to the defined output directory along with the required installation files (JAD, ALX etc) and deletes the two directories created in Step 4 from the file system entirely.

By now you should have a good idea of how BlackBerry Theme Builder figures out which devices should be supported and what happens in the theme export process behind the scenes. This should serve as a good base for the next section where we go into how to actually interrupt the build process for BlackBerry Theme Studio to create themes for devices that are not originally supported. Stay tuned for part 2 of this blog post series!

Got any questions about building BlackBerry themes in the meantime? Let us know in the comments!

There are many great things about developing for the BlackBerry platform – including our commitment and support of open source technologies and multiple development languages (Native, HTML5 with BlackBerry® WebWorks™, Adobe® AIR®, Java®). One thing we’ve really invested in over the last year is to respond to developer feedback and requests, in order to enable you to build the way that’s best for you. One of the areas we’ve been focusing on especially is code signing.

What is Code Signing anyway, and why does BlackBerry code sign?

Code signing has been designed to provide security for consumers. They can feel confident that the application they are installing has not been modified after it was signed by the application developer. Code signing is also a means for applications to protect their data.

Code signing has many benefits for both developers and consumers. Developers can distribute an unsigned version of their application along with a debug token to a limited set of beta testers. The debug token helps to ensure that only those beta testers that a developer has issued a token to can run the application. I’ll walk through this process in more detail in a future blog post.

Debug tokens also allow for central key management, allowing for a single code signing key to be used by a team of developers testing an application. Debug tokens can be issued to each developer, allowing them to test builds on their BlackBerry® PlayBook™ tablet. The code signing key can be deployed to a secure build server, protecting it and ensuring that only official builds of the application are signed for public distribution.

BlackBerry® Tablet OS applications each have their own sandboxed private data area that only the application itself can access, which is protected in part by the code signing key. This can prevent a malicious application from impersonating another application. If a malicious application – signed with a different code signing key – were to attempt to masquerade as an upgrade to an existing application the user has installed, it would install it as a new, unique application and it would not have access to the private data area of the original application. This makes it important to back up your code signing key because if you lose it, you’ll be unable to provide upgrades to your application.

Data protection isn’t just limited to BlackBerry Tablet OS applications. BlackBerry® 7 OS (and lower) support similar data access control through the use of a custom code signing key. You can read all about that here.

What We’ve Been Doing over the Last Year

We’ve made a number of improvements to code signing over the last year and we will continue to build on this in 2012. Here is a rundown of what we’ve done so far:

• Made code signing keys easier to obtain by removing the credit card requirement for ordering them
• Reduced the order time for code signing keys from 7-10 days to approximately 1-2 hours so you can start building right away!
• Created Configuration Wizards to walk you through configuring and backing up your keys
• Automated many previously manual steps by integrating Debug Tokens into the SDKs
• Updated the hardware for our code signing servers
• Created the Code Signing Supportsite to walk through the ordering, configuration and signing process

This is by no means the end of the road when it comes to improvements. The golden age of code signing will arrive when you can request keys instantly from the SDKs themselves and have the tools take care of all the dirty work for you. We’re actively re-writing the code signing infrastructure to accommodate this in the future.

The Future Is Secure AND Easy

These are just some of the major benefits that code signing provides. Of course, in any situation, the benefits have to outweigh the effort. We hope to achieve a near zero effort for code signing for both developers and consumers.

Got questions about the code signing process? Let us know in the comments!