Summary:
Plugins were loaded in `/plugins/index.js` which was loaded once at launch of the app. This moves the list of available plugins to redux. This way, plugins can be dynamically added. The redux store keeps to Maps of plugins (devicePlugins and clientPlugins) with their ID as key:
```
devicePlugins: Map<string, Class<FlipperDevicePlugin<>>>,
clientPlugins: Map<string, Class<FlipperPlugin<>>>,
```
On launch of the app, all plugins bundled with the app and the one found in `pluginsPath` are dynamically added.
This changes now allows to add new plugins at any time. All components that need to know which plugins are available (e.g. the sidebar) are connected to the redux store. This way, they will automatically update, whenever a new plugin is added.
- add `plugins` to the redux store to keep the list of available plugins
- add a plugins dispatcher, responsible for loading the plugins on launch
- connecting all React components that imported `plugins/index.js` before to the redux store to get the plugins from there.
- moved the updating of the MenuBar to the plugins dispatcher as it needs to update whenever a new plugin is added.
Reviewed By: jknoxville, passy
Differential Revision: D12449236
fbshipit-source-id: 6ef3e243e2c80443614b901ccbfde485fcb4301c
Summary: Puts the connection state into redux so we have more visibility on what's happening in bug reports and in general allowing us to display it on screen.
Reviewed By: passy
Differential Revision: D13060455
fbshipit-source-id: c79b4b7d6a1155d86128a5d8d1174ead9e4514ae
Summary:
Allows filtering notification by category. Category filters are also persisted in redux.
Adds a test suite for notification reducer
Reviewed By: passy
Differential Revision: D12999884
fbshipit-source-id: 5f8d2357e52f091c17b726e1f89ed68f3b7294fb
Summary: This diff adds action buttons to the notifications. Notifications with actions can only be sent from the main process. This is why we need to send a message to the main process which then shows the notification. The action callbacks are sent back to the renderer process to handle the action and log the event.
Reviewed By: passy
Differential Revision: D12999886
fbshipit-source-id: b415fded3172582fad11d88cabf0cfc5b3b8d4f9
Summary:
Flipper tracks devices on an adb connection. If the adb server gets killed, it deletes all devices, but doesn't attempt to reconnect.
This gets it to rety after 500ms.
Reviewed By: priteshrnandgaonkar
Differential Revision: D10526974
fbshipit-source-id: a2101067f2245b728f458fc5e06dc68833c5e772
Summary:
I feel like doing async stuff here isn't a good idea in general.
But more pressingly, it means you can't immediately call server.close() after new Server(), because the things to close haven't been created yet.
Reviewed By: danielbuechele
Differential Revision: D10488301
fbshipit-source-id: 76ebe91e0c09f353e0bdb9f2e4116757e757abb2
Summary: Clicking on a notifications links to the Notification Hub highlighting the selected notification.
Reviewed By: jknoxville
Differential Revision: D10487822
fbshipit-source-id: ed907ec244bef970d1b30ddb719856949229d0c4
Summary: Adding a GK to be able to disable notifications remotely.
Reviewed By: passy
Differential Revision: D10467036
fbshipit-source-id: ee555bd73cb5c58d1113e28fe88fe605480865cf
Summary:
When a client disconnects, we want to remove all plugins states for this client, so the next time the client reconnects the plugins start with an empty state.
The main use case for this is when recompiling the app and launching it in the simulator, we don't want to show old network-requests or QPL events.
Reviewed By: passy
Differential Revision: D10447808
fbshipit-source-id: 5fb3f24ee37f564e8dc00315bff86a2bcd5f65f2
Summary:
Adding a static method plugins can implement to trigger notifications:
```
static getActiveNotifications: ?(persistedState: P) => Array<Notification>;
```
When the plugin's persisted state changes, this API is called from the `notification`-dispatcher which updates the notifications store.
Reviewed By: passy
Differential Revision: D10378434
fbshipit-source-id: 778fe3ad4229b03bd5ba14ebfdafa5020c25f34f
Summary:
- Set userPrefferedPlugin for external deeplink
- Listen for deeplink in renderer process and navigate accordingly
Reviewed By: passy
Differential Revision: D10339035
fbshipit-source-id: 4de6249a0672f9ce02b0dfb78a4563302c308578
Summary: Apple seems to have changed the key for device availablility. We check for both now.
Reviewed By: jknoxville
Differential Revision: D10401073
fbshipit-source-id: 284a168a701eb2d5d9b3cbcac2aa6276ee1a2211
Summary: Removing PortForwarderMacApp as it is not used anymore. Before it was used to allow us to debug physical iOS device. However, the support for physical iOS device was removed a while ago for security reasons. The PortForwarder was not in use anymore so it is safe to remove it.
Reviewed By: passy
Differential Revision: D10337888
fbshipit-source-id: 93f508ec524a0fc055141176c06d7e7169d83f16
Summary:
Adds a new type of plugin: `FlipperBackgroundPlugin`
Background plugins are not torn down when the user switches to another plugin so they keep receiving messages in the background.
Background plugins need to use persistedState to keep their data. To handle the messages received in the background they need to implement a static method that merges a message with the current state from redux. The plugin doesn't need to call this method itself, it is called from `client.js`.
```static persistedStateReducer = (
persistedState: PersistedState,
data: Object,
): PersistedState
```
This method is used to handle messages in both foreground and background.
Reviewed By: danielbuechele
Differential Revision: D10256305
fbshipit-source-id: d86da9caa1b75178841a9a347eb427112141eaa3
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: Adds a notification disapatcher to the redux store which triggers native notifications.
Reviewed By: jknoxville
Differential Revision: D10301490
fbshipit-source-id: d926d9a5378359ebb98a8b5816100f41db1e13e6
Summary:
First connection attempt to iOS device was only made after 3000ms. This caused all iOS devices only show up after this delay.
Now, the devices are queried immediately.
Reviewed By: passy
Differential Revision: D9613057
fbshipit-source-id: a14e3f02576ec5e159f4002bf68efe53236dcc50
Summary:
`largeFrameDrops` are added to the usage tracking.
Similar to our other apps, we are considering a drop of 4 or more frames as a large frame drop. While a single frame drop might not be relevant to the user, large frame drops are a more relevant number to optimize for.
Reviewed By: passy
Differential Revision: D9358795
fbshipit-source-id: d9354695c816ba6c40676df6f3c6f3f070e28269
Summary:
This diff adds the ability for a windows desktop app to be a selectable device for Sonar.
just to over-communicate what I'm thinking regarding the logging: windows system logs don't have a lot of valuable information in my experience, and there is a ton of garbage, but there is probably a way to tap into that if we want.
however, I was thinking that redirecting stderr/stdout from every connected process would be useful. i.e. OVRServer could register a log plugin and it would write to the device's log output. not sure if this would be better than just having a logger plugin. This is probably a pretty naive question and this probably isn't the place to have this conversation...but here we are :)
Reviewed By: jknoxville
Differential Revision: D8861986
fbshipit-source-id: f6ccba28729692ae4566dd24302268ad54d437eb
Summary: Adding dropped frames counter to usage events. This will allow us to track performance improvements.
Reviewed By: passy
Differential Revision: D9238608
fbshipit-source-id: d9adbb0ed72aaf13802f5eef39606970b64c8e36
Summary:
Device connection didn't work on Linux due to netcat behaving differently.
I also played around with the `nc` and `node-netcat` packages, but they would
either crash the node stack or fail to compile with Babel. Oh glorious
JavaScript world.
Reviewed By: danielbuechele
Differential Revision: D9194591
fbshipit-source-id: 58e5b8d6b4a66e791e750de2f1449dcb8fc338ae
Summary: Adding a flowtype library definition for electron 3 and fixing related type errors
Reviewed By: passy
Differential Revision: D9124758
fbshipit-source-id: e09cb5b05ba952e7f95f68f9043edc586f81ae83
Summary:
Deselect plugin when app disconnects, but store the information that the users had the app selected. When the app conencts again, restore the user's selection.
This also stores the device seleced by the user and reselects the device if it connects.
Reviewed By: xiphirx
Differential Revision: D8833948
fbshipit-source-id: ad3ef54681550ae674bdd4e695d677aea5c14588
Summary: The redux store keeps a list of devices. For the active device, it stored the index in that list. This diff now stores a reference to the active device instead of the index in that array. This changes makes it easier to get the reference to the active device in a component.
Reviewed By: jknoxville
Differential Revision: D8767514
fbshipit-source-id: c740cf98d6039223ce8d5a47bcd277989fe70bc3
Summary:
Refactors the plugin architecture of Sonar:
- Before plugin rendering had it's own implementation of the react lifecycle. This means the `render`-function was not called by react, but rather by the application it self. In this diff, the render method is now called from react, which enables better debugging and allows react to do optimizations.
- Business logic for querying emulators is moved away from the view components into its own dispatcher
- All plugin handling is moved from `App.js` to `PluginContainer`.
- The sidebar only shows one selected device. This allows us to add the screenshot feature as part of the Sonar main app and not a plugin.
- This also fixes the inconsistency between the devices button and the sidebar
Reviewed By: jknoxville
Differential Revision: D8186933
fbshipit-source-id: 46404443025bcf18d6eeba0679e098d5440822d5
