cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: List of 'issues' I have seen with latest version
Date Tue, 30 Jul 2013 01:52:13 GMT
The main difference between plugman & cli is that CLI provides
multi-platform support and plugman doesn't.

I'm not suggesting we change CLI to have platform-specific logic (neither
was Tyler). I *am* suggesting that we can make the platforms aware of when
they exist within a CLI world.

Cordova certainly breaks more between releases than the platform IDEs...
Not sure what your point there is though.

There are currently key things that apps need to do that CLI doesn't
support. E.g. setting entitlements for push notifications, setting app
icons / launch images, setting the size of the NSUrlCache, setting allowed
device orientations for iPad vs iPod. IDEs also just give really nice
integration with emulators / devices ("just push play" support).

Maybe the abstraction won't be perfect, but we can certainly make it
through some very small tweaks (by doing the things Tyler pointed out).



On Mon, Jul 29, 2013 at 7:26 PM, Brian LeRoux <b@brian.io> wrote:

> I'd rather we kept our native platform abstractions in the actual
> native platform code. The CLI is ignorant to the implementation
> details of the native platforms so that the abstractions stay with the
> code they work against. If we've learned anything these past five
> years its that Eclipse, Android Studio and Xcode **will** break
> between releases.
>
>
> On Mon, Jul 29, 2013 at 6:08 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
> > Yes that is the process for now. Hopefully we'll be able to support
> > IDEs in CLI as well in the future.
> >
> > On Mon, Jul 29, 2013 at 2:58 PM, Filip Maj <fil@adobe.com> wrote:
> >> +1, totally agree, this was the main use case for separating our plugman
> >> vs cli tooling in the first place I thought..
> >>
> >> On 7/29/13 12:05 PM, "Brian LeRoux" <b@brian.io> wrote:
> >>
> >>>Woah woah, not my perception at all. If you want to work in native projs
> >>>then use plugman directly. CLI tools are designed to avoid IDE land and
> >>>associated pain from cat/mouse release antics. Combined usage will be
> too
> >>>leaky an abstraction.
> >>>On Jul 29, 2013 3:02 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >>>
> >>>> On Mon, Jul 29, 2013 at 1:30 PM, Tyler Wilson
> >>>><twilson@pulse-robotics.com
> >>>> >wrote:
> >>>>
> >>>> > See below.
> >>>> >
> >>>> > On Jul 29, 2013, at 12:56 PM, Brian LeRoux <b@brian.io> wrote:
> >>>> >
> >>>> > > Hey Tyler, thanks for capturing this. And yup filing relevant
> issues
> >>>> > > very welcome! I have some responses below inline:
> >>>> > >
> >>>> > >
> >>>> > >> You would need to create a new project to get the updated
> template
> >>>> > files, correct?
> >>>> > >
> >>>> > > This is correct. I believe we have a backlog item for implementing
> >>>>an
> >>>> > > `upgrade` command.
> >>>> >
> >>>> > Great
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > >> - When initially doing a 'cordova create' and the first
'cordova
> >>>> > platform add', it downloads the latest template files, but does
not
> >>>> display
> >>>> > any progress information. If on a slow connection, it can look
like
> it
> >>>> has
> >>>> > hung, and the user might cancel the operation, leaving the system
> in a
> >>>> > broken state.
> >>>> > >
> >>>> > > Yes, this is a docs issue too. If you run the command with
the -d
> >>>>flag
> >>>> > > you'll see detailed output.
> >>>> >
> >>>> > Got that now. Still think it ought to say something if it is
> >>>>performing a
> >>>> > possible time-consuming operation.
> >>>> >
> >>>>
> >>>> Agree. I'd like to see -d be the default.
> >>>>
> >>>>
> >>>> > >
> >>>> > >
> >>>> > >> - When doing a platform add iOS, we end up with two 'www'
> folders.
> >>>>One
> >>>> > at the root of the project, and one within the platform/ios folder.
> In
> >>>> step
> >>>> > 3 of the upgrading iOS page here
> >>>> >
> >>>>
> >>>>
> http://cordova.apache.org/docs/en/3.0.0/guide_platforms_ios_upgrading.md.
> >>>>html#Upgrading%20iOSitsays to copy the contents of the www folder to
> the
> >>>>www folder at the
> >>>> > root. But the Xcode project still refers to the www folder within
> the
> >>>>iOS
> >>>> > folder, not the one at the project root.
> >>>> > >
> >>>> > > This is deliberate. We copy the root www into the platform
folder.
> >>>>Our
> >>>> > > goal in 4.0 is to make ./platforms just build artifacts.
> >>>> >
> >>>> > Okay, this was not clear to me: I just did a test with 'cordova
> build'
> >>>> > which - as you say - did copy from the root www to the iOS platform.
> >>>>But
> >>>> > what about the case where the user simply creates the project,
adds
> >>>>the
> >>>> iOS
> >>>> > platform, and then uses Xcode? You cannot edit the www in the Xcode
> >>>> project
> >>>> > since it will be overwritten the next time they do a cordova build.
> I
> >>>> think
> >>>> > this would be a common use-case, and I do not see an levant solution
> >>>>to
> >>>> it.
> >>>> > My initial thought is that the Xcode project should point to the
> root
> >>>>www
> >>>> > and there are custom build options to copy then build within Xcode.
> >>>>Same
> >>>> > for Android if using Eclipse with an imported platform/androidÅ 
> >>>> >
> >>>>
> >>>> Agree here too. It's on the roadmap to do exactly as you said.
> >>>>
> >>>>
> >>>> >
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > >> - Adding plugins: I know we only have to do do the plugin
add
> once
> >>>>per
> >>>> > project, but I think is tedious.
> >>>> > >
> >>>> > > Plugin discovery didn't land in time for 3.0 but its there
now.
> You
> >>>> > > can just run `cordova plugin add geolocation` to get plugins
from
> >>>>our
> >>>> > > plugin repo that is based on npm. Documentation for this is
> >>>> > > forthcoming too.
> >>>> >
> >>>> > Nice to know. Thanks!
> >>>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message