Summary:
This change isolates the usage of folly async from Flipper. Is now self-contained in Flipper Folly schedulers.
Users of Flipper can decide not to use the types defined in that header and implement their own.
NOTE: changes are minimal, we are just replacing direct calls to folly event base with a scheduler which simply relays this on to folly.
Reviewed By: fabiomassimo
Differential Revision: D36626483
fbshipit-source-id: add0241caf4af0aa5c3b5c2e7efc2e725f5400ab
Summary:
This change isolates the usage of folly async from Flipper. Is now self-contained in Flipper Folly schedulers.
Users of Flipper can decide not to use the types defined in that header and implement their own.
NOTE: changes are minimal, we are just replacing direct calls to folly event base with a scheduler which simply relays this on to folly.
Reviewed By: fabiomassimo
Differential Revision: D36052198
fbshipit-source-id: 170d64a324a1f1f100224e2622a59cbac3c8b642
Summary:
Trigger a manual disconnect on deallocation. This was done automatically for us when the underlying socket gets released. But, this gives a bit more visibility and control onto exactly when this is going to take place.
Additionally, do not clear the message handler when a message is received.
It is not required as sendExpectResponse is one time called only used for certificate exchange. If this takes place again, a new handler will be set anyway.
Reviewed By: passy
Differential Revision: D31231828
fbshipit-source-id: 36ad13564a358b88d1618e94195fe05433d80993
Summary: This change reverts a revert. The change was reverted for 'unrelated' issues addressed on this diff dependencies.
Reviewed By: passy
Differential Revision: D30696113
fbshipit-source-id: 8591d6ea79999597024c316e9927a346979e5219
Summary: Revert D30371791 (cac09d14aa) to address undefined symbols for a few sandcastle jobs
Reviewed By: fabiomassimo
Differential Revision: D30606610
fbshipit-source-id: 24a5c08bcf5456a96469650a4207b05970399181
Summary:
Contains the implementation of FlipperWebSocket with any necessary changes to use it but without switching it on.
About SocketRocket and Cocoapods
A decision had to be made about whether to define different sub-specs, one for RSocket and another for SocketRocket.
I've opted to keep the podspec as is because:
- Keeps pod consumption as is.
- Makes easier to switch implementations using GK.
- There's no intention to keep RSocket going into the future. So, there's no point in creating a sub-spec only to remove it in the future.
- SocketRocket is a relatively small library so is not contributing to a significant increase in binary size.
If, as reviewer, you consider a subspec makes more sense, then feel free to reach out to discuss.
Reviewed By: fabiomassimo
Differential Revision: D30371791
fbshipit-source-id: 225c5b1de76aff1a6e36640a41765b963aaa2796
