On Fri, Feb 22, 2013 at 2:02 PM, Shazron <shaz...@gmail.com> wrote: > Feasibility > --------------- > For iOS, plugins can be static libraries, that is no problem. You cannot > use dynamic libraries in iOS (the .frameworks you see used are essentially > static libs in a different packaging). Assets should be .bundle packages > (essentially folders with the .bundle suffix). So you will have the .a, > header files, and any .bundle assets. > > Problems > -------------- > Authors have to make sure that the .a lib is a fat binary that includes all > architectures. If not, a user cannot test on the Simulator for example, if > the i386 architecture wasn't included. I suppose plugman or some tool can > check for this by using the 'lipo -info [lib]' command. >
This is the biggest trouble we've had when trying this approach before. There's also debug vs release. It does seem to be the way many people are releasing their SDKs though. e.g. https://developers.google.com/maps/documentation/ios/start#adding_the_google_maps_sdk_for_ios_to_your_project > > > Benefits > ------------ > Plugin marketplace, selling of plugins without releasing the source. > Plugman already supports .a plugins indirectly, you would just add the > plugin as a <framework> instead of a <source-file> in plugin.xml > > > On Fri, Feb 22, 2013 at 9:29 AM, Michael Brooks <mich...@michaelbrooks.ca > >wrote: > > > Hi all, > > > > I'd like to pick your brain around the feasibility of plugins existing as > > static or dynamic libraries. > > > > I had this idea a few years ago, when we first started discussing > plugins. > > At the time, it was > > possible on BlackBerry and, with some work, possible on Android and iOS. > > However, a lot > > has changed in the last few years, so I'd like to revisit the topic. > > > > Overview: > > > > - A plugin developer would compile their plugin as a static or dynamic > > library. > > - A plugin developer would publish their plugin as the library. > > - An app developer would install the static or dynamic library. > > > > Benefits: > > > > - The plugin is only compiled by the author who distributes it. > > - For complex plugins, this may help avoid compile-time errors around > > dependencies. > > - The plugin may be able to bundle some of its assets, simplifying the > > installation process. > > - Can be an alternative (not replacement) to distributing plugins as > > source-code. > > > > Questions: > > > > - For each platform, how feasible is this? > > - What problems (or other benefits) would exist with plugins as > libraries? > > > > Thanks! > > Michael > > >
