Great stuff. Cordova users are going to be plugin-happy installing everything once we get all this packaged up and going!
On Wed, Feb 8, 2012 at 2:47 PM, Andrew Lunny <[email protected]> wrote: > Update - quick screencast showing usage available here: > http://youtu.be/HOs9nuzhxR4 > > (apologies for the iShowU HD watermark, and it logging every vim keystore) > > On 6 February 2012 17:46, Brian LeRoux <[email protected]> wrote: > >> fantastic stuff andrew; looking forward to seeing how the childbrowser >> plugin package itself evolves >> >> On Mon, Feb 6, 2012 at 4:58 PM, Steven Gill <[email protected]> >> wrote: >> > This sounds awesome Andrew! >> > >> > On Mon, Feb 6, 2012 at 4:48 PM, Andrew Lunny <[email protected]> wrote: >> > >> >> Update: The pluginstall script - https://github.com/alunny/pluginstall- >> >> now installs (simple) iOS plugins as well as Android. >> >> >> >> There are three steps to installing an iOS plugin: >> >> 1. move some files around >> >> 2. modify the PhoneGap.plist file >> >> 3. modify the XCode project file (App.xcodeproj/project.pbxproj) >> >> >> >> 1 and 2 are trivial (although the Node library for manipulating plist >> files >> >> does need some love). >> >> >> >> 3 right now depends on a separate library I've developed - >> >> https://github.com/alunny/node-xcode - that parses an XCode project >> file >> >> into a JavaScript object. This object can then be easily modified, and >> >> written back out. The node-xcode project is not very mature, and will >> need >> >> enhancements to deal with the full range of PhoneGap plugins. >> >> >> >> My next step is to modify a fork of the ChildBrowser plugin, to allow >> for >> >> cross-platform deployment of the same JavaScript file (there are some >> >> fiddly inconsistencies between Android and iOS there). I'll then have a >> >> screencast/demo available of how the whole process works. >> >> >> >> On 24 January 2012 13:19, Filip Maj <[email protected]> wrote: >> >> >> >> > >> >> > On 24 January 2012 09:55, Filip Maj <[email protected]<mailto: >> [email protected] >> >> >> >> >> > wrote: >> >> > >> >> > Can you explain the two <asset> nodes in your example plugins.xml ? >> What >> >> > is the difference between the two elements? Lines 8-9. >> >> > >> >> > "The first tag is pointing to the js file, the second to a directory >> also >> >> > called "childbrowser" that needs to be moved into the project's www >> >> > directory." >> >> > >> >> > Gotcha! >> >> > >> >> > >> >> > >... >> >> > >A couple of open issues: >> >> > >* the current format doesn't have a mechanism for specifying that one >> >> > >plugin depends on another, which will be necessary >> >> > >* there's no way to specify a dependency on an external library - for >> >> > >example, a separate framework on iOS. I will investigate options as I >> >> > >begin >> >> > >work on the iOS side of the code. >> >> > >> >> > Could we use what mechanisms already exist in package.json to figure >> this >> >> > out? Maybe add an extension to this? It'd be nice to be able to >> feature >> >> > phonegap plugins and other tools in NPM, and it seems we're going the >> >> > route of node anyways for our CLI stuff. >> >> > >> >> > >> >> > It's definitely something we should feel out as phonegap-js and the >> >> plugin >> >> > tooling progress, particularly for plugin distribution. I think having >> >> this >> >> > kind of manifest file and a package.json is not out of the question, >> if >> >> > they're doing two very different things. >> >> > >> >> > At this stage, I'm focused on the plugin installation - with the >> >> > assumption that all the code is available locally. If you assume all >> the >> >> > code is there on the filesystem, package.json and the npm >> infrastructure >> >> > don't really benefit us. The goal right now is to encode all this >> >> > information: >> >> > >> >> > >> >> > >> >> >> https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md >> >> > >> >> > in a format that can easily be manipulated by software and humans. >> >> > >> >> > ^^ This is key. I'm thinking some extensions to either xml/json >> format we >> >> > end up on over what's already "in place" (a la NPM or even a similar >> sort >> >> > of extensions employed by Nodejitsu). >> >> > >> >> > It'd be a little ugly to have two config files in the root of the >> plugin, >> >> > but it keeps things simple (non-intertwined), especially while we're >> >> > prototyping this stuff. >> >> > >> >> > That's my concern, is that if we go down the rabbit hole without >> thinking >> >> > about all the aspects of the cordova project this affects we could >> end up >> >> > with a sub-par solution. >> >> > >> >> > ;/ >> >> > >> >> >>
