1. missing_K-W's Avatar
    I was on the BlackBerry Developer website,(Webworks Github) and noticed this, in reference to working with unavailable API's:

    "It’s also completely extensible; If support for that one API that you need doesn’t already exist, you can add it yourself."

    What does this imply? Are devs going to be able to create their own API's

    I'm not a developer....So I can't decipher what this implies

    Search for the highest text in the web link.

    BlackBerry WebWorks
    Last edited by missing_K-W; 02-18-12 at 05:59 PM.
    02-18-12 05:55 PM
  2. Concession's Avatar
    Webworks is open source.
    02-18-12 06:51 PM
  3. peter9477's Avatar
    Developers could always create their own APIs, so long as they were building on other, presumably lower level, APIs.

    What you read is simply referring to the fact that when WebWorks is lacking a particular API which you might want to use, such as the ability to control the LEDs, you could write code at a lower level -- on top of existing APIs that allow that for, say, in native code -- and expose that to the WebWorks code as an "extension".

    When I mucked up the stuff that let BuzzStarField get the magnetometer working in the interim release of What's Up, I used existing low-level filesystem APIs to read the raw data from a device called /dev/sensors/mag (or something like that) and after some contortions exposed the results in "an API" which he could call from his code. It's crude, and not something you'd want to release to the masses, but it's an API and it works, though with serious limitations that can't be overcome using just AIR code.

    In 2.0, RIM has implemented a nice, clean, fast API without the same limitations. They've also added the ability to write "extensions" for AIR apps, which will let someone write an AIR extension which provides a new magnetometer API for BuzzStarField's app, running as native code talking to a new lower-level API which RIM has added in 2.0.

    The reason why we often talk about having to "wait for RIM to supply an API" for something is when there's no way to work around the gap. For example, there is no way for us to launch code which continues running when an app exits, and therefore no way to write a "background service" for now. There was previously no extension mechanism for AIR, so it was impossible to interface it with native code the way we'll now be able to do.

    I guess you could say then, that the statement you highlighted is misleading if you try to apply it generally. They're not saying you can make anything you want, just that if there's no WebWorks way to do something that can be done from native code, you're free to write that routine yourself. Since WebWorks is actually built on top of AIR, they're really talking about the same new AIR Native Extension mechanism (which you may see referred to as an "ANE"). That lets both AIR and WebWorks devs add new APIs (at their own level) by calling existing native APIs which were previously inaccessible.
    02-18-12 07:09 PM
  4. KermEd's Avatar
    "Its also completely extensible; If support for that one API that you need doesnt already exist, you can add it yourself."

    BlackBerry WebWorks
    It just means you can extend the API's to a larger scope by creating your own. You can do this on AIR as well by creating an ANE in the NDK.

    Translation: You can create native code API's and use them in WebWorks to enhance the list of API commands.

    I could give some examples, but that would give away some of the secret things coming for root kit users after OS2.
    02-18-12 08:31 PM
  5. KermEd's Avatar
    <moved, wrong place lol!>
    Last edited by KermEd; 02-19-12 at 12:07 AM.
    02-18-12 08:36 PM
  6. BuzzStarField's Avatar
    Further to peter9477's excellent summary, writing an ANE, I am finding, is not for the faint-of-heart and is certainly not for the average HTML5 Webworks developer. This is another way that the highlighted text in the OP is very misleading.

    It makes no sense at all to me why RIM does not "just" write the native code and be done with it (instead of telling a JavaScript developer that they can "just" do it themselves). These are not obscure API's we are talking about here - they are vital capabilities for a modern device like the PB.

    If RIM would only take the time to fully implement the features that users crave, it would be so much easier to incorporate them into our apps without us having to know how to write bug-free c/c++ code. As it is, consumers have an unrealistic expectation that the magnetometer, for example, is a piece of cake to implement using the fancy new native API. And it's not.

    I keep getting reviews saying things like "i can't wait for OS2 to see even better point and view in this app" and frankly I am having to work my buttocks off not to disappoint. I hope that people will understand why the "perfect" version of my app must be delayed for a couple of weeks after OS2-day so that I can eliminate potential memory leaks and other inefficiencies in my somewhat amateurish c++ code.
    KermEd, DAnklaud and missing_K-W like this.
    02-18-12 08:54 PM