Summary: Rename ClientDevice to DummyDevice. It is being currently used in the case when we do cert exchange through WWW/Distillery. In this mode we are not able to figure out the exact device id(instead we create a fake one) and thus we would not like to use Android or IOSDevice for such cases.
Reviewed By: mweststrate
Differential Revision: D26944415
fbshipit-source-id: f9f76e8997cf5402ba5627ae1959f5a11e078bb1
Summary:
*Stack summary*: this stack adds ability to manage device plugins in the same way as client plugins: install, update, uninstall, enable (star) and disable (unstar) them.
*Diff summary*: changed the way how plugin compatibility with devices is checked from dynamic call to "supportsDevice" to static checks of "supportedDevices" metadata property which make it possible to check compatibility without even downloading plugin from Marketplace.
Changelog: plugin compatibility with devices is now checked according to metadata in property "supportedDevices" in package.json
Reviewed By: mweststrate
Differential Revision: D26315848
fbshipit-source-id: 6e4b052c4ea0507ee185fc17999b6211cdb11093
Summary: Plugin metadata format extended to include type of each plugin (client / device) and list of supported devices (android/ios/..., emulator/physical, etc). This will allow to detect plugins supported by device even if they are not installed and only available on Marketplace.
Reviewed By: mweststrate
Differential Revision: D26073531
fbshipit-source-id: e331f1be1af1046cd4220a286a1d52378c26cc53
Summary:
I've re-designed interfaces describing plugins as I found that mental overhead working with them became too expensive because of slightly flawed design. However this cascaded changes in many files so you can see how extensively these interfaces used in our codebase.
Before this change we had one interface PluginDetails which described three different entities: 1) plugins installed on the disk 2) plugins bundled into Flipper 3) plugins available on Marketplace. It's hard to use this "general" PluginDetails interface because of this as you always need to think about all three use cases everywhere.
After this change we have 3 separate interfaces: InstalledPluginDetails, BundledPluginDetails and DownloadablePluginDetails and things became much type-safer now.
Reviewed By: mweststrate
Differential Revision: D25530383
fbshipit-source-id: b93593916a980c04e36dc6ffa168797645a0ff9c
Summary: Extracted plugin marketplace API to a separate file and updated it to load full plugin manifests.
Reviewed By: passy
Differential Revision: D25181759
fbshipit-source-id: a63f9ce16249ccc170df148cef5c209fdc6d4d6d
Summary:
To know whether plugins should be mounted with the old setup or new setup (with a Provided / context based api), we need to be able to recognize whether a plugin is written with the old or new setup.
We do this by checking if the flipper-plugin dependency is declared as peer dependency. This we can to check for SDK compatibility as well.
Reviewed By: jknoxville
Differential Revision: D22043085
fbshipit-source-id: 21afabb6e58d86253a464470f4690c51cced87ab
Summary: Use interface PluginDetails everywhere where plugins are handled and removed PluginDefinition type which was effectively a subset of PluginDetails
Reviewed By: mweststrate
Differential Revision: D21927456
fbshipit-source-id: 434ebeef955b922cc11757e78fbba8dec05f1060
Summary: Added "description" field to PluginDetails interface and read it from package.json
Reviewed By: passy
Differential Revision: D21927391
fbshipit-source-id: 0513637d3afa3d8be8e2bc8ee87cc1d77c5e2250
