Summary:
Background plugins are initialised when flipper connects.
But there's no isolation, so if any fail to initialize, then we don't carry on initializing the rest.
This fixes that by skipping failed ones only.
Reviewed By: passy
Differential Revision: D17600854
fbshipit-source-id: 2ef04cbcecda78ca448c2f4d56639ba63792e2f7
Summary:
In tests, the instance is never initialized and it's hard to guard against null when the
instance isn't initialized to nullptr (instead being random data).
Reviewed By: ximyu
Differential Revision: D16984717
fbshipit-source-id: 414539e1117abaad16df9f9b7d3b8dbb328e38d0
Summary:
`/*` is the standard throughout open source code. For example, Firefox uses single /*: https://hg.mozilla.org/mozilla-central/file/21d22b2f541258d3d1cf96c7ba5ad73e96e616b5/gfx/ipc/CompositorWidgetVsyncObserver.cpp#l3
In addition, Rust considers `/**` to be a doc comment (similar to Javadoc) and having such a comment at the beginning of the file causes `rustc` to barf.
Note that some JavaScript tooling requires `/**`. This is OK since JavaScript files were not covered by the linter in the first place, but it would be good to have that tooling fixed too.
Reviewed By: zertosh
Differential Revision: D15640366
fbshipit-source-id: b4ed4599071516364d6109720750d6a43304c089
Summary:
The graphql plugin gets injected after the client is connected. In this case, earlier we didn't use to call `didconnect` assuming that it will be called when the plugin gets clicked by the user in the UI. But that is not true anymore as GraphQL plugin is a background plugin, And we don't call `didConnect` for the background plugins on the user click in the UI, as we assume that background plugins should have already received the call before.
This diff fixes the issue by calling didConnect on the background plugin which gets added after the `FlipperClient` is initialised.
{F152780726}
Look at the bug:
Reviewed By: danielbuechele
Differential Revision: D14369587
fbshipit-source-id: f75bf4e4463a31fa4735e90245c46632858a32b7
Summary: Since plugins aren't under our control, they might throw exception pointers. We can still extract the useful info in this case.
Reviewed By: passy
Differential Revision: D14244362
fbshipit-source-id: 5f18100c08160e7514b3fd88ec47809cb37e9770
Summary: Allows plugin to check if something is supported by that app, for example an extension command or a new feature, before trying to use it.
Reviewed By: passy
Differential Revision: D14225957
fbshipit-source-id: 3c5a29a06b56fe5f1da772824232547447872344
Summary:
Flipper exposes a call() api to plugins which lets them call their sdk component, and it returns a promise with the response.
Currently this is done by sending a fireAndForget request, noting the id of the request, and then receiving fireAndForget requests and matching up the ids to give the result back to the right plugin promise.
Instead, it will be simpler to use rsocket requestResponse, instead of fireAndForget, which is for this exact use case. This diff adds a requestResponse handler to the SDK, so that it can deal with such requests and respond accordingly, while preserving the current functionality if it receives a fireAndForget.
So this part is backwards compatible and should be safe to land in isolation.
A later diff will change the desktop app to use requestResponse, which may not be backwards compatible, so that will have to be deployed more carefully.
Reviewed By: passy
Differential Revision: D13974049
fbshipit-source-id: b371d94a86b1f186375161ed8f2242a462ce418f
Summary: This diff adds support to send crash notification whenever the cpp exception of Flipper is suppressed. Also updated the tests regarding the same
Reviewed By: jknoxville
Differential Revision: D13635822
fbshipit-source-id: 01e4a57c391476e5b044e64946d337cb4582a527
Summary: Wraps flipper client methods to avoid crash. Also added a tests which makes sure that malcious plugin cannot cause a crash
Reviewed By: jknoxville
Differential Revision: D13153277
fbshipit-source-id: ac21731fa3c4eb447f189e61f61b9e83aad91e13
Summary: Makes QPL iOS plugin to work in background
Reviewed By: jknoxville
Differential Revision: D10446049
fbshipit-source-id: 02ad6f6f83b13e326b6fdd8aa972fa7d29c76eb9
Summary:
This diff sets up flipper for running plugins in background. This diff does the following
- Adds a function named `runInBackground` to the interface `FlipperPlugin` to make the plugins opt in to be run in background, default is false
- Changes the javascript side of the flipper to store the messages received by the plugins in background
- Process the stored messages when the plugin in background becomes active
- Currently I have just turned on network plugin to be in background mode.
- Remove the buffering from the network plugin, as it will run in background
- Write a batching layer to batch the messages and send to flipper.
Note: I haven't tested the wilde app yet, but the sample app works. I will remove the "[WIP]" from the title once I have tested it in wilde
Reviewed By: danielbuechele
Differential Revision: D10301403
fbshipit-source-id: 034eebf659a545d6b480a4ac1b73b0aa4b2f9797
Summary: Part of sonar to flipper rename
Reviewed By: passy
Differential Revision: D9920275
fbshipit-source-id: 02f97d1e51d58864283d26e8d3a724cac973e938
Summary: Part of sonar to flipper rename
Reviewed By: passy
Differential Revision: D9919821
fbshipit-source-id: a44a2a04d5463750f884f8bf1328e02d56593e82
Summary:
Part of Sonar -> Flipper rename.
It's about time this is renamed from *Websocket as well, since it doesn't use websockets anymore.
Reviewed By: passy
Differential Revision: D9919695
fbshipit-source-id: 78a63bfb7d5de19c093b7fb775d1426b4fc58f77
