Summary:
There's been a bug here where the id was treated as a pluginId.
Renaming to make it clear.
Reviewed By: passy
Differential Revision: D16338884
fbshipit-source-id: 42c6c92653811d88cd37ebf4834346b1f0bb2c2a
Summary:
Original commit changeset: 650ef1344b8b
Backing this out until we can come up with a better way to do it.
The change was introduced so that when a device disconnects / crashes, we don't lose all plugin state, and you can still see what was on screen before the crash..
However, there are some problems with this solution, which get quite complicated. Putting them here for future reference:
* Closing an app results in the plugins staying there, and there's no way to tell it's not actually connected.
* If the app reconnects, the JS plugin doesn't get re-initialized. Even though the client plugin has been.
Reviewed By: bnelo12
Differential Revision: D16280931
fbshipit-source-id: 48e09b876e631aa87372054e706cdb9a2b3e2eb7
Summary: When an Android device disconnects, the device is marked as offline. In this diff, we want to make sure the client for the disconnected apps is not removed, but converted into a "disconnected" client. This makes sure plugins are still shown for the disconnected app.
Reviewed By: passy
Differential Revision: D15985424
fbshipit-source-id: 650ef1344b8be4411794b0344805cb75ceae4a83
Summary:
Using `process.exit()` stops the node process without waiting for the event loop to finish, so when using async i/o, which is what happens when piped, if the output is buffered, the process can terminate before it finishes flushing the buffer.
This means you only get some of the output and the JSON is malformed.
This fixes it by calling `process.exit()` inside the flushed callback.
Reviewed By: passy
Differential Revision: D15624806
fbshipit-source-id: ea540ed5a40fb1811e5b705b190da96c8e54730d
Summary:
Currently when a client connects, if there's no matching device we know of, it emits an error.
The problem is that there's a race between clients connecting and devices being detected, if the client connects first, then we'll emit this error, even though the device is displayed shortly afterwards.
Fixing this by waiting 2 seconds after a client connects, and then if it's still connected, checking for a matching device. This should be enough time to make this error more reliable.
Reviewed By: passy
Differential Revision: D14126315
fbshipit-source-id: c81b2c6d9a6e0639a656d1a4d7a8f999f715bfbf
Summary:
Unified all imports of Logger. Some were called LogManager before.
Now the fb-stub and the fb variants use the same interface.
Constructor of Logger is no longer exposed so it can't be initialized twice, unless in the case you're explicitly using the fb variant, which has extra functionality.
Reviewed By: danielbuechele
Differential Revision: D14083929
fbshipit-source-id: 9b61a06e1264d5f142b5a9188465c99deaf18193
Summary:
Fixes required to be able to run Flipper in node.js:
* Adds checks if the `window`-object exists before using it, to allow running in node.
* Imports from within Flipper should directly reference the file they are requiring instead of `import from 'flipper'`. This was done in most of the places. Fixed a few occurrences where this wasn't the case. This is to prevent cyclic dependencies in node.
* shared packages (React, ReactDOM and Flipper) were exposed on the `window` before, changed this to `global` as this works in browser and node.
* Adds some missing methods to our electron stubs (used for testing and headless Flipper)
Reviewed By: passy
Differential Revision: D13786577
fbshipit-source-id: 145d560f1446e7d0bdec2acd8dd54dae983d7b36
Summary:
- New improved UI
- Instead of sending the callstack as a string from android, now sending it as an array
- Deeplink to Logs support just for android. In iOS crash is not automatically logged in Logs plugin, atleast thats what happens in sample app
Reviewed By: jknoxville
Differential Revision: D13216477
fbshipit-source-id: d8b77549c83572d0442e431ce88a8f01f42c9565
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:
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:
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:
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:
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
