incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: plugin tooling/specification
Date Mon, 17 Sep 2012 19:17:36 GMT
Another good example of this use case is modifying an iOS app to register
for push notifications. You need to change code in the AppDelegate to do

The use case for formalizing/automating this is something in the plugin
spec like a giant block of code inside an xml tag. That doesn't sound cool


<code target="AppDelegate.m">
// Delegation methods
- (void)application:(UIApplication *)app
didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken {
    const void *devTokenBytes = [devToken bytes];
    self.registered = YES;
    [self sendProviderDeviceToken:devTokenBytes];
    // custom method


.. And then we'd need escaping of characters in the xml.. Blarghhh

>> Our goal should be to make it so that the only path to modifying
>> generated native bits should be either plugins, or upgrades to cordova
>> config.xml.

This plus a million.

On 9/17/12 9:28 AM, "Brion Vibber" <> wrote:

>On Sep 17, 2012 2:10 AM, "Brian LeRoux" <> wrote:
>> Consider this scenario. A developer generates a new Cordova project.
>> They then add, and subsequently modify, the generated native bits in
>> the platforms folder. Google changes something, perhaps how
>> AndroidManifest works. Or maybe Apple deprecates a library. The
>> developer now needs to regenerate their native bits in the platforms
>> folder. But they modified stuff--
>The AndroidManifest is an example of a file that we'd *need* to modify in
>many cases; unless there's tooling to patch it with custom modifications
>every time it's regenerated that'd be uncomfortable.
>-- brion vibber (brion @ / bvibber @

View raw message