Don't want to be a bother but it's been sometime now without any activity.
we have one agreement to keep both the feature and documentation PRs as
is and to create a new issue for a larger documentation restructure for
the android platform and no objections so far.
If there is no objections I'll go ahead and create a documentation
restructure issue as described in this thread.
Thanks for your feedback,
Norman
On 2019/07/30 12:12:03, Jan Piotrowski wrote:
> +1 on #1, #2 and #3 - just don't forget to create the issue that makes>
> sure #3 will be taken care of later.>
>
> J>
>
> Am Di., 30. Juli 2019 um 14:10 Uhr schrieb Norman Breau>
> :>
> >>
> > Hello devs!>
> >>
> > I am writing to gather feedback on the new feature to support
building>
> > the new android packaging format: android bundles. Below are the
links>
> > to the PRs, but I'll try to provide a brief summary below, then I'll>
> > provide my personal opinion.>
> >>
> > Feature PR: https://github.com/apache/cordova-android/pull/764>
> > Documentation PR: https://github.com/apache/cordova-docs/pull/1009>
> >>
> > What invoked moving the discussion here is the use of the packageType>
> > property/command line argument. During the course of the PR, it was>
> > decided to mimic the iOS platform use of the packageType build.json>
> > property to decide whether to build an APK or a AAB (bundle) file. It>
> > was then found that for iOS, the packageType build property is a>
> > property mostly related to signing and therefore, the documentation
for>
> > this is under "Signing an App".>
> >>
> > For android, building either the APK or a bundle has no relation to>
> > signing, all other build.json properties available for android is a>
> > "signing" property. Because of this, the android documentation for>
> > build.json properties is also organized under a "Signing an App">
> > section. As you might have guess, the addition of a new packageType>
> > property for android, a property that is more of a "building"
property>
> > rather than a "signing" property makes it a little awkward to
simply add>
> > to the current documentation without some major reorganizing.>
> >>
> > So what requires discussion is:>
> >>
> > 1) Should android reuse packageType, even if the purpose is slightly>
> > different for iOS?>
> >>
> > 2) If the answer to #1 is "yes", how should the android
documentation be>
> > reorganized as to not hide a "build" property under a "Signing an
App">
> > section?>
> >>
> > 3) If #2 is answered yes, should this re-organizing be deferred to a>
> > future PR to get app bundle support out as soon as possible?>
> >>
> > Below now is how I would favour proceeding>
> >>
> > The answer to #1, should be "yes" because the metaphor I think
applies>
> > just as well for Android as it does for iOS. While iOS as I
understand,>
> > all packageTypes builds an IPA file, they are just signed
differently,>
> > and to be consumed differenetly based on the selected packageType. As>
> > for Android, a packageType will build their own different formats,
but>
> > they are still packages, just formatted to be differently to be>
> > consumed differently, based on their packageType.>
> >>
> > Thus leading to question #2, I think a "Building the app" section
should>
> > be added, which will mimic the format of the existing "Signing the
app">
> > section, but will only include properties or flags related to
building>
> > the app. I have provided an example at>
> >
https://github.com/apache/cordova-docs/pull/1009#issuecomment-512227371>
> >>
> > Leading to #3, another contributor have suggested to simply add the>
> > documentation for app bundles in the current documentation format
(under>
> > "Signing the app" section) and defer adding the new build section to>
> > another PR. The intention for this is to get the feature out as
soon as>
> > possible as the feature request is somewhat highly requested (Over 43>
> > positive responses on the initial feature request ticket). I don't>
> > really have a strong opinion one way or another therefore my action
will>
> > be largely what everybody else thinks I should do here.>
> >>
> > Looking for everyones feedback,>
> > Thanks>
> >>
> > P.S. this is my first major contribution, I hope I didn't make this
too>
> > long and I hoped I explained myself clearly.>
> >>
> >>
> > --------------------------------------------------------------------->
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org>
> > For additional commands, e-mail: dev-h...@cordova.apache.org>
> >>
>
> --------------------------------------------------------------------->
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org>
> For additional commands, e-mail: dev-h...@cordova.apache.org>
>
>
