I didn't say it doesn't make sense (in fact, as you pointed out, it makes a lot of sense in some cases). I just wanted to point out that it might not be allowed.
Loading external execution code is explicitly not allowed by Apples App Guidelines. That's all I wanted to note! Am 25.11.2011 16:37, schrieb Brian LeRoux: > Actually, async resource loading has lots of use cases even in a > compiled app. Best one to illustrate would be an app that includes > Google Maps but that isn't the primary function. No sense in loading > it up front but if the user requests that view then loading those JS > assets on demand makes sense --- and having an async mechanism to do > it does too. > > > On Thu, Nov 24, 2011 at 10:56 PM, Viras <[email protected]> wrote: >> Just as a side note: async loading of externally libraries shouldn't be >> a top target, especially as this is for example not allowed on iOS and I >> guess it isn't on other platforms as well. >> >> PhoneGap/Callback/Cordova is mainly targeting embedded devices in a >> closed execution environment - this is not a webpage per se. I would >> just like to keep that in mind when doing design decisions. >> (that's just my opinion, please correct me if I'm wrong with that). >> >> Best, >> Wolfgang >> >> Am 24.11.2011 19:46, schrieb Filip Maj: >>> Bit late but better than never... >>> >>> PhoneGap doesn't *need* modules but it *should* have them. >>> >>> +1 for AMD from me. >>> >>> As Laurent said, we need to consider the end-user. Overhead would be. >>> Compilation step is nice for phonegap.js but you cannot expect all scripts >>> will be prepackaged. Consider the case where a PG app async loads >>> libraries externally. AMD should be supported. >>> >>> Another argument in this thread was readability (see Gord's prototype for >>> the readability; Brian you agree too that Gord's demo was pretty). Don't >>> buy that commonJS is "nicer" than AMD - agree with Andrew that that is a >>> question of style. Personally I think AMD is nicer. >>> >>> >>> On 11-11-20 7:19 PM, "Laurent Hasson" <[email protected]> wrote: >>> >>>> Not about advocacy? I still do innerHTML and table layouts! :) It's about >>>> how to structure the project moving forwards... and I always took this >>>> conversation to be about (1) how to we write the framework, and (2) how >>>> do developers use it. >>>> - Are we expecting third-party modules to be developed in the >>>> wild? >>>> - If I write an app and need (a), (b) and (c), but not (d), (e), >>>> and (f), how do I specify that? A build system is how it's done and >>>> having modules clearly defined and dependencies managed helps doing that. >>>> >>>> In WebWorks, and Tim can correct me, there are potentially hundreds of >>>> modules. To just say it's all one big file with everything in it is >>>> something I don't understand. The fact that it's all packaged and we >>>> don't incur bandwidth and requests to pull it all in doesn't mean it >>>> doesn't take time to load in the browser, parse and so on. Putting it all >>>> on the shoulders of a developer to bring it all in themselves is also >>>> problematic. >>>> >>>> Maybe I am missing something here, but the way I read your messages is: >>>> phonegap.js is fine as it is, and we don't use any modules, so why start >>>> now? If we believe that we can control it, then maybe that's a fine >>>> position. Otherwise, if it's going to grow, and if third-parties are able >>>> to extend it (i.e., add new modules), and developers are going to find >>>> themselves never needing the entire thing by far, then how do we manage >>>> it? >>>> >>>> And maybe this is not a 1.x thing, maybe we'll re-architect again in 2.0 >>>> if the need arises? Advocacy aside, I don't often come across projects >>>> that don't need to end there, or suffer because they did this sooner >>>> rather than later. Just my $.02. >>>> >>>> >>>> Thank you >>>> ------------------------------------------------ >>>> - LDH (Laurent Hasson) - >>>> - Technical Director, BlackBerry Web Platform - >>>> - Research In Motion - >>>> - Email: [email protected] - >>>> - Mobile: 646-460-7066 - >>>> ------------------------------------------------ >>>> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin >>>> >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Brian LeRoux >>>> Sent: Sunday, November 20, 2011 9:22 PM >>>> To: [email protected] >>>> Subject: Re: Unified phonegap javascript layer incorperating modules / >>>> plugins >>>> >>>> With respect Laurent, lets keep the conversation around our project >>>> goals and away from library / pattern advocacy for just the moment. I >>>> don't think we are really debating this correctly (yet) since we >>>> aren't looking at the long view. Ultimately we don't even need a >>>> module system for the single file that is phonegap.js which is in use >>>> today and, indeed, we don't use one or have one. All this discussion >>>> has been framed, I think, around authoring apps with phonegap rather >>>> than how to author phonegap javascript itself. >>>> >>>> The key questions we need to answer to guide this effort: >>>> >>>> Are we looking to enforce a particular module semantics on 3rd party >>>> plugin authors? (Do we have to?) Are plugins all compiled into the >>>> phonegap.js file or are we going to see something like this: >>>> >>>> <script src="phonegap-exec.js"></script> >>>> <script src="phonegap-acceleromter.js"></script> >>>> >>>> ??? >>>> >>>> (And leave module loading as an exercise to the end developer...?) >>>> >>>> >>>> >>>> On Sun, Nov 20, 2011 at 5:38 PM, Laurent Hasson <[email protected]> wrote: >>>>> Things as ambitious as PhoneGap always grow in complexity faster and >>>>> bigger than people think. I have been in way too many projects in the >>>>> past where "anything goes" was the order of the day in terms of macro >>>>> structure, and then it became deeply regretted quickly. I for one don't >>>>> see a downside to using something like AMD. And if we do want to get >>>>> into a much more "micro-kernel" type approach for PhoneGap as a >>>>> platform, then we'll need something. >>>>> >>>>> So I would put the question differently: are people so offended by the >>>>> idea of something AMD-like? What's the downside? Verbosity? Overhead? >>>>> Really? :) It enables tooling, dependency management, code structuring, >>>>> plugins etc... I don't see the downside. >>>> >>>>> >>>>> >>>>> Thank you >>>>> ------------------------------------------------ >>>>> - LDH (Laurent Hasson) - >>>>> - Technical Director, BlackBerry Web Platform - >>>>> - Research In Motion - >>>>> - Email: [email protected] - >>>>> - Mobile: 646-460-7066 - >>>>> ------------------------------------------------ >>>>> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On Behalf >>>>> Of Brian LeRoux >>>>> Sent: Sunday, November 20, 2011 3:25 PM >>>>> To: [email protected] >>>>> Subject: Re: Unified phonegap javascript layer incorperating modules / >>>>> plugins >>>>> >>>>> Would like to draw attention back to the primary goal here: a single >>>>> file phonegap.js that works on all the target platforms: >>>>> >>>>> - ios >>>>> - android >>>>> - blackberry >>>>> - wp7 >>>>> - bada >>>>> - qt >>>>> - browser <--- never been an explicit goal, but seems consensus here >>>>> is that it should be given its a common practice during app dev >>>>> >>>>> Right now our module system is classic js: we have no module loader. >>>>> =P We just concat our JS, always have, and leave the loading of that >>>>> file as an exercise for the app developer using phonegap (and it >>>>> should stay that way). >>>>> >>>>> Our secondary goal w/ this effort was to determine how we could move >>>>> code out of the phonegap core and into atomic plugins. With that mind, >>>>> a module system is could make things whole lot nicer. >>>>> >>>>> Do have to use a module system when we 'pluginize'? No. >>>>> >>>>> Here's the big question: *should* authors of plugins be forced into a >>>>> module system? I'm thinking the answer here would be no too ---- but >>>>> I'd love to hear everyones thoughts on that. >>>>> >>>>> >>>>> On Sat, Nov 19, 2011 at 12:42 PM, Patrick Mueller <[email protected]> >>>>> wrote: >>>>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <[email protected]> wrote: >>>>>>> For PhoneGap.js, we're dealing with a finite number of modules - >>>>>>> around >>>>>>> twenty I'd guess, plus one for each plugin. Typically, each module >>>>>>> only >>>>>>> depends on phonegap/base - it's very unlikely that, say, the Camera >>>>>>> API >>>>>>> would depend on the Accelerometer, although there may be cases of >>>>>>> cross >>>>>>> dependencies. >>>>>> >>>>>> I take it you aren't including phonegap-plugins in that list (of 20). >>>>>> Shouldn't they be? >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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. >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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. >>> >>> >> >> -- >> GOFG - Get On Fat Guy >> http://www.gofg.at/ - powered by PhoneGap >> > -- GOFG - Get On Fat Guy http://www.gofg.at/ - powered by PhoneGap
