cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] Library Project/AAR alternatives to current plugin situation
Date Thu, 07 Apr 2016 00:51:33 GMT
On Wed, Apr 6, 2016 at 4:08 PM, Carlos Santana <csantana23@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 <bowserj@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?
> >
>

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