Posts Tagged ‘WebWorks’

Ryan R

Getting Started with BB10 Development

Tuesday, July 17th, 2012

BB10 is expected to power the next-generation of RIM handsets and tablets. With four different development approaches supported, many people may wonder which approach is right for them.

The development options avaliable to BB10 developers each have pros and cons, but many developers will want to jump into development as fast as possible. To get up and running quickly, you may want to choose a path that is the most similar to your current style of development.

 

What type of developer are you?

 

 Web Developers

Web developers will feel right at home with WebWorks. WebWorks is a runtime which bundles HTML, JavaScript and (eventually) native plug-ins into a native BB10 application. Along with the provided WebWorks JavaScript API, you are free to use most of the web technologies you are already comfortable with.

 Adventurous Web Developers

If you don’t want to feel too comfortable in your new development environment, consider jumping right into Cascades. While the initial learning curve may be steeper for those without C++ experience, the payoff will be big when you realize how transferable your JavaScript skills are. Cascade applications can be created completed in QML (a declarative language used to construct UI) and JavaScript, with minimal C++ code to glue it all together.

Flash Developers

Like the PlayBook, BB10 can run Adobe AIR applications. ActionScript developers can use the same Adobe tools they are comfortable with and publish their AIR apps right onto a BB10 device with minimal effort.

Java Developers

Java Developers may find themselves torn when migrating to BB10. The only supported path to write in Java is by taking advantage of the Android Runtime bundled into BB10. However, this path should only be considered for Java developers with extensive Android experience as it has some  big drawkbacks. The biggest one being that the Android Runtime is limited to to apps built on the Android 2.3 SDK. The Android 2.3 SDK was built first and formost for Android phones, and is now almost two years old.

In my opinion, the best path forward for a Java developer wanting to get started on BB10 is to jump headfirst into Cascades development. As with the others who aren’t as comfortable with C++ there will be a learning curve, but you’ll find a lot to like about Qt (which Cascades is built ontop of) and QML.

C/C++ Developers

Anyone who’s already familiar with C or C++ should definitely jump into native development on BB10. Those comfortable with low-level C may even want to stick with it by using the NDK, especially for Game Development. Otherwise, Cascades will development will be very easy to get into, and those with Qt experience will have an even easier time. The biggest task for developers familiar with C or C++ will be exploring all the components provided by the Cascades UI library.

Porting Tips

For those lucky (or unlucky) enough to have a pre-existing code base they intend to port, the development path will depend on the original platform. Below are some additional tips for developers looking to bring over various types of projects to BB10.

WebWorks for PlayBook for BB7 (and below)

WebWorks applications built for BB7 or Playbook OS will require minimal changes to prepare for BB10. The most important change is that neither Java and ActionScript plug-ins are supported on BB10, and will need to be rewritten as (C/C++) native plug-ins.

WebOS Applications

Developers with exisiting WebOS projects can migrate them successfully to WebWorks with some reworking. WebWorks uses pure HTML and CSS to style its UI and doesn’t rely on any native elements, to reproduce the look and feel of a Cascades application in WebWorks check out the BBUI project: https://github.com/blackberry/bbUI.js/ Most functionality proviced by Enyo is provided by the blackberry object in JavaScript. 3rd party libraries, like jQuery, are recommended to fill in the missing pieces, more informaiton can be found here: https://developer.blackberry.com/html5/documentation/ww_developing/porting_webos_apps_1952251_11.html

 OpenGL-based Games

With BB10, the NDK is provided to write code completely in low level C. This, with BB10′s support for all POSIX compliant libraries, makes BB10 a great target for porting OpenGL games written in C or C++.

C Libraries

Similarly C libraries should be very easy to get compiling on BB10.

Qt Applications

Qt developers will find that QtQuick has been replaced. Existing applications will have to be adapted to the components and architecture of Cascades UI. Currently drawing shapes is not supported and only Cascades UI elements can be drawn onto the screen. Luckily Cascades supports a component called ForeignView, which can be used to drop down to the use of OpenGL drawing operations.

Android Applications

For those that do have existing Android 2.3 applications targeting the Android Runtime should take a minimal amount of effort. This is provided that your application isn’t heavily reliant on the Google Play store, or a few sensor APIs which the Android Runtime for BB10 does not support. See this API support guide for more information: https://developer.blackberry.com/android/apisupport/ .

 Everything Else

Finally, many multi-platform development toolsets like Unity and Appcelerator have begun to announce support for BB10. With these plethora of options avaliable to developers, BB10 is promising to be one of the most flexible and developer friendly mobile platforms to develop for.

 

oliverm

BlackBerry Hackathons – Come out and Play(Book)!

Wednesday, May 16th, 2012

I’m currently in Bogotá, Colombia taking part in my third Hackathon on behalf of RIM. These hackathons are two-day events where local developers get the opportunity to interact directly with experts in PlayBook development. They also get a free PlayBook just for showing up!

We typically have a team of three experts covering AIR, HTML5/WebWorks and Native development. Most of the events have been focused on game development, but I’ve also done one centred around business apps using WebWorks.

Developers, either in teams or individually, work some long hours over the two day period. At the end of the second day, their apps are judged and winners awarded additional prizes. Nothing like a bit of competition to bring out the best in a dev team!

And with BB10 on the horizon, there’s a lot of anticipation from developers. Keep your eyes open for an event coming to your city this summer. Hope to see you there!

Rod Nolan

Debugging WebWorks applications using the PlayBook simulator and Google Chrome

Saturday, September 24th, 2011

By: Rod Nolan

I encountered an error recently while working on a WebWorks project. So I broke out the PlayBook WebInspector (aka Developer Tools in Google Chrome) and got to work… sort of.

In case you haven’t discovered this yet, to use the debugging tools in Chrome, you just launch your application in the simulator and then open Chrome and connect to the simulator over port 1337 (http://{simulator IP address}:1337).  You should see a simple page with a single link and when you click it, you’re connected to the running application.

Connecting to the PlayBook WebInspector

Connecting to the PlayBook WebInspector

This usually starts the Developer Tools in Chrome complete with Console, Script Debugger, Profiler and all the goodies you know and love. But this time around I got a nearly empty page… a blank toolbar area and the toggle buttons at the bottom of the page that didn’t work.

Where are the Chrome Developer Tools?

Where are the Chrome Developer Tools?

Hmm, this worked last week?! What changed?

I confirmed that the Chrome Developer Tools worked as expected with a regular public web site.

Then I tried a different version of the PlayBook simulator since I have two:

  • version 1.0.1 (from the BlackBerry WebWorks SDK for TabletOS 2.1.0.6)
  • version 1.0.6 (from the blackberry-tablet-sdk-1.1.0)

But both simulators produced the same result.

Maybe it was Chrome? You probably know how Google Chrome just silently updates itself without asking. (Can software be arrogant?)

The solution turned out to be this:

  1. Completely uninstall Google Chrome.
  2. Go find an installer for an older version (oldapps.com).
  3. Install it and get back to work.
PlayBook WebInspector works as expected in Chrome ver13

PlayBook WebInspector works as expected in Chrome ver13

Happy debugging. But keep that Chrome (Lucky 13) installer around and be ready to undo the auto update.

Thanks to Oliver Merk, NTG principal Consultant, for discovering this fix.

oliverm

A Date with SQLite

Thursday, August 11th, 2011

By Oliver Merk – Principal Consultant

Been doing a lot with SQLite lately (sqlite.org) on the PlayBook and elsewhere and wanted to pass on a few quick notes.

First, SQLite columns are typeless.

What?

Yup. Even though you may declare fields as VARCHAR or DATETIME, you may actually store any type of data you want in them. The exception to this rule is for PRIMARY KEY fields declared as INTEGER.

I’ve found that typeless fields can lead to some problems when storing and retrieving date values. I suspect that minor version differences in SQLite are returning different CURRENT_TIMESTAMP values.

Here’s an example of some SQL which creates a table with a date field:

CREATE TABLE location (
    location_ID INTEGER PRIMARY KEY NOT NULL,
    name VARCHAR,
    latitude NUMERIC NOT NULL,
    longitude NUMERIC NOT NULL,
    addDate DATETIME DEFAULT CURRENT_TIMESTAMP);

If I INSERT a new record without specifying the addDate value, SQLite will default to inserting its CURRENT_TIMESTAMP value to populate the addDate field and I get something like 2011-08-11 12:05:10.

But if I decide to explicitly use CURRENT_TIMESTAMP in my insert statement, the value gets stored in an odd-looking decimal format. For example, 2455769.105023148.

Depending on the SQLite version, I may or may not be able to convert the returned date field using JavaScript’s date parsing functions for fields inserted with CURRENT_TIMESTAMP:

Client SQLite version Format Supports JS Date parsing
Chrome (Win) 13.0 beta 3.7.6.3 NO
Firefox (Win) 5.0 3.7.5 NO
PlayBook AIR Runtime 3.7.3 YES

My concern is that the code which now works with the PlayBook might break when it gets its next SQLite update. Guess I’ll burn that bridge when I get to it.

I should also mention a great Firefox add-on called SQLite Manager that allows you to manage these databases.

Oh, and how did I get the SQLite version?

SELECT DISTINCT sqlite_version() AS version FROM sqlite_master;

I’ll leave the rest up to you…

oliverm

jQuery Mobile With WebWorks Gotcha

Monday, June 6th, 2011

By Oliver Merk – Principal Consultant

Since RIM’s WebWorks platform for the PlayBook is based on HTML5, it’s natural to use a popular JavaScript framework such as jQuery Mobile. One thing to be aware of when creating a WebWorks app in this way is that the jQuery Mobile framework relies on AJAX calls to load pages. When your HTML is hosted on a server, this works great. But when running a WebWorks application you’re actually running off the file system, where the URL starts with file:///. If you try to link from your main index.html to another HTML file using jQuery Mobile, the browser throws an error: XMLHttpRequest cannot load file file:///… Origin null is not allowed by Access-Control-Allow-Origin. If you run your HTML in Google Chrome and open the Developer Tools (Ctrl-Shift-i), you’ll see this error in the console. jQuery Mobile pops up a quick error message as well: Error Loading Page.

Basically, the AJAX call is failing because the browser is considering a file request as though it were a request to another domain and prevents it, for your own safety and security.

The remedy for this is to create all of your jQuery Mobile “pages” in one file. That is, having multiple page tag sets in your index.html file:

<div id="faq" data-role="page">...

To “go to” these pages requires that your anchor tags point to the id of the “page” you want:

<a href="#faq">FAQ</a>

Of course, this becomes a bit unweildy for larger applications since all layout now has to be in one file.

I’ve seen this problem reported as a Chrome bug, so it could really be a WebKit problem. Hopefully this will get fixed soon and find its way into the PlayBook’s WebKit-based browser.

Please comment if you’ve run into this or found another solution.

oliverm

BlackBerry PlayBook Developer Links

Sunday, May 29th, 2011

By Oliver Merk – Principal Consultant

General

Developing Adobe AIR Application for PlayBook

QNX Components for AIR apps

WebWorks (for PlayBook)

HTML5

NTG Training Courses