05-03-2011 12:30 PM
I have begun digging around the WebWorks for Tablet OS extensions code, and was able to build and compile a custom extension into a Playbook app with the direction of @tneil (Thanks Tim!). I will be working on writing a walk through in the next few days, but I wanted to gather information about the best way to approach filling out the WebWorks API for Tablet OS. I for one want access to a much richer API.
I guess my thought is to follow the exact same API structure of the standard WebWorks API used on BB phones (https://github.com/blackberry/WebWorks-API-Docs -- This includes docs for both WebWorks frameworks), and knock out implementation one by one. However, I started my WebWorks experience via the Playbook (vs WW for phones), so I am not sure how compatible the two frameworks should/can be.
I just wanted to open the discussion and see if there is any interest from other developers in helping build out the extensions availible to WebWorks for Tablet OS.
05-03-2011 08:26 PM - edited 05-03-2011 08:28 PM
You'll likely also be interested in Matthew's thread in the Contributors forum:
Our general philosophy over the summer is to try and bring the two platforms together as close as we possibly can so that there's less confusion on what APIs work on each platform. One of the first steps is the convergence of the API docs like you have mentioned. Also in our Roadmap we are trying to schedule items in each release to draw us closer to this goal by the fall.
This in no way means we are looking to try and create a lowest common denominator between the two platforms..
The general rule of thumb guiding our work is the following:
- If the new functionality proposed will work on both platforms, let's find a common way to make it work
- If the new functionality is specific to the target platform, let's find the best way to make it work on that platform
So basically the common stuff stays common, and the platform specific stuff is directly targetted to take advantage of that functionality in the best way possible.
What we are doing is slotting work/APIs into the different target releases on the roadmap. The scope of these releases are directly proportional to the amount of resources we have to make it all happen. If there are members of the community that would like to take ownership of some new features to add to the bandwidth and scope of these different releases we are more than open to having others help out
Our steps for bringing new APIs to the platform look like the following:
1) Figure out which release the functionality should go into. Then create the proper branches across the repositories (docs, smartphone, tablet)
2) Create a new jsdoc addition/modification to outline what the proposed API should look like, how a user would interact with the API and code samples for the API in the branch created for its release. Really flushing out the use cases to make sure it matches the intended use and provides a web API feel.
We use jsdocs as a collaboration method to describe and solidify what an API interface will/should look like. We want to ensure that before we write code, we have the usage nailed down.
So let's start the conversation on what APIs that people would like to help out and contribute. We're new to this whole process at RIM but we are more than happy to learn and figure out this process together as a community
Also for anyone who would like to contribute to the project, I would encourage you to sign a contributor's agreement for yourself and the company you work for: https://github.com/blackberry/WebWorks/wiki/How-to