Google Team's Task Backlog: iOS

[Andrew Grieve <ag...@chromium.org>]

We've done some planning around what we'd like to get done over the next
quarter, and so I thought I'd share.

This isn't to say that we'll be going and doing these things without
further discussion or proper JIRA issues. It also doesn't mean we will be
solely focused on this list, nor that we'll actually end up completing
everything on the list. Just that we *currently* think that these things
should get done.


cordova-ios:

- Move header symbols into .m files where possible (reduce API surface)

- Move resource copy step into an external script

- Make Xcode have a custom build step that runs prepare for CLI setup

- Make Xcode's project navigator point to your root www/ and merges/

- (CB-3900) Have PluginResult that gets populated lazily - at the time of
being sent over the bridge.

Re: Google Team's Task Backlog: iOS

[Michal Mocny <mm...@chromium.org>]

Options could be:

- Buffer PluginResults using a good scheme (perhaps the RAF method), and
just don't clobber.  Without spam, hopefully backup isn't common (for good
apps, that would be true..)
- Support querying list of currently queued PluginResults, so plugin can
chose how to replace itself.  This would need to be done "atomically" as
one transaction somehow so bridge doesn't flush after the query, perhaps
done by making the query a "pop" method?  (socket loop would be: pop or
create result, append data, push)
- Use a separate long lived binary stream (XHR?) as discussed in the past,
that doesn't have this problem

-Michal


On Mon, Jul 29, 2013 at 3:03 PM, Andrew Grieve <ag...@chromium.org> wrote:

> I considered clobber, but I think it falls apart in this case:
>
> E.g. for sockets, your callback sends back as much *new* data as is ready.
> With clobbers, how do you know what the JS side has already been sent?
>
> We could probably do similar timing + logging to detect slow plugins in
> this case.
>
>
> On Mon, Jul 29, 2013 at 2:08 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > While I like that idea, what happens when creating the plugin result is
> > "heavy", perhaps needing to synchronize with background threads etc?
> >  Waiting on the callbacks may not be a great plan.
> >
> > Could an alternative be to just support a "clobber" boolean flag, to
> > replace old PluginResult (instead of append to) if they have not been
> sent
> > across yet?  That would solve the accelerometer or progress events
> > problem..
> >
> > -Michal
> >
> >
> > On Mon, Jul 29, 2013 at 10:43 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > On Thu, Jul 25, 2013 at 3:06 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Comments inline.
> > > >
> > > >
> > > > cordova-ios:
> > > > >
> > > > > - Move header symbols into .m files where possible (reduce API
> > surface)
> > > > >
> > > > > Makes sense now since the core code shouldn't be called into with
> the
> > > > exception of some classes like CDVPlugin.h
> > > >
> > > >
> > > >
> > > > > - Move resource copy step into an external script
> > > > >
> > > >
> > > > +1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode
> > > >
> > > >
> > > > >
> > > > > - Make Xcode have a custom build step that runs prepare for CLI
> setup
> > > > >
> > > > >
> > > >  as long as it works for people not using the CLI
> > > >
> > > >
> > > > > - Make Xcode's project navigator point to your root www/ and
> merges/
> > > > >
> > > > >
> > > > also, have to make sure if user not using the CLI
> > > >
> > > >
> > > >
> > > > > - (CB-3900) Have PluginResult that gets populated lazily - at the
> > time
> > > of
> > > > > being sent over the bridge.
> > > > >
> > > >
> > > > not sure what this is exactly, the issue referred to is an Android
> > issue?
> > > >
> > > This is more of an Android problem, but there was a report of
> > accelerometer
> > > callbacks being sent faster than the bridge could deliver them. Same
> > thing
> > > could happen with FileTransfer progress events. The primary example is
> > when
> > > there's a JS alert on Android. I figured that this scenario would apply
> > to
> > > both platforms though.
> > >
> > > The idea here is that a plugin can send a PluginResult that has a
> > callback
> > > in it instead of a value. The plugin then knows not to send any further
> > > PluginResults until that callback has been called. When the bridge goes
> > to
> > > serialize pending PluginResults to be sent to JS, it calls the callback
> > in
> > > order to populate the value of the result. This will ensure the
> > > PluginResult has the freshest data. This approach should be used for
> > > accelerometer, compass, progress events.
> > >
> >
>

Re: Google Team's Task Backlog: iOS

[Andrew Grieve <ag...@chromium.org>]

I considered clobber, but I think it falls apart in this case:

E.g. for sockets, your callback sends back as much *new* data as is ready.
With clobbers, how do you know what the JS side has already been sent?

We could probably do similar timing + logging to detect slow plugins in
this case.


On Mon, Jul 29, 2013 at 2:08 PM, Michal Mocny <mm...@chromium.org> wrote:

> While I like that idea, what happens when creating the plugin result is
> "heavy", perhaps needing to synchronize with background threads etc?
>  Waiting on the callbacks may not be a great plan.
>
> Could an alternative be to just support a "clobber" boolean flag, to
> replace old PluginResult (instead of append to) if they have not been sent
> across yet?  That would solve the accelerometer or progress events
> problem..
>
> -Michal
>
>
> On Mon, Jul 29, 2013 at 10:43 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > On Thu, Jul 25, 2013 at 3:06 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > Comments inline.
> > >
> > >
> > > cordova-ios:
> > > >
> > > > - Move header symbols into .m files where possible (reduce API
> surface)
> > > >
> > > > Makes sense now since the core code shouldn't be called into with the
> > > exception of some classes like CDVPlugin.h
> > >
> > >
> > >
> > > > - Move resource copy step into an external script
> > > >
> > >
> > > +1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode
> > >
> > >
> > > >
> > > > - Make Xcode have a custom build step that runs prepare for CLI setup
> > > >
> > > >
> > >  as long as it works for people not using the CLI
> > >
> > >
> > > > - Make Xcode's project navigator point to your root www/ and merges/
> > > >
> > > >
> > > also, have to make sure if user not using the CLI
> > >
> > >
> > >
> > > > - (CB-3900) Have PluginResult that gets populated lazily - at the
> time
> > of
> > > > being sent over the bridge.
> > > >
> > >
> > > not sure what this is exactly, the issue referred to is an Android
> issue?
> > >
> > This is more of an Android problem, but there was a report of
> accelerometer
> > callbacks being sent faster than the bridge could deliver them. Same
> thing
> > could happen with FileTransfer progress events. The primary example is
> when
> > there's a JS alert on Android. I figured that this scenario would apply
> to
> > both platforms though.
> >
> > The idea here is that a plugin can send a PluginResult that has a
> callback
> > in it instead of a value. The plugin then knows not to send any further
> > PluginResults until that callback has been called. When the bridge goes
> to
> > serialize pending PluginResults to be sent to JS, it calls the callback
> in
> > order to populate the value of the result. This will ensure the
> > PluginResult has the freshest data. This approach should be used for
> > accelerometer, compass, progress events.
> >
>

Re: Google Team's Task Backlog: iOS

[Michal Mocny <mm...@chromium.org>]

While I like that idea, what happens when creating the plugin result is
"heavy", perhaps needing to synchronize with background threads etc?
 Waiting on the callbacks may not be a great plan.

Could an alternative be to just support a "clobber" boolean flag, to
replace old PluginResult (instead of append to) if they have not been sent
across yet?  That would solve the accelerometer or progress events problem..

-Michal


On Mon, Jul 29, 2013 at 10:43 AM, Andrew Grieve <ag...@chromium.org>wrote:

> On Thu, Jul 25, 2013 at 3:06 PM, Shazron <sh...@gmail.com> wrote:
>
> > Comments inline.
> >
> >
> > cordova-ios:
> > >
> > > - Move header symbols into .m files where possible (reduce API surface)
> > >
> > > Makes sense now since the core code shouldn't be called into with the
> > exception of some classes like CDVPlugin.h
> >
> >
> >
> > > - Move resource copy step into an external script
> > >
> >
> > +1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode
> >
> >
> > >
> > > - Make Xcode have a custom build step that runs prepare for CLI setup
> > >
> > >
> >  as long as it works for people not using the CLI
> >
> >
> > > - Make Xcode's project navigator point to your root www/ and merges/
> > >
> > >
> > also, have to make sure if user not using the CLI
> >
> >
> >
> > > - (CB-3900) Have PluginResult that gets populated lazily - at the time
> of
> > > being sent over the bridge.
> > >
> >
> > not sure what this is exactly, the issue referred to is an Android issue?
> >
> This is more of an Android problem, but there was a report of accelerometer
> callbacks being sent faster than the bridge could deliver them. Same thing
> could happen with FileTransfer progress events. The primary example is when
> there's a JS alert on Android. I figured that this scenario would apply to
> both platforms though.
>
> The idea here is that a plugin can send a PluginResult that has a callback
> in it instead of a value. The plugin then knows not to send any further
> PluginResults until that callback has been called. When the bridge goes to
> serialize pending PluginResults to be sent to JS, it calls the callback in
> order to populate the value of the result. This will ensure the
> PluginResult has the freshest data. This approach should be used for
> accelerometer, compass, progress events.
>

Re: Google Team's Task Backlog: iOS

[David Kemp <dr...@google.com>]

Note that the PluginResult callback would be done synchronously in the
bridge, possibly impacting other PluginResult timings.



On Mon, Jul 29, 2013 at 10:43 AM, Andrew Grieve <ag...@chromium.org>wrote:

> On Thu, Jul 25, 2013 at 3:06 PM, Shazron <sh...@gmail.com> wrote:
>
> > Comments inline.
> >
> >
> > cordova-ios:
> > >
> > > - Move header symbols into .m files where possible (reduce API surface)
> > >
> > > Makes sense now since the core code shouldn't be called into with the
> > exception of some classes like CDVPlugin.h
> >
> >
> >
> > > - Move resource copy step into an external script
> > >
> >
> > +1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode
> >
> >
> > >
> > > - Make Xcode have a custom build step that runs prepare for CLI setup
> > >
> > >
> >  as long as it works for people not using the CLI
> >
> >
> > > - Make Xcode's project navigator point to your root www/ and merges/
> > >
> > >
> > also, have to make sure if user not using the CLI
> >
> >
> >
> > > - (CB-3900) Have PluginResult that gets populated lazily - at the time
> of
> > > being sent over the bridge.
> > >
> >
> > not sure what this is exactly, the issue referred to is an Android issue?
> >
> This is more of an Android problem, but there was a report of accelerometer
> callbacks being sent faster than the bridge could deliver them. Same thing
> could happen with FileTransfer progress events. The primary example is when
> there's a JS alert on Android. I figured that this scenario would apply to
> both platforms though.
>
> The idea here is that a plugin can send a PluginResult that has a callback
> in it instead of a value. The plugin then knows not to send any further
> PluginResults until that callback has been called. When the bridge goes to
> serialize pending PluginResults to be sent to JS, it calls the callback in
> order to populate the value of the result. This will ensure the
> PluginResult has the freshest data. This approach should be used for
> accelerometer, compass, progress events.
>

Re: Google Team's Task Backlog: iOS

[Andrew Grieve <ag...@chromium.org>]

On Thu, Jul 25, 2013 at 3:06 PM, Shazron <sh...@gmail.com> wrote:

> Comments inline.
>
>
> cordova-ios:
> >
> > - Move header symbols into .m files where possible (reduce API surface)
> >
> > Makes sense now since the core code shouldn't be called into with the
> exception of some classes like CDVPlugin.h
>
>
>
> > - Move resource copy step into an external script
> >
>
> +1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode
>
>
> >
> > - Make Xcode have a custom build step that runs prepare for CLI setup
> >
> >
>  as long as it works for people not using the CLI
>
>
> > - Make Xcode's project navigator point to your root www/ and merges/
> >
> >
> also, have to make sure if user not using the CLI
>
>
>
> > - (CB-3900) Have PluginResult that gets populated lazily - at the time of
> > being sent over the bridge.
> >
>
> not sure what this is exactly, the issue referred to is an Android issue?
>
This is more of an Android problem, but there was a report of accelerometer
callbacks being sent faster than the bridge could deliver them. Same thing
could happen with FileTransfer progress events. The primary example is when
there's a JS alert on Android. I figured that this scenario would apply to
both platforms though.

The idea here is that a plugin can send a PluginResult that has a callback
in it instead of a value. The plugin then knows not to send any further
PluginResults until that callback has been called. When the bridge goes to
serialize pending PluginResults to be sent to JS, it calls the callback in
order to populate the value of the result. This will ensure the
PluginResult has the freshest data. This approach should be used for
accelerometer, compass, progress events.

Re: Google Team's Task Backlog: iOS

[Shazron <sh...@gmail.com>]

Comments inline.


cordova-ios:
>
> - Move header symbols into .m files where possible (reduce API surface)
>
> Makes sense now since the core code shouldn't be called into with the
exception of some classes like CDVPlugin.h



> - Move resource copy step into an external script
>

+1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode


>
> - Make Xcode have a custom build step that runs prepare for CLI setup
>
>
 as long as it works for people not using the CLI


> - Make Xcode's project navigator point to your root www/ and merges/
>
>
also, have to make sure if user not using the CLI



> - (CB-3900) Have PluginResult that gets populated lazily - at the time of
> being sent over the bridge.
>

not sure what this is exactly, the issue referred to is an Android issue?

Re: Google Team's Task Backlog: iOS

[Filip Maj <fi...@adobe.com>]

I won't comment on the ios/android specifics and defer to Shaz/Joe on
those points :)


On 7/25/13 10:48 AM, "Andrew Grieve" <ag...@chromium.org> wrote:

>We've done some planning around what we'd like to get done over the next
>quarter, and so I thought I'd share.
>
>This isn't to say that we'll be going and doing these things without
>further discussion or proper JIRA issues. It also doesn't mean we will be
>solely focused on this list, nor that we'll actually end up completing
>everything on the list. Just that we *currently* think that these things
>should get done.
>
>
>cordova-ios:
>
>- Move header symbols into .m files where possible (reduce API surface)
>
>- Move resource copy step into an external script
>
>- Make Xcode have a custom build step that runs prepare for CLI setup
>
>- Make Xcode's project navigator point to your root www/ and merges/
>
>- (CB-3900) Have PluginResult that gets populated lazily - at the time of
>being sent over the bridge.