More Suggestions on Making PlayBook Development Easier



We’ve been getting lots of follow up about PlayBook development since recent posts about the subject and the support forums are sounding off too. One such thread is by pnewhook, who follows up with some of his own suggestions. They’re worth checking out and we’d like to hear yours too. Pnewhook’s suggestions include:

Unify the Playbook WebWorks Community

Why do I get the feeling WebWorks development on Playbook is an afterthought? The forum is shared by WebWorks for general web development, and smart phone development? It’s impossible to search for only information on Playbook WebWorks development. This was brought up in the forums, but there hasn’t been any response from the RIM team.

The Playbook WebWorks webcast series was excellent, but they’re not a substitute for proper documentation.

Get All the Native Functionality and APIs into the Playbook Simulator

The Playbook’s documentation includes the handy Invoke APIs for using the camera, browser, App World, etc., only problem is they don’t work on the simulator. Before you do anything else, deliver a simulator that isn’t neutered of all it’s native apps and functionality.

JavaScript Alone Ain’t Gonna Cut It

I’m not saying an HTML/JavaScript/CSS stack isn’t a great idea but there are times that it isn’t enough, for example 3D and other processor intensive operations. The developer webcasts keep referencing the ability to call into mysterious Java and Native libraries, but until they’re released, they’re obviously not an option. I think everyone’s heard the rumours of Android apps running on the Playbook, and if that’s the direction you want to take with the Java API, fantastic!, one less API I have to learn. But the lack of communication on this front makes me a little concerned for the future of the WebWorks API and feels very cloak-and-dagger.

You’ve got an open source project, Use it

Open source projects are great at soliciting feedback from a technical audience. Just recently, Cedric Buest of TestNG fame was soliciting feedback on a new feature. He wanted to see how developers were using his tool and get the expected behaviour locked in before releasing a final build. He iterated and solicited feedback until he was certain he had the feature his users needed.

Get build instructions and a contributor’s agreement onto the GitHub project. Working on open source isn’t for everyone but for the developers that want to understand the underlying framework, that kind of access is invaluable. Code dumps after the SDK is release isn’t enough, development would ideally be done in the open.

We’ve mentioned this before but the support forums have had a lot of what’s being discussed lately already mentioned. It’s probably due to all the attention that Murai’s post got from Silicon Valley that made RIM want to respond so publicly. Since the support forums are mostly anonymous posters who aren’t getting the same attention, perhaps RIM doesn’t feel the need to directly respond. Feel free to send your dev articles to BlackBerryCool and we’ll help promote them if we feel it would help the community in general.

You can find more commentary over at BerryReview as well.