All, I added a candidate structure for the hybridized TicketMonster - it's based on the Aerogear kitchensink with the added twist that we keep separate index files for each device, and then refer directly to those files from the wrapper code. While not ideal, this allows to keep separate configurations (i.e. dependencies for each device) and avoid manual changes after opening a particular device project. An alternative would be to use maven to construct target/www-<device> folders and use symlinks to those. I don't like it because - doesn't work well with the web configurations; - you can't easily create fixes from Xcode/Android SDK to the web app code, because you need to run the build phase manually after. Let the reviews begin! Here it is: https://github.com/jboss-jdf/ticket-monster/pull/6 _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

But I don't have a better answer right now. I'm just calling it out as a (major) issue. On 13 Aug 2012, at 16:39, Pete Muir wrote: > I really don't like keeping the project files in SCM. > > On 13 Aug 2012, at 14:24, Marius Bogoevici wrote: > >> All, >> >> I added a candidate structure for the hybridized TicketMonster - it's based on the Aerogear kitchensink with the added twist that we keep separate index files for each device, and then refer directly to those files from the wrapper code. While not ideal, this allows to keep separate configurations (i.e. dependencies for each device) and avoid manual changes after opening a particular device project. >> >> An alternative would be to use maven to construct target/www-<device> folders and use symlinks to those. I don't like it because >> >> - doesn't work well with the web configurations; >> - you can't easily create fixes from Xcode/Android SDK to the web app code, because you need to run the build phase manually after. >> >> Let the reviews begin! >> >> Here it is: >> https://github.com/jboss-jdf/ticket-monster/pull/6 >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev > > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev

Really the usual stuff - that we then need to specify the version of the IDE to use quite specifically, and we have to change the project files when the IDE updates. Furthermore, typically changes to IDE project files tend to get forgotten. I dont think there is a better way though. I suppose it also relates to whether Cordova is a progressive enhancement (you can write a browser app, and reuse it as a native app) or whether it's a strand in it's own right.

On 13 Aug 2012, at 16:54, Marius Bogoevici wrote: > Pete, can you voice your misgivings specifically? > > I'll begin: I have mixed feelings about SCM. The idea on a typical Android SDK/iOS project is that project sources will be checked in. However, these are not typical projects, given how they are really rather thin wrappers, basically the result of a "getting started" process, so we could just go away with a tutorial, like we did with Forge. The main difference is that, unlike the Forge stuff, once the Cordova projects are generated, the current generated projects can stay as they are (I don't see this as very easy to break ATM) unless we change the index files. > > On top of that, I have made changes to the original 'getting started', so I wanted to capture that as well. My motivations of putting this in SCM is > > a) To have a baseline on the structure > b) To show the customizations that need to be made to generated projects (customized entry points for Android/iOS, using the alternative indexes) > > > > > On 2012-08-13, at 11:39 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >> But I don't have a better answer right now. I'm just calling it out as a (major) issue. >> >> On 13 Aug 2012, at 16:39, Pete Muir wrote: >> >>> I really don't like keeping the project files in SCM. >>> >>> On 13 Aug 2012, at 14:24, Marius Bogoevici wrote: >>> >>>> All, >>>> >>>> I added a candidate structure for the hybridized TicketMonster - it's based on the Aerogear kitchensink with the added twist that we keep separate index files for each device, and then refer directly to those files from the wrapper code. While not ideal, this allows to keep separate configurations (i.e. dependencies for each device) and avoid manual changes after opening a particular device project. >>>> >>>> An alternative would be to use maven to construct target/www-<device> folders and use symlinks to those. I don't like it because >>>> >>>> - doesn't work well with the web configurations; >>>> - you can't easily create fixes from Xcode/Android SDK to the web app code, because you need to run the build phase manually after. >>>> >>>> Let the reviews begin! >>>> >>>> Here it is: >>>> https://github.com/jboss-jdf/ticket-monster/pull/6 >>>> _______________________________________________ >>>> jdf-dev mailing list >>>> jdf-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>> >>> >>> _______________________________________________ >>> jdf-dev mailing list >>> jdf-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jdf-dev >> >

On Aug 14, 2012, at 8:31 AM, Marius Bogoevici <mariusb(a)redhat.com&gt; wrote: > > On 2012-08-14, at 7:37 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >> Really the usual stuff - that we then need to specify the version of the IDE to use quite specifically, and we have to change the project files when the IDE updates. Furthermore, typically changes to IDE project files tend to get forgotten. >> >> I dont think there is a better way though. >> >> I suppose it also relates to whether Cordova is a progressive enhancement (you can write a browser app, and reuse it as a native app) or whether it's a strand in it's own right. > > That is some we'll have to think about. I don't think that the fundamental purpose of Cordova is progressive enhancement. Getting it's full value means using the Cordova API which means breaking with web deployment. It's more about having the means for writing completely portable (across mobile platforms) applications using HTML5. Now I can see a scenario where you share code with a web application (and that's interesting enough to warrant an exploration because I think it's a problem that a lot of dev's have or will have), but generally speaking, the move is uni-directional (web->hybrid). I would say that I somewhat agree with Marius on this. In my opinion, Cordova has 2 major audiences. The first, as Marius points out, are the developers using Cordova for its native APIs and getting those benefits. The second, which I believe is probably just as large and equally as important, is the group of web developers that want to break into the app stores but have no native programming skills (Java, Objective-C, etc.) These developers are building apps and just need that web view wrapper to get their app into an app store and that's all they need out of Cordova, in a sense, treating it as a progressive enhancement. This same group is probably also very concerned with maintaining a single code base across their web and hybrid apps as much as possible.

> >> >> On 13 Aug 2012, at 16:54, Marius Bogoevici wrote: >> >>> Pete, can you voice your misgivings specifically? >>> >>> I'll begin: I have mixed feelings about SCM. The idea on a typical Android SDK/iOS project is that project sources will be checked in. However, these are not typical projects, given how they are really rather thin wrappers, basically the result of a "getting started" process, so we could just go away with a tutorial, like we did with Forge. The main difference is that, unlike the Forge stuff, once the Cordova projects are generated, the current generated projects can stay as they are (I don't see this as very easy to break ATM) unless we change the index files. >>> >>> On top of that, I have made changes to the original 'getting started', so I wanted to capture that as well. My motivations of putting this in SCM is >>> >>> a) To have a baseline on the structure >>> b) To show the customizations that need to be made to generated projects (customized entry points for Android/iOS, using the alternative indexes) >>> >>> >>> >>> >>> On 2012-08-13, at 11:39 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >>> >>>> But I don't have a better answer right now. I'm just calling it out as a (major) issue. >>>> >>>> On 13 Aug 2012, at 16:39, Pete Muir wrote: >>>> >>>>> I really don't like keeping the project files in SCM. >>>>> >>>>> On 13 Aug 2012, at 14:24, Marius Bogoevici wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I added a candidate structure for the hybridized TicketMonster - it's based on the Aerogear kitchensink with the added twist that we keep separate index files for each device, and then refer directly to those files from the wrapper code. While not ideal, this allows to keep separate configurations (i.e. dependencies for each device) and avoid manual changes after opening a particular device project. >>>>>> >>>>>> An alternative would be to use maven to construct target/www-<device> folders and use symlinks to those. I don't like it because >>>>>> >>>>>> - doesn't work well with the web configurations; >>>>>> - you can't easily create fixes from Xcode/Android SDK to the web app code, because you need to run the build phase manually after. >>>>>> >>>>>> Let the reviews begin! >>>>>> >>>>>> Here it is: >>>>>> https://github.com/jboss-jdf/ticket-monster/pull/6 >>>>>> _______________________________________________ >>>>>> jdf-dev mailing list >>>>>> jdf-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> jdf-dev mailing list >>>>> jdf-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>> >>> >> > > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev