I think we discussed this previously, but what's the potential for the native side to just load the cordova.js/plugin javascript dynamically at initialization rather then requiring each app to specify it in the HTML content. This is what I did in my refactor of Cordova BlackBerry where everything is a plugin. I recall there being an issue with iOS / Android doing something similar but not sure.
On Tue, Jun 5, 2012 at 7:31 PM, Michael Brooks <mich...@michaelbrooks.ca> wrote: > Jesse / Fil / Gord / Anis, I think we're all in agreement but our > suggestions are for different stages of the problem. > > Today: The easiest is pre-building a monolith file with all plugins and > platform-specifics. > > Tomorrow: Loading only necessary the plugins as modules (or some concat > variation). > > In both: We offer a "debug" JavaScript that detects the platform and loads > the platform-specifics. For the performance hungry, they can opt into a > slimmer "prod" JavaScript that only includes a specific platform. All of > these JavaScript files can be pre-built and shipped, so the end-users do > not need to run cordova-js. > > Michael > > On Tue, Jun 5, 2012 at 4:40 PM, <gtan...@gmail.com> wrote: > >> I have really liked the mobile-spec cordova.js file (option 2). If we have >> enough runtime information to figure out the platform (is useragent >> enough?) we could continue building platform specific files and include >> them at runtime. >> >> Could then be handled better via the cmdline tooling to only include >> platforms they care about.: >> >> cordova add ios >> cordova add blackberry >> >> ... >> Sent on the TELUS Mobility network with BlackBerry >> >> -----Original Message----- >> From: Anis KADRI <anis.ka...@gmail.com> >> Date: Tue, 5 Jun 2012 15:45:53 >> To: <callback-dev@incubator.apache.org> >> Reply-To: callback-dev@incubator.apache.org >> Subject: Re: one file to rule them all: some post 2.x thoughts >> >> I vote for including the javascript generation as part of the build process >> (or separate). >> It could: >> - include the plugins that are needed (contacts, etc...). >> - use the right exec method and inludes the right platform-specific code. >> >> Pretty much what cordova-js does right now with the ability to select what >> plugins you want. >> >> advantages: >> - smaller file that just includes what you need in terms of plugins. Faster >> load time. >> - Doesn't include plugins that are not supported by the targeted platform. >> >> I find it easier to deal with one file that has everything I need rather >> than having to include multiple files. but that is just me. >> On Tue, Jun 5, 2012 at 3:21 PM, Jesse <purplecabb...@gmail.com> wrote: >> >> > I originally envisioned something like #1, except that the individual >> APIs >> > would not be part of the master file. >> > ie. real modules, the cordova-common.js would just provide the transport, >> > and fire the correct events. If you want to use Contacts, then you >> simply >> > add an include script tag for cdv-contacts.js >> > This would be just like any other plugin ... >> > >> > We already employ this type of modular-izing in mobile-spec in that any >> > tests you want to run must be included in the page. >> > >> > On Tue, Jun 5, 2012 at 3:10 PM, Michael Brooks <mich...@michaelbrooks.ca >> > >wrote: >> > >> > > A small variation of 1) >> > > >> > > 1) Ship all platform-specific JavaScript in one file and sort it out at >> > > runtime. Provide the option to build the JavaScript for a specific >> > > platform. Basically, a debug vs production file, although most apps >> would >> > > happily use the debug in production. >> > > >> > > On Tue, Jun 5, 2012 at 2:56 PM, Brian LeRoux <brian.ler...@gmail.com> >> > > wrote: >> > > >> > > > Just had a water cooler discussion about the holy grail of having one >> > > > js file to rule them all. >> > > > >> > > > 1. platforms have differences but could it be feasible to ship all >> > > > those differences in the single file and sort out which traits to >> load >> > > > at runtime. this would certainly introduce a latency and parse hit. >> > > > this would force us to really be thinking about a protocol to >> minimize >> > > > platform differences instead of brute forcing it. >> > > > >> > > > 2. the cordova.js file could document.write a script tag including >> the >> > > > auto compiled src file (still doing different files for each platform >> > > > but the src would feel cleaner to end developers). same performance >> we >> > > > have today. >> > > > >> > > > 3. do as we do today: different files for every platform treated as a >> > > > build artifact. >> > > > >> > > >> > >> > >> > >> > -- >> > @purplecabbage >> > risingj.com >> > >> >>
