Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Web and WebWorks Development

Reply
New Developer
pnewhook
Posts: 70
Registered: ‎01-13-2011
My Device: Torch 9800 and Playbook
My Carrier: Rogers

A Response to Jamie Murai's Post and RIM's reaction

Fellow developers and RIM employees, I really want to respond to the series of blog posts about the Playbook WebWorks development process. You may have come across these posts, but if you haven’t, I suggest reading Jamie’s post (http://blog.jamiemurai.com/2011/02/you-win-rim/) then Tyler’s response (http://devblog.blackberry.com/2011/02/thanks-for-the-open-letter-to-rim-developer-relations/) before reading on.

 

First and foremost Jamie makes a lot of good points, and seems to have sparked action from the developer relations group at RIM. But when I see managers jumping to action in respond to a single blog post, I get nervous because I don’t want one developer to hijack the community process. Especially a developer that doesn’t appear to have been active on the forums, contributed code, or even created a bug report.

 

I’d like to deal with some of the points Jamie made, then look at Tyler’s respons, then finish with some improvements I think we can all agree on.

 

Jamie’s Post

Jamie is a university student and by the sound of his feedback, wants to get up and running as easily as possible. Fine. That makes perfect sense if you’re just looking to kick the tires on some new tools and see what the development process looks like. But he isn’t looking out for the needs of real developers, and RIM needs to take that into account before jumping to support his requests.

 

 

“You’ve decided that it’s better to make me download the Adobe AIR SDK, the Playbook SDK, and the Playbook simulator in three separate downloads.”

 

 

Because I expect updates to the Playbook SDK and simulator to be released frequently (and not necessarily at the same time), I want to be able to manage all these installs separately. RIM, if this is indeed the reason for keeping the downloads separate, just make it clear.

And having the AIR SDK as a zip instead of an installer is a non-issue. This is a third party tool that a lot of developers already have installed.

 

 

“For some reason, you want me to fill in an entire form of personal information. That’s odd, considering I did already when I first signed up. I guess I’ll give you the benefit of the doubt and assume your database crashed in the interim.”

 

 

Agreed fully with Jamie. There seems to be a lot of different registrations on the BlackBerry developer’s sites. Last I checked I had separate logins for the forums, Developer Centre, App World, webcast registration, and I still get pestered to register when I need to download the SDK. Tyler mentions this should be streamlined by your Developer Center account, but that was far from clear.

 

 

“Next, I go to install the Playbook SDK. For some reason, it thinks that the optimal place to install software on a Mac is my home directory.”

 

 

I can’t speak to the Mac conventions, but every developer I know has a slightly different place they like to put their libraries and dependencies, so trying to figure out where a zip file would have been extracted seems unreasonable. This seems like whining for whining sake.

 

 

“Oh, I forgot to mention that you also told me I had to download VMWare Fusion to run the simulator. Nothing says user friendly like making me buy an additional piece of $80 third party software to run YOUR simulator.”

 

 

No question, that’s annoying. Why did RIM decide to go with VMWare instead of the excellent open source Virtual-Box?

 

 

“The docs say that I need to install the .iso image into VMWare, but the file I downloaded from you was an installer?”

 

 

Really Jamie? Is this such a roadblock?

 

 

“So I click the nice little Play button inside VMWare, and am greeted by what I perceived to be a 1000000000 page license agreement in a DOS-like console window.”

 

 

The documentation is actually for the first release of the simulator and doesn’t cover this license. It should be mentioned that you can jump to the end of the agreement (though of course you always read the whole thing) by hitting ‘q’.

 

 

“First up, I have to put the simulator into development mode, which makes total sense because of those times when you don’t want to use the simulator for development.”

 

 

I want the simulator to behave exactly like the actual device. I’m assuming the actual playbook won’t start in developer mode, don’t start my simulator that way. Though I should say, I would like to set an option to start in developer mode by default.

 

 

“Your docs now tell me that before I can create the application package, I need to first create an application archive. Ok, that sounds alright with me, because obviously you’re going to tell me how to do that. Wait, you’re not going to tell me how to do that?”

 

 

If this is confusing, I fear Jamie is going to really struggle with actual development.

 

 

“If you are developing for iOS or Android, you can replace the entire preceding two paragraphs with one sentence: Press the button that says Build and Run (or the equivalent button within Eclipse for Android).”

 

 

For the love of god, don’t make my build process depend on pressing “Build and Run” in and IDE! Don’t get me wrong, I use Eclipse for 99.9% of my Java development and Visual Studio for 99.9% of my .Net work so I get the productivity benefits, but web development is a different beast altogether. There are so many preferences that people have when doing web development that forcing everyone to use one common environment is bound to incite holy wars. Command line utilities are a reasonable common denominator.

That said, the command line utilities themselves are a little clumsy. I’d like to see the process made a little easier by some higher level build scripts in the shape of batch, or powershell, or bash scripts. I’ve put together a handy little Ant script myself that works quite well.  You can find it in my forked GitHub repo, https://github.com/pnewhook/WebWorks-TabletOS-Contrib.

 

 

“This afternoon, Google Notifier informs me that I’ve received an email from you. Naturally, I assumed that it was just a confirmation that my App World account had been approved, considering I had filled out your forms truthfully and completely, just as you had asked. However, I was surprised to find that it was, in fact, a request for more personal information. You wanted me to print off a notarized statement of identification form, fill it out, take it to notary with government issue ID to have it notarized, and then return it to you so that you could be absolutely sure with 100% accuracy that I was who I said I was.”

 

 

Jamie’s spot on, the notary step seems pretty aggressive. Check out the Android registration process, they’ve figured it out.

 

Tyler’s Response

Tyler, I feel for you. You’ve got some developer calling your newest baby ugly. And he’s even from Waterloo! In this hyper-competitive mobile market you can’t afford for developer displeasure to leak into mainstream press and give any indication that there’s anything wrong. So you write a blog post essentially saying ‘We’re working on it.’ Great. Crisis averted and everyone’s happy.

 

One problem.

 

Should I email you every time I run into trouble? Or do I need to get my angry blog post to the top of Hacker News? No, there are already tools for those kinds of things in the forums and bug tracker and GitHub projects. Encourage their use, they’re great resources. Instead of writing a blog post and forcing me to add my thoughts into comment number 45, start a discussion on the forum soliciting feedback. You tell us to use the forums to give feedback, but why does it seem like you’re not there?

 

One other thing that irked me was the number of pain points Jamie’s post seemingly ‘brought to your attention.’ When I’m asking for feedback from the development team, I want to know they’re using the same tools and have experience with the development process. When was the last time you went end to end on a Playbook app? From registering, to development, to deployment.

 

My Suggestions


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 (http://supportforums.blackberry.com/t5/Web-Development/Two-sections-for-playbook-and-phones-in-web-d...), 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. 

 

Thank you very much for making it to the bottom of a very long post. I hope this message doesn't fall on deaf ears. 

Please use plain text.
Developer
billfoust
Posts: 382
Registered: ‎05-19-2008
My Device: BlackBerry Torch
My Carrier: AT&T

Re: A Response to Jamie Murai's Post and RIM's reaction

Excellent post. I wanted to also point out that there is a long thread over in the Tablet OS forum on the same topic. I don't say this to take away from  your post at all, just in the interest of completeness.

 

Bill

 

Bill
-------------------------------------------
Check out my book on BlackBerry Development for Java.
And my other really really old book
My Apps: FlashKids
Please use plain text.
Developer
Accoductions
Posts: 42
Registered: ‎01-18-2011
My Device: PlayBook

Re: A Response to Jamie Murai's Post and RIM's reaction

Mm, excellent objective look at things. This needs to be read by the developer relations team!

Please use plain text.
New Developer
pnewhook
Posts: 70
Registered: ‎01-13-2011
My Device: Torch 9800 and Playbook
My Carrier: Rogers

Re: A Response to Jamie Murai's Post and RIM's reaction

@billfoust The fact that that post is on another board highlights how fragmented Playbook development is right now. Thanks for pointing that out.

 

@Accoductions thanks, I hope Dev relations sees this

Please use plain text.
Developer
pwerry
Posts: 177
Registered: ‎01-21-2009
My Device: 9900
My Carrier: Vodafone

Re: A Response to Jamie Murai's Post and RIM's reaction

[ Edited ]

Posted a response in the other thread

 

Please use plain text.
Contributor
Berryreview
Posts: 17
Registered: ‎01-09-2011
My Device: Not Specified

Re: A Response to Jamie Murai's Post and RIM's reaction

Great analysis pnewhook. Its great to see that developers are not getting turned off by the clumsy tools. I totally agree that these are not big deals but they are things that RIM could probably fix in a few days if they put their mind to it. Actually wrote up an article referencing this post and the other.

Keep up the great work. Hope to see some promising PlayBook apps!

Please use plain text.
Developer
Heiko
Posts: 125
Registered: ‎01-17-2011
My Device: Playbook
My Carrier: Vodacom

Re: A Response to Jamie Murai's Post and RIM's reaction

 

Hi

 

I read this post and relevant articles last night.

This morning when I got to work I still felt annoyed for some reason.

 

Yes, I agree, there are probably lots of shortcomings, things to be fixed, improved, documented and presented better; ... besides adding those build buttons and user interfaces that some people can't do without. (Don't get me wrong I like using IDE's, but sometimes it's also nice to work a bit under the bonnet, get your hands dirty)

 

I expect that RIM's got their hands full, first moving to a new phone OS, and then the new QNX OS and Tablet hardware.

So I'm sure there's lots of stuff for them to work on, and maybe they spent a little less time adding fancy build buttons and more time on building a functional product. - As Jamie mentioned in one of his articles, sometimes it's more important to have a few quality apps that users can relate too, than to just flood the device with countless apps.

 

There's nothing wrong with criticism, but sometimes it just depends on how you bring it across. @pnewhook - well done for evaluating, weighing up, and providing constructive feedback, and not just to rant about RIM's shortcomings.

 

I for one followed the instructions on the web, and had no problem getting things up and running and for any problems, queries, questions, etc. I found the answers on the support sites, or figured them out.

 

Considering that the QNX OS and Playbook are all very new in development and production I tend to be more forgiving if I have to forfeit on an IDE, or a single installer, or jump through some hoops to get things working.

 

I see it as more of a challenge, exciting, pioneering, to be there from the start and watch as things, grow and develop, and hopefully contribute to the development in any way I can, and hopefully grow myself in the process..

 

Kudos to RIM - I've had a great experience so far with many new things to learn (yay!) , especially since I come from a c++ background and had brush up on my javascript/html/css skills. Looking forward to a native SDK, so I can tweak where required.

 

Webworks rocks ! - Was amazed at how easy it was to get an application up and running (compared to the C++ slog work I'm used to :smileywink:

 

Would love to have a C++ backend though so I can combine the simplicity of a web user interface with the performance of native C++ code (if and where required) - and so that I can reuse some existing C++ code instead of having to rewrite to javascript.

 

Now I'm feeling better :smileyhappy:

I assume what was bothering me was that everybody was just criticising and nobody seemed to add anything positive.

Its all in the balance:

 

    Hey RIM you know what - this 'sucks' ! - but hey I've enjoyed using this, and that, keep it up !

 

.Heiko

 

 

 

 

 

 

 

Please use plain text.
New Developer
pnewhook
Posts: 70
Registered: ‎01-13-2011
My Device: Torch 9800 and Playbook
My Carrier: Rogers

Re: A Response to Jamie Murai's Post and RIM's reaction

Hi Heiko, I'm glad you're able to get that out of your system.:smileywink:

 

I too tend to be  a little more foregiving on new products than I may otherwise be. There's a reason it still has a beta tag on it. And without a hard release date it's hard to know exactly where teh tolls should be in their development cycle. I think the March 15th deadline has devs a little on edge, but that's certainly not the product release date!

 

And regarding the C++ bridge I'm 110%. It's been fun to start designing HTML and javascript in a new context, but I'd like to be able to dig a little deeper when I need to. I really like knowing exactly what browser support I will get (compared to regular web development where you have to build to a lowest common denominator) and really embracing the new HTML5 APIs. But I'm struggling a bit with the audio tag because it's just a touch too laggy.

 

I mention 'native' or Java above, but my real fantasy would be to have access to WebGL in WebWorks. There's some crazy impressive things being done in that.

Please use plain text.
BlackBerry Development Advisor
tneil
Posts: 3,708
Registered: ‎10-16-2008
My Device: Z10
My Carrier: Rogers

Re: A Response to Jamie Murai's Post and RIM's reaction

Ah... finally my Blog article went live :smileyhappy:

 

http://devblog.blackberry.com/2011/03/blackberry-webworks-sdk-for-tablet-os-tips/

 

I was waiting for it before jumping into the conversation.  Give it a read, and I'll go back over this thread and see if there are other questions/concerns that I might be able to adress

Tim Neil
Director, Application Platform & Tools Product Management
Follow me on Twitter
Please use plain text.
BlackBerry Development Advisor
tneil
Posts: 3,708
Registered: ‎10-16-2008
My Device: Z10
My Carrier: Rogers

Re: A Response to Jamie Murai's Post and RIM's reaction

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. 

 

Absolutely 100% agree.  We now have our contributor agreements in place and the source code for WebWorks on Tablet OS available.  The contributor agreements finally went up yesterday.

 

We've also been working on build scripts using Maven and trying to make sure we have both JavaScript and Java/ActionScript unit tests in place that can be published and used on your own machine.  We've been working hard at stripping out the internal RIM sauce so that all our continuous builds and testing frameworks work in free familiar open source frameworks.

 

We also have our Contributor's forums open where we are planning on discussing all of the new additional APIs and architecture as we move forward.  You will see some discussions there at the moment.  We also have all the APIs currently under development for the Smartphone platform listed here.  Our first step in this new development is to get the interfaces for these APIs created so that we can post them up and share them with the community to gather feedback, tweaks or changes that should be made before they get their final development work completed to be included in a release.

 

We've also been working through our branching strategies for the project so that we can get much more forward development up in the repo and not just push after the code is released.  We are looking at pushing up code each time a feature is built and internally tested so that it won't break the upstream code.

 

The next major release of the product and source code will be around the middle of march. This will be a major milestone for us because we will have Evacuated all of the WebWorks APIs off of the core OS and into the open source project.  This way 100% of WebWorks code will be in github!!  This will provide us much more freedom for fixing bugs as well as extending functionality to existing APIs.

 

WebWorks is our first open source project at RIM and we are learning as we move forward.  We have also hired on more folks who have experience running open source projects to help us get the WebWorks project rolling like a well oiled machine.  Continuous feedback, collaboration and participation from the community is key to make sure the project is meeting your needs

 

 

 

Tim Neil
Director, Application Platform & Tools Product Management
Follow me on Twitter
Please use plain text.