incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin tooling/specification
Date Mon, 17 Sep 2012 19:42:11 GMT
Yeah I'm not trying to exclude anyone from the process, just thinking it
might be more efficient and faster if a few of us could realtime chat about
this. :) I'm in there now as mikenstein.



On Mon, Sep 17, 2012 at 3:32 PM, Filip Maj <fil@adobe.com> wrote:

> We can chat anytime. I'm in #phonegap on irc.freenode.net all the time.
>
> That said, any _decisions_ that come out of our chat needs to be brought
> back to the list so everyone gets a chance to chime in and influence that
> decision.
>
> On 9/17/12 12:29 PM, "Mike Reinstein" <reinstein.mike@gmail.com> wrote:
>
> >I'd like to setup a time on irc to chat about the state of the plugin
> >system. I've made a lot of progress on several fronts, but I'd like to get
> >feedback from relevant/interested parties before I proceed. How do you
> >folks usually set up these group chats? Informally or is there some Apache
> >process I need to follow?
> >
> >-Mike
> >
> >On Mon, Sep 17, 2012 at 3:17 PM, Filip Maj <fil@adobe.com> wrote:
> >
> >> 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
> >> this.
> >>
> >> 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
> >> :(
> >>
> >> E.g.
> >>
> >> <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
> >> }
> >>
> >> </code>
> >>
> >> .. 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" <bvibber@wikimedia.org> wrote:
> >>
> >> >On Sep 17, 2012 2:10 AM, "Brian LeRoux" <b@brian.io> 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 @ pobox.com / bvibber @ wikimedia.org)
> >>
> >>
>
>

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