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 <agri...@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 <mmo...@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 <agri...@chromium.org > > >wrote: > > > > > On Thu, Jul 25, 2013 at 3:06 PM, Shazron <shaz...@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. > > > > > >
