Hi Michael, Thanks for raising this. We went through this exact question on BlackBerry 10 WebWorks SDK last year and eventually made the decision to pre-compile plugins.
>> - For each platform, how feasible is this? BlackBerry 10 is unique in its nature of plugins, as in the Framework (non-plugin code) itself is all JavaScript and does not need to be compiled but the plugins might contain native (C/C++) code. This means that even though the developer does not need to compile the framework they would have to compile the plugins. So the choice for BlackBerry 10 was obvious, the plugins are indeed compiled into libraries that are then loaded at runtime. This obviously provides the benefit of simplicity to the end user, who does not need to compile the native code. On older BlackBerry and Playbook platforms this is also feasible as library loading is supported by both Java and ActionScript, although it might be slow on Java (will need prototyping) >> - What problems (or other benefits) would exist with plugins as >>libraries? We also added a feature where we only load the library when an API is used the first time. This reduces memory consumption at launch of the application reducing startup time for the application. Obviously if your API is time sensitive it should be loaded at startup. I imagine this is a major benefit that can probably be achieved by other platforms as well. BlackBerry 10 WebWorks SDK received a lot of Kudos from our developers for reducing dependencies and time when building their application. I can imagine similar benefits of decreasing build time (might be minimal though) can be achieved on other platforms even though reducing build time dependencies might not be feasible for all platforms. We are yet to observe any negative impact of this approach. Obviously these benefits are automatically carried over to the BlackBerry 10 implementation of Cordova as well. Nukul Bhasin Team Lead, BlackBerry WebWorks Tel: 289 261 5574 Research in Motion Limited On 2/22/13 12:29 PM, "Michael Brooks" <mich...@michaelbrooks.ca> wrote: >Hi all, > >I'd like to pick your brain around the feasibility of plugins existing as >static or dynamic libraries. > >I had this idea a few years ago, when we first started discussing plugins. >At the time, it was >possible on BlackBerry and, with some work, possible on Android and iOS. >However, a lot >has changed in the last few years, so I'd like to revisit the topic. > >Overview: > >- A plugin developer would compile their plugin as a static or dynamic >library. >- A plugin developer would publish their plugin as the library. >- An app developer would install the static or dynamic library. > >Benefits: > >- The plugin is only compiled by the author who distributes it. > - For complex plugins, this may help avoid compile-time errors around >dependencies. >- The plugin may be able to bundle some of its assets, simplifying the >installation process. >- Can be an alternative (not replacement) to distributing plugins as >source-code. > >Questions: > >- For each platform, how feasible is this? >- What problems (or other benefits) would exist with plugins as libraries? > >Thanks! >Michael --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
