You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2016/04/06 23:52:23 UTC
[Android] Library Project/AAR alternatives to current plugin situation
Hey
I recently looked at how native Android developers could use the current
Cordova code with their projects, and I've noticed that there's some major
problems with our current approach of just copying the Java classes into a
project, such as resources getting merged together, and other related
issues, so I created a project that instead uses the InAppBrowser source as
an Android Library instead of just code thrown over the wall.
The main advantage of this approach is that we can now build the library as
an AAR and distribute the plugins and the platform using jcenter and
mavenCentral and allow more Android developers to be able to use Cordova in
their apps and make their apps more hybrid.
Anyway, the example code is here.
https://github.com/infil00p/Library-Dev-Project
I used a Cordova application to demonstrate this, but I could have easily
used a vanilla Android project. Hopefully this also allows for certain
plugins like the InAppBrowser to be a lot more managable and will also
allow us to add more unit tests to our projects.
Any thoughts on this approach versus our current one?
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by Joe Bowser <bo...@gmail.com>.
On Fri, Apr 8, 2016 at 3:07 PM, Jason Ginchereau <ja...@microsoft.com>
wrote:
> Distributing Android platforms and plugins as AAR binaries seems to go
> against open-source conventions and the existing Cordova model, where
> everything is distributed as source. It also breaks the platform-centric
> workflow that otherwise allows easily making changes to the platform and
> plugin code after it is installed into the app project.
>
I disagree. I think that it's just another way that Android developers can
use Cordova. We shouldn't be strictly promoting one way of working with
the project as the only way to work with the project and we should allow
Android developers to use our libraries the same way that they'd use any
other Java library, which is to allow it to be downloaded from JCenter as
an AAR. This doesn't mean that they can't use this as a separate library
if they chose to, but I don't think that this is going against any
philosophy or convention.
> Have you explored a mechanism where the library project files are
> distributed along with the source code? Then when the plugin is installed,
> that project would be added as a project reference in the application
> project. React Native (both Android and iOS) uses this model for
> distributing and installing plugins that contain native code. [1] It seems
> like this could solve the same problems you're attempting to address with
> the AAR approach, while preserving the benefits of distributing as source
> code.
>
Why not both? Why don't we distribute AARs, and also allow for library
projects to be distributed?
> Actually, it looks like Cordova uses project references already for the
> Android platform, but not for plugins. Is there a reason why a project
> reference to the cordova-android lib project is inconvenient in the
> embedded-Cordova scenario?
>
It has to manually downloaded instead of having it done in a single line in
build.gradle. Having a library that doesn't work like every other Java
library that Android developers can use means that Android developers won't
embed Cordova because it's too much of a pain in the ass to do so. I know
that I prefer using jcenter dependencies over downloading crap from some
website, let alone having to deal with our CLI.
>
>
> [1] I struggled to find good documentation, but here's the tool that links
> RN plugins into RN app projects: https://github.com/rnpm/rnpm,
> https://github.com/rnpm/rnpm-plugin-link
>
>
> Jason
>
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Thursday, April 7, 2016 10:12 AM
> To: dev <de...@cordova.apache.org>
> Subject: Re: [Android] Library Project/AAR alternatives to current plugin
> situation
>
> BTW: The library project is in the Android directory of this plugin. I
> want to be able to have our plugins use Library Projects and AARs so that
> we can get much improved test coverage.
>
> https://github.com/infil00p/cordova-plugin-inappbrowser/tree/aar_poc
>
> On Thu, Apr 7, 2016 at 8:52 AM, Joe Bowser <bo...@gmail.com> wrote:
>
> > BTW: You can use this to install plugins in an Android Studio project.
> > It's a proof-of-concept, but it's a good stop-gap until we get our
> > plugin story figured out.
> >
> > https://github.com/infil00p/cordova-android-studio
> >
> > On Thu, Apr 7, 2016 at 5:31 AM, julio cesar sanchez <
> > jcesarmobile@gmail.com> wrote:
> >
> >> I think it's a good idea as right now you can't install plugins on
> >> the cordova embedded webview use case, not even with plugman.
> >>
> >> Did you publish it on jcenter or mavencentral? or can you publish on
> >> github the plugin as library project (I mean the plugin with the
> >> changes you made, but without the cordova sample project)
> >>
> >> 2016-04-07 2:51 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> >>
> >> > On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana
> >> > <cs...@gmail.com>
> >> > wrote:
> >> >
> >> > > Does this aligns in a similar way as how phonegap is recommending
> >> > > for
> >> iOS
> >> > > on using Cocoapods [1] to embed the Cordova WebView into an
> >> > > existing
> >> iOS
> >> > > App?
> >> > >
> >> >
> >> > Yes, except that I don't think it will be nearly as complex as the
> >> > iOS approach is.
> >> >
> >> >
> >> > >
> >> > > Looking only from a Native Android developer eyes this will be
> >> > > the
> >> > approach
> >> > > I would like if I have a pure native android app and for some
> >> > > reason I
> >> > want
> >> > > to add a Cordova webview to a portion of my App.
> >> > >
> >> > > [1]:
> >> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fd
> >> > > ocs.phonegap.com%2fdevelop%2f1-embed-webview%2fios%2f%23pods&data
> >> > > =01%7c01%7cjasongin%40microsoft.com%7c651246d755c64bec161e08d35f0
> >> > > 7b69b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=shpqixroQaQD9A
> >> > > 54eMa1xUmwiCB%2bUN8U97xYJUrpxJs%3d
> >> > >
> >> > >
> >> > > On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com>
> wrote:
> >> > >
> >> > > > Hey
> >> > > >
> >> > > > I recently looked at how native Android developers could use
> >> > > > the
> >> > current
> >> > > > Cordova code with their projects, and I've noticed that there's
> >> > > > some
> >> > > major
> >> > > > problems with our current approach of just copying the Java
> >> > > > classes
> >> > into
> >> > > a
> >> > > > project, such as resources getting merged together, and other
> >> related
> >> > > > issues, so I created a project that instead uses the
> >> > > > InAppBrowser
> >> > source
> >> > > as
> >> > > > an Android Library instead of just code thrown over the wall.
> >> > > >
> >> > > > The main advantage of this approach is that we can now build
> >> > > > the
> >> > library
> >> > > as
> >> > > > an AAR and distribute the plugins and the platform using
> >> > > > jcenter and mavenCentral and allow more Android developers to
> >> > > > be able to use
> >> > Cordova
> >> > > in
> >> > > > their apps and make their apps more hybrid.
> >> > > >
> >> > > > Anyway, the example code is here.
> >> > > >
> >> > > > https://github.com/infil00p/Library-Dev-Project
> >> > > >
> >> > > > I used a Cordova application to demonstrate this, but I could
> >> > > > have
> >> > easily
> >> > > > used a vanilla Android project. Hopefully this also allows for
> >> certain
> >> > > > plugins like the InAppBrowser to be a lot more managable and
> >> > > > will
> >> also
> >> > > > allow us to add more unit tests to our projects.
> >> > > >
> >> > > > Any thoughts on this approach versus our current one?
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
RE: [Android] Library Project/AAR alternatives to current plugin
situation
Posted by Jason Ginchereau <ja...@microsoft.com>.
Distributing Android platforms and plugins as AAR binaries seems to go against open-source conventions and the existing Cordova model, where everything is distributed as source. It also breaks the platform-centric workflow that otherwise allows easily making changes to the platform and plugin code after it is installed into the app project.
Have you explored a mechanism where the library project files are distributed along with the source code? Then when the plugin is installed, that project would be added as a project reference in the application project. React Native (both Android and iOS) uses this model for distributing and installing plugins that contain native code. [1] It seems like this could solve the same problems you're attempting to address with the AAR approach, while preserving the benefits of distributing as source code.
Actually, it looks like Cordova uses project references already for the Android platform, but not for plugins. Is there a reason why a project reference to the cordova-android lib project is inconvenient in the embedded-Cordova scenario?
[1] I struggled to find good documentation, but here's the tool that links RN plugins into RN app projects: https://github.com/rnpm/rnpm, https://github.com/rnpm/rnpm-plugin-link
Jason
-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com]
Sent: Thursday, April 7, 2016 10:12 AM
To: dev <de...@cordova.apache.org>
Subject: Re: [Android] Library Project/AAR alternatives to current plugin situation
BTW: The library project is in the Android directory of this plugin. I want to be able to have our plugins use Library Projects and AARs so that we can get much improved test coverage.
https://github.com/infil00p/cordova-plugin-inappbrowser/tree/aar_poc
On Thu, Apr 7, 2016 at 8:52 AM, Joe Bowser <bo...@gmail.com> wrote:
> BTW: You can use this to install plugins in an Android Studio project.
> It's a proof-of-concept, but it's a good stop-gap until we get our
> plugin story figured out.
>
> https://github.com/infil00p/cordova-android-studio
>
> On Thu, Apr 7, 2016 at 5:31 AM, julio cesar sanchez <
> jcesarmobile@gmail.com> wrote:
>
>> I think it's a good idea as right now you can't install plugins on
>> the cordova embedded webview use case, not even with plugman.
>>
>> Did you publish it on jcenter or mavencentral? or can you publish on
>> github the plugin as library project (I mean the plugin with the
>> changes you made, but without the cordova sample project)
>>
>> 2016-04-07 2:51 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>>
>> > On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana
>> > <cs...@gmail.com>
>> > wrote:
>> >
>> > > Does this aligns in a similar way as how phonegap is recommending
>> > > for
>> iOS
>> > > on using Cocoapods [1] to embed the Cordova WebView into an
>> > > existing
>> iOS
>> > > App?
>> > >
>> >
>> > Yes, except that I don't think it will be nearly as complex as the
>> > iOS approach is.
>> >
>> >
>> > >
>> > > Looking only from a Native Android developer eyes this will be
>> > > the
>> > approach
>> > > I would like if I have a pure native android app and for some
>> > > reason I
>> > want
>> > > to add a Cordova webview to a portion of my App.
>> > >
>> > > [1]:
>> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fd
>> > > ocs.phonegap.com%2fdevelop%2f1-embed-webview%2fios%2f%23pods&data
>> > > =01%7c01%7cjasongin%40microsoft.com%7c651246d755c64bec161e08d35f0
>> > > 7b69b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=shpqixroQaQD9A
>> > > 54eMa1xUmwiCB%2bUN8U97xYJUrpxJs%3d
>> > >
>> > >
>> > > On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
>> > >
>> > > > Hey
>> > > >
>> > > > I recently looked at how native Android developers could use
>> > > > the
>> > current
>> > > > Cordova code with their projects, and I've noticed that there's
>> > > > some
>> > > major
>> > > > problems with our current approach of just copying the Java
>> > > > classes
>> > into
>> > > a
>> > > > project, such as resources getting merged together, and other
>> related
>> > > > issues, so I created a project that instead uses the
>> > > > InAppBrowser
>> > source
>> > > as
>> > > > an Android Library instead of just code thrown over the wall.
>> > > >
>> > > > The main advantage of this approach is that we can now build
>> > > > the
>> > library
>> > > as
>> > > > an AAR and distribute the plugins and the platform using
>> > > > jcenter and mavenCentral and allow more Android developers to
>> > > > be able to use
>> > Cordova
>> > > in
>> > > > their apps and make their apps more hybrid.
>> > > >
>> > > > Anyway, the example code is here.
>> > > >
>> > > > https://github.com/infil00p/Library-Dev-Project
>> > > >
>> > > > I used a Cordova application to demonstrate this, but I could
>> > > > have
>> > easily
>> > > > used a vanilla Android project. Hopefully this also allows for
>> certain
>> > > > plugins like the InAppBrowser to be a lot more managable and
>> > > > will
>> also
>> > > > allow us to add more unit tests to our projects.
>> > > >
>> > > > Any thoughts on this approach versus our current one?
>> > > >
>> > >
>> >
>>
>
>
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by Joe Bowser <bo...@gmail.com>.
BTW: The library project is in the Android directory of this plugin. I
want to be able to have our plugins use Library Projects and AARs so that
we can get much improved test coverage.
https://github.com/infil00p/cordova-plugin-inappbrowser/tree/aar_poc
On Thu, Apr 7, 2016 at 8:52 AM, Joe Bowser <bo...@gmail.com> wrote:
> BTW: You can use this to install plugins in an Android Studio project.
> It's a proof-of-concept, but it's a good stop-gap until we get our plugin
> story figured out.
>
> https://github.com/infil00p/cordova-android-studio
>
> On Thu, Apr 7, 2016 at 5:31 AM, julio cesar sanchez <
> jcesarmobile@gmail.com> wrote:
>
>> I think it's a good idea as right now you can't install plugins on the
>> cordova embedded webview use case, not even with plugman.
>>
>> Did you publish it on jcenter or mavencentral? or can you publish on
>> github
>> the plugin as library project (I mean the plugin with the changes you
>> made, but without the cordova sample project)
>>
>> 2016-04-07 2:51 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>>
>> > On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana <cs...@gmail.com>
>> > wrote:
>> >
>> > > Does this aligns in a similar way as how phonegap is recommending for
>> iOS
>> > > on using Cocoapods [1] to embed the Cordova WebView into an existing
>> iOS
>> > > App?
>> > >
>> >
>> > Yes, except that I don't think it will be nearly as complex as the iOS
>> > approach is.
>> >
>> >
>> > >
>> > > Looking only from a Native Android developer eyes this will be the
>> > approach
>> > > I would like if I have a pure native android app and for some reason I
>> > want
>> > > to add a Cordova webview to a portion of my App.
>> > >
>> > > [1]: http://docs.phonegap.com/develop/1-embed-webview/ios/#pods
>> > >
>> > >
>> > > On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
>> > >
>> > > > Hey
>> > > >
>> > > > I recently looked at how native Android developers could use the
>> > current
>> > > > Cordova code with their projects, and I've noticed that there's some
>> > > major
>> > > > problems with our current approach of just copying the Java classes
>> > into
>> > > a
>> > > > project, such as resources getting merged together, and other
>> related
>> > > > issues, so I created a project that instead uses the InAppBrowser
>> > source
>> > > as
>> > > > an Android Library instead of just code thrown over the wall.
>> > > >
>> > > > The main advantage of this approach is that we can now build the
>> > library
>> > > as
>> > > > an AAR and distribute the plugins and the platform using jcenter and
>> > > > mavenCentral and allow more Android developers to be able to use
>> > Cordova
>> > > in
>> > > > their apps and make their apps more hybrid.
>> > > >
>> > > > Anyway, the example code is here.
>> > > >
>> > > > https://github.com/infil00p/Library-Dev-Project
>> > > >
>> > > > I used a Cordova application to demonstrate this, but I could have
>> > easily
>> > > > used a vanilla Android project. Hopefully this also allows for
>> certain
>> > > > plugins like the InAppBrowser to be a lot more managable and will
>> also
>> > > > allow us to add more unit tests to our projects.
>> > > >
>> > > > Any thoughts on this approach versus our current one?
>> > > >
>> > >
>> >
>>
>
>
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by Joe Bowser <bo...@gmail.com>.
BTW: You can use this to install plugins in an Android Studio project.
It's a proof-of-concept, but it's a good stop-gap until we get our plugin
story figured out.
https://github.com/infil00p/cordova-android-studio
On Thu, Apr 7, 2016 at 5:31 AM, julio cesar sanchez <jc...@gmail.com>
wrote:
> I think it's a good idea as right now you can't install plugins on the
> cordova embedded webview use case, not even with plugman.
>
> Did you publish it on jcenter or mavencentral? or can you publish on github
> the plugin as library project (I mean the plugin with the changes you
> made, but without the cordova sample project)
>
> 2016-04-07 2:51 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>
> > On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> > > Does this aligns in a similar way as how phonegap is recommending for
> iOS
> > > on using Cocoapods [1] to embed the Cordova WebView into an existing
> iOS
> > > App?
> > >
> >
> > Yes, except that I don't think it will be nearly as complex as the iOS
> > approach is.
> >
> >
> > >
> > > Looking only from a Native Android developer eyes this will be the
> > approach
> > > I would like if I have a pure native android app and for some reason I
> > want
> > > to add a Cordova webview to a portion of my App.
> > >
> > > [1]: http://docs.phonegap.com/develop/1-embed-webview/ios/#pods
> > >
> > >
> > > On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
> > >
> > > > Hey
> > > >
> > > > I recently looked at how native Android developers could use the
> > current
> > > > Cordova code with their projects, and I've noticed that there's some
> > > major
> > > > problems with our current approach of just copying the Java classes
> > into
> > > a
> > > > project, such as resources getting merged together, and other related
> > > > issues, so I created a project that instead uses the InAppBrowser
> > source
> > > as
> > > > an Android Library instead of just code thrown over the wall.
> > > >
> > > > The main advantage of this approach is that we can now build the
> > library
> > > as
> > > > an AAR and distribute the plugins and the platform using jcenter and
> > > > mavenCentral and allow more Android developers to be able to use
> > Cordova
> > > in
> > > > their apps and make their apps more hybrid.
> > > >
> > > > Anyway, the example code is here.
> > > >
> > > > https://github.com/infil00p/Library-Dev-Project
> > > >
> > > > I used a Cordova application to demonstrate this, but I could have
> > easily
> > > > used a vanilla Android project. Hopefully this also allows for
> certain
> > > > plugins like the InAppBrowser to be a lot more managable and will
> also
> > > > allow us to add more unit tests to our projects.
> > > >
> > > > Any thoughts on this approach versus our current one?
> > > >
> > >
> >
>
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by Joe Bowser <bo...@gmail.com>.
I didn't publish it anywhere yet because I can't officially publish things
as Cordova without things being voted on. I could probably call this all
PhoneGap and publish it, but I really want to make sure that I have the is
dotted and the ts crossed before doing that, since I don't want the Apache
powers-that-be to come back down and shit on my head because I dared do
something for our users.
On Thu, Apr 7, 2016 at 5:31 AM, julio cesar sanchez <jc...@gmail.com>
wrote:
> I think it's a good idea as right now you can't install plugins on the
> cordova embedded webview use case, not even with plugman.
>
> Did you publish it on jcenter or mavencentral? or can you publish on github
> the plugin as library project (I mean the plugin with the changes you
> made, but without the cordova sample project)
>
> 2016-04-07 2:51 GMT+02:00 Joe Bowser <bo...@gmail.com>:
>
> > On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> > > Does this aligns in a similar way as how phonegap is recommending for
> iOS
> > > on using Cocoapods [1] to embed the Cordova WebView into an existing
> iOS
> > > App?
> > >
> >
> > Yes, except that I don't think it will be nearly as complex as the iOS
> > approach is.
> >
> >
> > >
> > > Looking only from a Native Android developer eyes this will be the
> > approach
> > > I would like if I have a pure native android app and for some reason I
> > want
> > > to add a Cordova webview to a portion of my App.
> > >
> > > [1]: http://docs.phonegap.com/develop/1-embed-webview/ios/#pods
> > >
> > >
> > > On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
> > >
> > > > Hey
> > > >
> > > > I recently looked at how native Android developers could use the
> > current
> > > > Cordova code with their projects, and I've noticed that there's some
> > > major
> > > > problems with our current approach of just copying the Java classes
> > into
> > > a
> > > > project, such as resources getting merged together, and other related
> > > > issues, so I created a project that instead uses the InAppBrowser
> > source
> > > as
> > > > an Android Library instead of just code thrown over the wall.
> > > >
> > > > The main advantage of this approach is that we can now build the
> > library
> > > as
> > > > an AAR and distribute the plugins and the platform using jcenter and
> > > > mavenCentral and allow more Android developers to be able to use
> > Cordova
> > > in
> > > > their apps and make their apps more hybrid.
> > > >
> > > > Anyway, the example code is here.
> > > >
> > > > https://github.com/infil00p/Library-Dev-Project
> > > >
> > > > I used a Cordova application to demonstrate this, but I could have
> > easily
> > > > used a vanilla Android project. Hopefully this also allows for
> certain
> > > > plugins like the InAppBrowser to be a lot more managable and will
> also
> > > > allow us to add more unit tests to our projects.
> > > >
> > > > Any thoughts on this approach versus our current one?
> > > >
> > >
> >
>
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by julio cesar sanchez <jc...@gmail.com>.
I think it's a good idea as right now you can't install plugins on the
cordova embedded webview use case, not even with plugman.
Did you publish it on jcenter or mavencentral? or can you publish on github
the plugin as library project (I mean the plugin with the changes you
made, but without the cordova sample project)
2016-04-07 2:51 GMT+02:00 Joe Bowser <bo...@gmail.com>:
> On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana <cs...@gmail.com>
> wrote:
>
> > Does this aligns in a similar way as how phonegap is recommending for iOS
> > on using Cocoapods [1] to embed the Cordova WebView into an existing iOS
> > App?
> >
>
> Yes, except that I don't think it will be nearly as complex as the iOS
> approach is.
>
>
> >
> > Looking only from a Native Android developer eyes this will be the
> approach
> > I would like if I have a pure native android app and for some reason I
> want
> > to add a Cordova webview to a portion of my App.
> >
> > [1]: http://docs.phonegap.com/develop/1-embed-webview/ios/#pods
> >
> >
> > On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
> >
> > > Hey
> > >
> > > I recently looked at how native Android developers could use the
> current
> > > Cordova code with their projects, and I've noticed that there's some
> > major
> > > problems with our current approach of just copying the Java classes
> into
> > a
> > > project, such as resources getting merged together, and other related
> > > issues, so I created a project that instead uses the InAppBrowser
> source
> > as
> > > an Android Library instead of just code thrown over the wall.
> > >
> > > The main advantage of this approach is that we can now build the
> library
> > as
> > > an AAR and distribute the plugins and the platform using jcenter and
> > > mavenCentral and allow more Android developers to be able to use
> Cordova
> > in
> > > their apps and make their apps more hybrid.
> > >
> > > Anyway, the example code is here.
> > >
> > > https://github.com/infil00p/Library-Dev-Project
> > >
> > > I used a Cordova application to demonstrate this, but I could have
> easily
> > > used a vanilla Android project. Hopefully this also allows for certain
> > > plugins like the InAppBrowser to be a lot more managable and will also
> > > allow us to add more unit tests to our projects.
> > >
> > > Any thoughts on this approach versus our current one?
> > >
> >
>
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana <cs...@gmail.com> wrote:
> Does this aligns in a similar way as how phonegap is recommending for iOS
> on using Cocoapods [1] to embed the Cordova WebView into an existing iOS
> App?
>
Yes, except that I don't think it will be nearly as complex as the iOS
approach is.
>
> Looking only from a Native Android developer eyes this will be the approach
> I would like if I have a pure native android app and for some reason I want
> to add a Cordova webview to a portion of my App.
>
> [1]: http://docs.phonegap.com/develop/1-embed-webview/ios/#pods
>
>
> On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
>
> > Hey
> >
> > I recently looked at how native Android developers could use the current
> > Cordova code with their projects, and I've noticed that there's some
> major
> > problems with our current approach of just copying the Java classes into
> a
> > project, such as resources getting merged together, and other related
> > issues, so I created a project that instead uses the InAppBrowser source
> as
> > an Android Library instead of just code thrown over the wall.
> >
> > The main advantage of this approach is that we can now build the library
> as
> > an AAR and distribute the plugins and the platform using jcenter and
> > mavenCentral and allow more Android developers to be able to use Cordova
> in
> > their apps and make their apps more hybrid.
> >
> > Anyway, the example code is here.
> >
> > https://github.com/infil00p/Library-Dev-Project
> >
> > I used a Cordova application to demonstrate this, but I could have easily
> > used a vanilla Android project. Hopefully this also allows for certain
> > plugins like the InAppBrowser to be a lot more managable and will also
> > allow us to add more unit tests to our projects.
> >
> > Any thoughts on this approach versus our current one?
> >
>
Re: [Android] Library Project/AAR alternatives to current plugin situation
Posted by Carlos Santana <cs...@gmail.com>.
Does this aligns in a similar way as how phonegap is recommending for iOS
on using Cocoapods [1] to embed the Cordova WebView into an existing iOS
App?
Looking only from a Native Android developer eyes this will be the approach
I would like if I have a pure native android app and for some reason I want
to add a Cordova webview to a portion of my App.
[1]: http://docs.phonegap.com/develop/1-embed-webview/ios/#pods
On Wed, Apr 6, 2016 at 5:52 PM Joe Bowser <bo...@gmail.com> wrote:
> Hey
>
> I recently looked at how native Android developers could use the current
> Cordova code with their projects, and I've noticed that there's some major
> problems with our current approach of just copying the Java classes into a
> project, such as resources getting merged together, and other related
> issues, so I created a project that instead uses the InAppBrowser source as
> an Android Library instead of just code thrown over the wall.
>
> The main advantage of this approach is that we can now build the library as
> an AAR and distribute the plugins and the platform using jcenter and
> mavenCentral and allow more Android developers to be able to use Cordova in
> their apps and make their apps more hybrid.
>
> Anyway, the example code is here.
>
> https://github.com/infil00p/Library-Dev-Project
>
> I used a Cordova application to demonstrate this, but I could have easily
> used a vanilla Android project. Hopefully this also allows for certain
> plugins like the InAppBrowser to be a lot more managable and will also
> allow us to add more unit tests to our projects.
>
> Any thoughts on this approach versus our current one?
>