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:
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:
Adds a test runner for jest test and adds three simple test cases:
- render the app
- start a server
- client connecting to the app
Test can be run using `yarn test`.
To make the test runner work, some changes needed to be made:
- remove the export of `init()` from `'flipper'`, because it was a cyclic dependency
- updating Button.js to the new ref-API
Reviewed By: jknoxville
Differential Revision: D10027078
fbshipit-source-id: 49107b0dd4dec666b92ecd841422fe7e6b3a7756
Summary: Not collecting all debug logs because there are so many, but server ones are few and usually important for context on what's connected at the time.
Reviewed By: danielbuechele
Differential Revision: D9654402
fbshipit-source-id: 5ad090838be3e06c25bd93e4d85726822bd7fc4e
Summary:
Android devices don't always know their own serial.
But we do a certificate exchange using adb from the desktop, so we can provide it in the response.
After this the client will provide it every time it connects, so we can do things like filter plugins by device id.
For apps that have already done cert exchange, they'll continue to use 'unknown' as their id until they do it again with an up to date version of sonar.
We can think about forcefully stopping that, but I haven't done it.
Reviewed By: danielbuechele
Differential Revision: D9481460
fbshipit-source-id: f8932699711ebbec4260fabe32f87e6cdff920f2
Summary: The console was pretty spammy. This fixes some issues that were logged and changes many log statements to `console.debug` which are not shown by default.
Reviewed By: passy
Differential Revision: D9303011
fbshipit-source-id: 1102f4f8814152a45f155cb43488a515c2d4eee4
Summary:
[Step 1 of a protocol change between desktop app and flipper agent]
The flipper agent periodically tries to connect.
When it doesn't have the required certs, instead of trying to connect, it requests them from the desktop.
After requesting, it just continues the loop, trying to request.
The problem with that is
a) the desktop can take longer than one cycle to generate and provide the certs, meaning the agent will make overlapping requests, causing confusion and it to take longer than necessary.
b) the desktop can take less time than a retry cycle, but the agent will still wait before trying to connect.
Fixing a) by making the agent wait for a response from the desktop before continuing attempting to reconnect.
This means on the next connection attempt, it's guaranteed that the desktop is finished processing the CSR.
b) remains unfixed for now, but can be dealt with separately.
This is step 1 which adds an extra responder to the desktop app. It won't change anything until the agent starts
sending requestResponse messages instead of fireAndForgets. The plan is to leave this in place for a while to give users time to update, after that, we'll roll out the change to the agent.
Reviewed By: passy
Differential Revision: D9179392
fbshipit-source-id: 9a8021253dcd28c15cceeec23630a67aec219fd5
Summary: At the moment sonar doesn't work with physical iOS devices. Until we add that feature, to avoid confusion, tell the user that it won't work.
Reviewed By: passy
Differential Revision: D8859223
fbshipit-source-id: 318777406877e0f769c6d0dc5bbe745ca0565f55
Summary:
Some errors such as UI errors should be logged whenever they occur, but some, such as those that occur when a device keeps trying to connect but can't, should not be.
This adds the class and replaces the top recurring errors with it.
Reviewed By: danielbuechele
Differential Revision: D8639448
fbshipit-source-id: f001aa1e90eae6d26a8dbfcd3175b51fc486eae9
Summary: The `Client` and `Server` code was in one file, which was messy. This splits it into two separate files.
Reviewed By: emilsjolander
Differential Revision: D8186932
fbshipit-source-id: faa79d7dccd867d69ccd1bccd43a2cf85314b1b3
Summary:
At the moment, in sonar we have an error reporter and a Logger.
ErrorReporter can be encapsulated into Logger, so users don't have to decide between logging and reporting errors.
Reviewed By: danielbuechele
Differential Revision: D8531902
fbshipit-source-id: 3986f51ea163ac939f3baffd4db3ab968f2a0762
