incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <deedu...@gmail.com>
Subject Re: one file to rule them all: some post 2.x thoughts
Date Wed, 06 Jun 2012 13:48:55 GMT
So with BlackBerry 10 I would assume the webworks.js is dynamically
built by the packager based on the extensions specified in config.xml
right?

I would think this is what we would eventually do in Cordova. It seems
to me our build tools for the various platforms should just be
configured to point to where the Cordova SDK is and then the build can
dynamically build a platform specific cordova.js file that is packaged
with the application.

On Wed, Jun 6, 2012 at 8:10 AM, Ken Wallis <kwallis@rim.com> wrote:
> You can probably lump BlackBerry 10 into the JavaScript based platform. ;)
>
> We have a similar concept now with a webworks.js file that orchestrates the API loading
etc.
> --
>
> Ken Wallis
>
> Product Manager – BlackBerry WebWorks
>
> Research In Motion
>
> (905) 629-4746 x14369
>
> ________________________________________
> From: Dave Johnson [dave.c.johnson@gmail.com]
> Sent: Wednesday, June 06, 2012 1:44 AM
> To: callback-dev@incubator.apache.org
> Cc: gtanner@gmail.com
> Subject: Re: one file to rule them all: some post 2.x thoughts
>
> Drew I really like that approach but it doesn't work well in platforms
> where there's no "native" code like desktop browser (for debugging)
> and JavaScript based platforms like Symbian and webOS (but maybe
> that's not such a big deal?).
>
> On Tue, Jun 5, 2012 at 6:46 PM, Drew Walters <deedubbu@gmail.com> wrote:
>> 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 <michael@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, <gtanner@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.kadri@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 <purplecabbage@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 <michael@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.leroux@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
>>>> >
>>>>
>>>>
>
> ---------------------------------------------------------------------
> 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.

Mime
View raw message