Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

allow for arbitrary source munging? #5

filmaj opened this Issue Sep 5, 2012 · 10 comments


None yet
4 participants

filmaj commented Sep 5, 2012

Use case: most iOS plugins require you to change shit in your appdelegate.m file.

Fun times. should the spec allow for this?


alunny commented Sep 12, 2012

How might this look?


filmaj commented Sep 12, 2012

Oh dear.

We would have to be ok with XML-escaping code - that alone would be fucking gnarly.


filmaj commented Oct 18, 2012

What if the cordova project had comments or something delimiting common code "areas" where certain plugins would need to hook into?

For example, didReceivePushNotification or whatever method(s) in AppDelegate.m for iOS apps wanting to integrate push notification. If we stub out all such possible methods that users may want to hook into (with empty methods in a stock cordova app) and delimit them with some recognizable comments, we should be able to easily insert code.

If we support and integrate the suggestion brought up in #9, then this code-munging functionality could work in the same way: split out the changes to source code into separate files and point to them via a src attribute. Not sure what that spec element would look like though, and if we'd need a separate element for each potential area we'd want to hook source code into?


alunny commented Oct 18, 2012

Yeah, this could get very gnarly very quickly.

I'd love to see a quick prototype, just to get an idea of what the implementation looks like. By someone other than me 👍


filmaj commented Oct 18, 2012

Fair :)


alunny commented Oct 18, 2012

Had a quick chat with @brianleroux about this - we might well want to push as much into the native code API as possible and keep the logic out of the install process.

So (pseudocode ahead), the Cordova app delegate / main Android activity has a thing that looks like this:

function onAppCreate() {
   var that = this;

   // do everything normal
   this.plugins.forEach(function (plugin) {
       plugin.trigger('appcreated', that)

and then my plugin can say

this.on('appcreated', function (app) {

Not sure if how widely implemented the plugin lifecycles are though.


alunny commented Oct 18, 2012

Looks like iOS, for instance, has some lifecycle events but nothing for create:

Zammy commented Oct 19, 2012

I like @brianleroux idea. I was thinking the same thing. I prefer more native solution though. The plugins should be called as delegates. They should implement protocol UIApplicationDelegate. Here is the whole protocol: http://developer.apple.com/library/ios/#documentation/uikit/reference/UIApplicationDelegate_Protocol/Reference/Reference.html

All plugins can belooped through and sent any message from the lifecycle events. As this is Objective-C there is no problem to send messages(call methods) to objects that do not implement them. This way you can make any kind of Plugin funcionality without the need to change ApplicationDelegate. Maybe we can even do that for the view controller.

Zammy commented Oct 20, 2012

Ok so if we have preloaded plugins they could be eligible for LifeCycle events?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment