On 2012-08-14, at 9:40 AM, Kris Borchers <kris(a)redhat.com> wrote:
On Aug 14, 2012, at 8:31 AM, Marius Bogoevici <mariusb(a)redhat.com> wrote:
>
> On 2012-08-14, at 7:37 AM, Pete Muir <pmuir(a)redhat.com> 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.
+1 which is why I think we should design a way of showcasing progressive enhancement for
cordovaized apps (make native enhancements pluggable one way or the other), if there
isn't one already
>
>>
>> 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> 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