Summary:
Device plugins have an activate and deactivate hook, that reflects the plugin being selected in the UI. Added these same hooks to client plugins as well. In practice they are called at the same times as `onConnect` and `onDisconnect`, except for background plugins, which connect only once, so it is pretty useful to be still able to make the distinction.
Since there is now quite some common functionality between plugins and device plugins, will clean things a bit up in a next diff
[Interesting] as it explains the difference between the different lifecycle methods of plugins, and the impact of being a background plugin
LIfecycle summary:
1. app connects
2. for background plugins: connect them (`onConnect`)
3. user selects a plugin, triggers `onActivate`. will also trigger `onConnect` the plugin if it _isnt_ a bg plugin
4. user selects a different plugin, triggers `onDeactivate`. will also trigger `onDisconnect` if it isn't a bg plugin.
5. app is unloaded. Triggers `onDisconnect` for bg plugins. Triggers `onDestroy` for all plugins,
Reviewed By: jknoxville
Differential Revision: D22724791
fbshipit-source-id: 9fe2e666eb37fa2e0bd00fa61d78d2d4b1080137
Summary:
This stack introduces Sandy device plugins, they are quite similar to normal plugins, but, a devicePlugin module is organized as
```
export function supportsDevice(device): boolean
export function devicePlugin(devicePluginClient)
export function Component
```
Device plugins get access to the device meta data and can subscribe to the `onLogEntry` callback and `onDestroy` lifecycle.
They will be able to store state just as normal plugins, but can't send or receive methods, so devicePluginClient is a bit limited.
This diff only sets up most of the new data structures, and makes sure everything still compiles and no existing tests fail.
To prevent this diff from becoming to big, actually loading, rendering and testing device plugins will be done in next diffs
Please take a critical look at the api proposed and the (especially) the public names used :)
Reviewed By: passy, nikoant
Differential Revision: D22691351
fbshipit-source-id: bdbbd7f86d14b646fc9a693ad19f33583a76f26d
Summary:
Bolded the record fields' keys if it is consistent (in the consistency white list).
*if the key is within an object, information on whether it is consistent will not be available in preview. The Object has to be physically expanded by the user in order to see the bolded key.
Reviewed By: mweststrate
Differential Revision: D22416084
fbshipit-source-id: 7eb1d8c65be07f880722a133b70195a4a63f0e75
Summary: This diff enables the installation for iOS simulators. This also fixes the error view created when there is an error. Right now there is a bug on my machine where idb doesn't detect my physical device. But once it is detected, it will work.
Reviewed By: mweststrate
Differential Revision: D22137831
fbshipit-source-id: b6d6f77318c6baef78c35af73db3969b7dd1b907
Summary: Fixed direct source import of Flipper code from layout plugin which broke its packaging
Reviewed By: cekkaewnumchai
Differential Revision: D22135716
fbshipit-source-id: 8f67a21ed94c13dd73d24ef8692d37ae51963319
Summary:
This diff is not meant to land as-is, but instead to generate discussion on how to properly accomplish this.
The goal is to add a Layout plugin sidebar extension that displays the NT reduction trace when an NT component is selected.
Note this is a feature that exists today (when whitelisted on `reduction_trace_check` GK) via the `SKComponentLayoutDescriptor` API, where we'd include the entire JSON representation on every element and display that in a standard inspector in the sidebar. We have a new metadata system where we only include a metadata id and Flipper can separately request the metadata, which is much more performant. Also, we have an existing `NTReductionTracePanel` component we'd like to use that handles requesting and displaying that information in a much better way.
I'd still like to use the `SKComponentLayoutDescriptor` API (or something similar) to have access to that component's metadata id in order to decide whether the panel should appear and of course that id is needed for the panel. This works well right now (see test plan), but as you can see, it's less than ideal in that it needs to look into `Extra Sections` then `Native Templates` to get that information. This might be acceptable for the time being while we think this API through, but I wanted to get input on if we can do better before trying to land.
Additional questions:
- Why are `SidebarExtensions` exported from the "flipper" module, when they only work with and import from the Layout plugin?
- There are two `InspectorSidebar` components - one in the Layout plugin and one in main flipper module [here](https://fburl.com/diffusion/ecg8lhfq) that I don't think is being used?
Reviewed By: mweststrate
Differential Revision: D21887701
fbshipit-source-id: 23ed19c08b68b4b1115b8cc6af84af9e87e91128
Summary: Persist state in Mobile builds plugin. This diff also moves the logic of percentage updates in the persisted state.
Reviewed By: mweststrate
Differential Revision: D21840853
fbshipit-source-id: 3246cdfecfca12cd0f269f5a87646cf619380999
Summary:
See previous diff, let's store the collapsed state of sidebar sections in local storage.
Introduced a reusable hook to take care of that.
Changelog: Device plugins are now expanded by default, and the expand / collapse state will now be remembered across restarts
Reviewed By: passy
Differential Revision: D21903394
fbshipit-source-id: a3c0231acc0aa0877522ec328eedd09cb11aedb1
Summary:
- Add value for null type to use `.value` easier
- Add value to string by directly converting to string if possible; otherwise null
Reviewed By: jknoxville
Differential Revision: D21788242
fbshipit-source-id: f3a9f995de6b4cb1b304981c8adaaba70105c988
Summary:
Update the UX of the mobilebuild download. When one clicks download one can see the the installation in progress in the main screen. Once its downloaded, you can open the finder pointed to the folder of download.
I didn't write the test for InstallSection as I was not able to test it through react-testing library. Seems like the data gets added to the document little late and not instantly.
Next work:
- Search in sidebar
- Persist downloaded app data for a session
- Show download data in the form of progress bar.
Reviewed By: mweststrate
Differential Revision: D21709229
fbshipit-source-id: e67db68ff16155230becf86c913dc6b1ec9d482c
Summary:
This diff updates the sidebar to show the recommended and all build types.
Also there is error handling in place along with tests. Right now the download happens by opening browser and the build gets downloaded in the download folder. But later in the diffs I will improve this flow to do that in the Flipper with a UX showing status updates.
Reviewed By: mweststrate
Differential Revision: D21556383
fbshipit-source-id: 6de9a00fe416c22cae7bacf91828a2221644eac7
Summary: FileSelector was added in D19743998, but it was not exported to be used by other. This diff exports it so that developers can use.
Reviewed By: mweststrate
Differential Revision: D21653870
fbshipit-source-id: 062247fa7a14c7ddf87c927205880a695598928d
Summary: Naive implementation of searchable data inspector: matching of search term agains first level keys of data
Reviewed By: cgrushko
Differential Revision: D21510073
fbshipit-source-id: 2010e584248a64fb3351c95a5646b1935445a13b
Summary: a bit of refactoring since we are going to use elements inspector a lot in NT related plugins
Reviewed By: jknoxville
Differential Revision: D21155830
fbshipit-source-id: 0ff6acf97658bccbbed86388257bbad207fd65b4
Summary: We are working on integrating new NT debug api and debug metadata is stored in sandbox
Reviewed By: jknoxville
Differential Revision: D21155832
fbshipit-source-id: 2a7c8303e62793092f9e5b27f61d9db38eab14c5
Summary: there are two plugins which uses copy-pasted ToolbarIcon and at least one more where it will be helpful. Let's move it to components folder
Reviewed By: nikoant
Differential Revision: D21089290
fbshipit-source-id: a14dcd56633dd24016711e34308b94023fcb40ed
Summary:
1) moved "sonar/desktop/src" to "sonar/desktop/app/src", so "app" is now a separate package containing the core Flipper app code
2) Configured yarn workspaces with the root in "sonar/desktop": app, static, pkg, doctor, headless-tests. Plugins are not included for now, I plan to do this later.
Reviewed By: jknoxville
Differential Revision: D20535782
fbshipit-source-id: 600b2301960f37c7d72166e0d04eba462bec9fc1
