I’m super excited to be presenting three sessions at BlackBerry Jam 2013 in Orlando next week! As a former 3^rd party developer I’ve had the chance to attend several BlackBerry events over the past couple of years. Now that I’m working on the Developer Relations team I’ve got the opportunity to not only attend these awesome events, but also present some killer content to my developer friends!

Here’s what I’ll be doing next week:

Are you building an app which requires a solid database of venues, and an amazingly easy API to interact with? Myself, Erin Rahnenfuehrer, and Kyle Fowler of Foursquare will be presenting JAM37, “Building context-aware applications by leveraging the power of Foursquare APIs”.

Looking to make to most out of your app by connecting it with all the big name social networks like Foursquare, Twitter, Facebook, and LinkedIn? Again, myself, Erin Rahnenfuehrer, and Kyle Fowler will be presenting JAM52, “Get Social: Connecting your app to Facebook, Twitter, Foursquare, and more!”.

Are you trying to make the most out of your BlackBerry World app reports? Jerome Carty, the creator of Blaq, and I will present an in-depth look at how to measure the success of your app using BlackBerry World Reports, and enhancing them with Distimo Analytics.

Which sessions are you looking forward to the most?  Let me know on Twitter (@chadtatro), and I’ll see you in Orlando!

We’ll be continuing this video series leading up to BlackBerry Jam Americas in Orlando in order to give some more background surrounding the topics that we’ll be discussing in detail during the conference.

This particular video will give you some information about the upcoming roadmap items that we’re looking at for WebWorks and HTML5 developers. We’re joined by Erik Johnson from the WebWorks R&D team to talk to us about Apache Cordova and the evolution of the BlackBerry 10 Web Platform!

The reason for this is that the container housing the content isn’t hardware accelerated by default; we can fix this simply by adding the -webkit-overflow-scrolling: touch; CSS property and instantly see the improvements:

• Smoother scrolling and support for much larger content sets.
• Visual bounce effect when scrolling at the edges of the list.
• More responsive touch / tap interactions.

It’s incredible; the difference that hardware acceleration makes. With one CSS flag you can leverage the power of the GPU within your applications too!

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

Now with 4500% more unique peaks and valleys.

On November 2nd, PeaksAndValleys 2.0 was uploaded to Github with a number of improvements. In the first release, we relied on a static map that was 150 by 150 vertices (22,500 total vertices.) When we’re talking about a map, we’re just referring to a grid of vertices where each vertex has a specific height.

Bird’s eye view of a 33 by 33 vertex grid (map); each vertex has a specific height associated with it.

These 22,500 vertices were all generated during startup with randomized heights. It was a good initial implementation, but subject to a number of limitations:

• Maybe we want a fixed / persistent world to traverse.
• We can’t expand the map much more due to performance reasons.
• If the player runs in any direction for long enough, they will hit the edge of the map.

Let’s take a look at each of these individually.

Fixed / Persistent World

One of the more common approaches to this problem is the use of a static source of data; in our case, a height map. This is the approach opted for in PeaksAndValleys 2.0. The following is an example of what a height map might look like:

Sample height map (originally 1024 by 1024 pixels).

Each pixel represents one vertex (or point) of the map, and the RGB colour of that pixel is used to determine the height of each vertex. In the case of PeaksAndValleys, the lowest height occurs at pure black (RGB = 0×000000) and the highest height at pure white (0xFFFFFF).

Though the height map is only 1024 by 1024 pixels, we can apply a scaling factor to extend the map across larger distances in our WebGL world.

Depending on how smooth the source image is, we may get areas where there is a very low region next to a very high region. To prevent drastic changes in terrain, a smoothing algorithm was implemented that averages the height of each pixel with that of its neighbours.

And with this, we address the fixed / persistent world by using a static data source. We can quickly see how multiple height maps and randomized starting locations can expand the versatility of this approach.

Performance

As noted, the first release of PeaksAndValleys contained a static 150 by 150 vertex area and expanding to a larger number of vertices would have an impact on performance; so then what good is a 1024 by 1024 height map?

In our case, we’re actually only loading a 121 by 121 region at any given time. As the player traverses the terrain, we are continuously reloading the surrounding region data (with the player at the center.) This means that as the player moves around, terrain in their vicinity is continually loaded from the height map.

There is a lot of processing that needs to go on in order to keep loading terrain — so much that if we do this processing on the main application thread, we’ll see a drop to roughly 30 frames per second. This is where Web Workers come in, for which the implementation can be seen in GLTerrainWorker.js.

A Web Worker allows a separate thread to perform actions without interfering with our main application thread. Our main application thread is where all of our interactions and rendering are performed, so if we can minimize the work being done there, we can improve our frames per second and responsiveness.

Web Workers aren’t without their limitations. Specifically affecting us, we cannot:

• Access the DOM. This eliminates WebGL rendering directly on the Web Worker.
• Pass objects with functions between the main application thread and Web Worker.

These two limitations mean that while we can perform our processing on a Web Worker, we actually need to pass the processed data back to our main application thread in order to update our rendering objects. We do this via the onMessage listener and postMessage initiator to initialize our Web Worker with the data it will need, and then pass subsets of that data at various intervals. You can see this initialization and rendering update performed in GLTerrain.js.

By offloading this processing to a Web Worker, we can continuously load more data off the main application thread, and only pass back the final data results to be assigned to our renderers. The end result is increasing our frames per second from roughly 30 to 50-60 frames per second; a huge win. To learn more about Web Workers, the following HTML5 Rocks tutorial is a great starting point.

Seamless Terrain

The final issue we had with our 150 by 150 static area was that when you run to the edge of the map, you hit the border. Loading data from a larger 1024 by 1024 area certainly extends the time before the player hits the border, but inevitably they will if they keep moving in one direction.

To counter this, the application continuously loads an area of pixels surrounding the player. As you reach any of the edges, data from the opposite side of the map will we used to populate that area. This produces a continuous terrain, even when travelling near the edges of the map.

Red cross represents the location of the player, white area represents the data we’ve loaded.

By wrapping the data that we load as we get close to the edges, we can in essence allow the player to run forever. You may notice that this image isn’t intended to be seamless (i.e. when wrapping around, the colours at the borders do not match up or flow together). This can be overcome by using a height map that is already seamless (i.e. it has already been processed to ensure that the pixels on the north side match those on the south, and those on the east match those on the west). In the case of PeaksAndValleys, our smoothing algorithm was implemented to wrap around the image when necessary (i.e. at the edges), thus turning non-seamless images into height map data that is seamless.

Preprocessing Data

To obtain usable height map data, we must:

• Read a source image; in our case 1024 by 1024 pixels.
• Perform height calculations.
• Calculate the normal (perpendicular vector) of each point.
• Calculate texture coordinates.

This involved quite a bit of math and processing power. Mathematical calculations are an area where JavaScript performance has historically suffered. Attempting to perform these actions while the application loads leads to a PC load time around 5 seconds and a mobile device load time around 20-25 seconds.

This also means that we are re-calculating data on every load just to get the same result as our previous run — a very inefficient approach.

To address this, a Node.js preprocessor tool was created that reads in an image, along with some parameters, and generates a json file with the resulting vertex, normal, and texture data required by our WebGL application. On a 1024 x 1024 image, the resulting file is roughly 50mb in size. Originally, this file was closer to 120mb, however by truncating decimal points to 5 significant digits the overall size was reduced.

As a result our application doesn’t actually process any data on load. Instead of feeding in an image, we are now feeding in the output json file with all calculations already in place. That being said, we are still loading a 50mb file which does take some time, but now we’ve managed to cut the loading time closer to 5 seconds on a mobile device.

Using preprocessed data also minimizes the amount of work the Web Worker has to do, as it will simply retrieve the appropriate data based on the user’s location and pass that data back to the main application thread.

Summary

Ultimately, PeaksAndValleys has seen a large number of improvements in the terrain implementation. From preprocessing / generating seamless height maps to leveraging Web Workers and minimizing strain on the main application thread, we now have a much more versatile world.

There are still some issues such as terrain popping into view as you move about. There is also room for optimization by only loading a cone of data in the player’s field of view (as opposed to a square in all directions around the player). These are topics that will be addressed in the next release.

For more information on this project, be sure to check out the Github release. Feel free to leave questions there, or reach out to me directly on Twitter® via @WaterlooErik.

Guest post from Nukul – Ed.

We’ve received a lot of requests from developers to be able to build BlackBerry® 10 WebWorks™ directly from GitHub. Before I talk about how to take advantage of this, I would like to explain why it took us so long to get here and what it means for you.

The main issue was that the latest BlackBerry 10 WebWorks SDK features were dependent on features in the BlackBerry 10 OS. Therefore, if you built BlackBerry 10 WebWorks in open source, it potentially would not work with latest BlackBerry 10 OS beta.

This has changed as we get closer and closer to launch. We are now starting to work on features that are not dependent on the latest BlackBerry 10 OS beta. Imagine this: You hear about an awesome new feature or extension we are working on. You can now go to our GitHub repositories, look at pull requests, pull down the branch, and a few minutes later you have a BlackBerry 10 WebWorks build with the new extension or feature.

Build time can be less than two to three minutes from a clean build. From the time you see someone’s tweet about an awesome new feature, it could take you less than five minutes to get a build of BlackBerry 10 WebWorks that has that feature.

The advantages to a BlackBerry 10 WebWorks app developer are infinite here. You should never need to wait for new features. You can even build with Linux! It’s all there. There will still be some features that you will need the next OS release for, but that will happen less frequently as we get closer to launch of BlackBerry 10.

Here are the two repos you need to build to get ready to take advantage of this:

https://github.com/blackberry/BB10-WebWorks-Framework

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

The framework repo contains the Framework that is packaged with your app when you build a BlackBerry 10 WebWorks app. The Packager repo contains all the code for the packaging tool.

There are two main branches in each BlackBerry 10 WebWorks repo: master and next. The master branch will contain all the features that you can currently use with the current publicly-released OS — think of it as the features we wish we had time to get into the previous release. When a feature is completed, it’s merged into master if does not have any OS dependencies. The next branch will contain the new features that have OS dependencies.

To allow developers to easily build stable versions, each release is tagged using the version number of the release. This allows you to easily check out the source of a particular release. You can simply use the tags to check out the code from that release. For example, you can use “git checkout v1.0.2.9” to pull down the code for the last release. So, any pull request you see going into the master branch, you can grab and use right away. You will see none open today, but over the next couple of weeks you should start seeing many.

The README.md has been updated with all the updated instructions.
Run the unit tests, automated tests, all the developer tools we use are all available to you.

We are doing everything we can to enable developers to take advantage of our latest and greatest work. Just open an issue on our repo when you find an issue with our BlackBerry 10 WebWorks SDK. If you fix a bug or build an awesome extension, contribute it back and help us make BlackBerry 10 WebWorks SDK even better. For details on how to contribute, check out http://blackberry.github.com/howToContribute.html

We recently had Mark Robinson contribute changes to make SDK work on Linux — contributions like that go a long way. Be sure to see our growing list of contributors!

You can reach me any time on Twitter® @nukulb or send me a message through GitHub.

The BlackBerry® Developer Relations will be at the Sprint Open Solutions Conference to help you with porting your existing Android™ or HTML5 application for the BlackBerry® PlayBook™ tablet and our upcoming BlackBerry® 10 platform. The Sprint Open Solution Conference runs on Wednesday, October 24th and Thursday, October 25th at the San Jose Convention Center in beautiful downtown San Jose.

Are you ready for #SprintOSC12?Have you registered?It’s not too late! Reg NOW! ow.ly/eBVv6

— Sprint Dev Program (@SprintDeveloper) October 21, 2012

Stop by our booth to port your HTML5 and Android apps to the BlackBerry 10 platform and the BlackBerry PlayBook tablet with few or no required code modifications. We’ll have porting experts on hand to help, and the first ten developers to get their app running on a BlackBerry 10 Dev Alpha testing device and submitted to the BlackBerry App World™ storefront will be given a BlackBerry 10 Dev Alpha testing device on site. Plus, if you get it running on the BlackBerry PlayBook tablet, you could receive 1 of 100 free BlackBerry PlayBook tablets — and once your app is on the BlackBerry PlayBook tablet, it can be easily ported to BlackBerry 10!

Want to get a head start?

1. Register for BlackBerry App World – Become an official BlackBerry developer.
2. Request signature keys – Ensure you select for BlackBerry PlayBook OS and BlackBerry 10 and higher. Downloading in advance is strongly recommended as the time involved to do so on site could prevent you from competing for Alphas.
3. Get the BlackBerry Tools and Plug-ins – Get your laptop set up with the right tools so you can begin creating apps for BlackBerry 10.

In addition to our Porting Booth, our own Larry McDonough is presenting the session “Mobile Monetization with BlackBerry – What Developers Need to Know” on Thursday, October 25th at 2:30pm PST in room 210G. This presentation will cover the different methods for monetizing mobile applications on BlackBerry devices. Larry will cover NFC, in-app payments, advertising, “freemium” apps, and carrier billing. This discussion will also consider how to prepare and market your app through a mobile app marketplace like BlackBerry App World.

See you in San Jose!

On Thursday, October 18^th user groups around Los Angeles are organizing an event for all to come and learn a little more about this thing we call mobile development – Mobile Camp LA. Regardless of what floats your boat (game development, UI frameworks, cross-platform strategies, etc.) there are sessions for everyone.

In addition to these sessions (including an in-depth look at the Ripple tool by our very own Gord Tanner), we’ll be having another kind of activity that runs throughout the day. Once again we’ll be out in the community providing developers who are serious about getting their apps on BlackBerry® 10, with the opportunity to take home a BlackBerry 10 Dev Alpha testing device.

How do I qualify?

I’m glad you asked. First, you’ll need to have an application that you’ve developed using PhoneGap and you’ve already taken to market outside of BlackBerry App World™.

Next, you need to bring your application source (or an already compiled BAR file) and we’ll get it up and running on a BlackBerry 10 Dev Alpha testing device. If all goes well, we’ll have a station on hand where you can submit the newly created application to BlackBerry App World, and you get to walk away with the device!

If there are obstacles, well that’s what we are there for and we will do all we can to assist you in overcoming them on site and getting your app submitted. If they cannot be addressed on site, we will take your contact information to provide continued support after the event.

Most importantly, you need to be one of the first ten developers to do so!

What can you do to speed up the process and get your hands on one of these devices and  back to the conference and sessions as quickly as possible?

• Pre-register as a BlackBerry Developer in the BlackBerry App World Vendor Portal. The entire process is free.
• Request your BlackBerry Code Signing Keys in advance.
• Have your laptop, application source, and development tools ready to go.

For those that haven’t heard, obtaining a Blackberry 10 Dev Alpha testing device will be one of the steps to a limited edition BlackBerry 10 smartphone after the launch in Q1 2013 – details to follow. Submissions received will also be eligible for the 10k Developer Commitment!

When the BlackBerry 10 Dev Alpha testing devices run out, we will be entering other developers who visit us at the booth in a raffle to win BlackBerry® PlayBook™ tablets. Remember, if you can get your app working on BlackBerry PlayBook, it can easily be ported to BlackBerry 10.

We’ll be there throughout the conference to assist PhoneGap developers with their porting, so be sure to plan out the sessions you want to see accordingly. To get a better idea of what’s being offered, be sure to visit the Mobile Camp LA event page.

See you on Thursday, fellow devs! Follow me on Twitter for updates at @WaterlooErik.

So how do you actually go about integrating features from these services into your application?  First the needs to allow your application access to their profile, and this bring us to Open Authorization – better known as OAuth.

OAuth you say?!

OAuth is an open standard for authorization used by tons of popular services, foursquare, Twitter, and Tumblr, to name a few.  It allows applications to connect their users to these services without having to handle their username and password.

There are a couple versions of OAuth which we have created sample apps for.

OAuth 1

Let’s be honest, OAuth 1 can be darn right nasty to work with out-of-the-box.  OAuth 1 and I are not really good friends, we’ve had many fights over the past year, and often I’ve been on the losing side.  In a nutshell, the way OAuth 1 works is by having an application perform a series of requests to a service, exchanging “tokens”, and ultimately granting the application access to the service on behalf of the user.  It requires several things to go just right, and if something doesn’t, access is denied.

Luckily there is a really awesome open-source JavaScript library written by Rob Griffiths (@bytespider) called jsOAuth. JsOAuth takes the pain and extensive process of OAuth 1 away, and allows you to focus on connecting your app with a service such as Twitter rather than spend a ton of time working with the OAuth 1 protocol.

OAuth 2

While OAuth 1 is my adversary; OAuth 2 is my best friend.  This is the next evolution of the OAuth protocol and is used by services like foursquare, and Facebook.  OAuth 2 is much friendlier for developers to integrate into their apps, and provides much easier, and straight forward authorization “flows” to work with.  Though the standard is still evolving, it’s solid, and in contrast to OAuth 1, is amazingly easy to work with.

The Sample Apps

Getting started with OAuth can be pretty intimidating to say the least.  As a former 3^rd party developer, I’ve been there.  I’ve screamed at my console log, cried like a baby, and even begged the OAuth gods for it to “just work”.  Since joining the BlackBerry® Developer Relations team here at RIM®, I vowed to help make this process easier for fellow developers and I’m glad to finally say that we’ve released two sample apps on GitHub today to help guide you on your OAuth journey.

The first sample app shows how to integrate Twitter into your application by using the OAuth 1 protocol.  You’ll learn how to quickly and painlessly authenticate with Twitter, and post a Tweet to a user’s timeline by taking advantage of the jsOAuth library.

The second sample shows integration with foursquare, and uses OAuth 2.  It’ll show you how your application can authenticate a user with the service, search for near-by venues, and then check-in to a venue.

The third sample shows how to integrate Facebook and OAuth 2 into your application.  You’ll learn how to authenticate a user with Facebook, and interact with their feed by posting, and reading content.

Each of these samples are completely Open Source, and available on GitHub.  If you find them useful, have any feedback, or need an extra helping hand along your way find me on the BlackBerry Developer Support Forums or Twitter @chadtatro.

In honor of 10/10 and the opening of BlackBerry App World™ for BlackBerry 10 app submissions, we’ve put together a list of the 10 most viewed blog posts in the developer blog about BlackBerry 10. It’s been an eventful couple of months! Check out how far we’ve come:

1. BlackBerry 10 Cascades™ is here!
2. Introducing Built for BlackBerry and the $10K Developer Commitment
3. Standardizing on Screen Resolutions for BlackBerry 10 devices
4. The BlackBerry 10 Native SDK Experience
5. BlackBerry 10 WebWorks™ SDK Released!
6. BlackBerry 10 – The Evolution from Beta to Gold
7. Flight Arrival Boards have been posted!
8. The BlackBerry 10 User Agent String Has Arrived!
9. BlackBerry 10 Samples Galore
10. Creating Outstanding Apps with bbUI.js – Community Tutorial

Now, you can submit your app to the BlackBerry App World for BlackBerry 10.

What was your favorite BlackBerry 10 related blog post? Share with us in the comments below!