Developer Story of iPDF
iPDF is not yet another office productivity app. It’s a platform. A third party developer, which literally means you, can develop plugins to extend its capabilities. iPDF provides the infrastructures like the ribbon user interface, adding items to the data grid, processing them, notifying user when done, etc. You only have to focus on specific functionality you intend to implement.
In iPDF 1.0, third party developer can only add web service to the services gallery on the Publish tab. With next release, which is due out in August, you will be able to add tabs, add galleries, pop up a notification to user, add your own column to the data grid, scripting iPDF using a BOO like language, and more. Oh, one side note, we are going to use MEF – Managed Extensibility Framework. Stay tuned.
First, let’s dive into how iPDF loads those web services plugins. On startup, iPDF scan the ‘Services’ folder in the iPDF installation directory for DLL files in a background thread. For each dll, iPDF uses .net reflection API to determine if it contains one class which inherits from a certain class called CloudService. If it does, then iPDF will instantiate one instance of that class, adds it to the services gallery with an icon supplied by that class. And when user does a certain action on the Publish tab, the action will be delegated to the current selected service instance to do something about. And that’s pretty much it.
As a plugin developer, you have to implement a class that inherits from the CloudService and plug into iPDF by placing your assembly in the ‘Service’ folder. And that’s it.
iPDF uses .NET reflection API to load plugins and as you know, reflection can be very slow. So for performance’s sake, you probably should not build one giant assembly and put it into the ‘Services’ folder. Nor you should create a bunch of small assemblies and put them all in the ‘Service’ folder because that would pollute the ‘Services’ folder, thus will extend the process of loading ‘Services'.
Instead, it is preferred that you create a stub assembly which inherits the CloudService class, do some basic stuff and put all the heavy work in other assemblies and reference them from your stub assembly. And then you only put your stub assembly in the ‘Services’ folder of iPDF and put the rest of your assemblies which the stub assembly depends on into GAC or wherever you like. This way, iPDF can loads your plugin pretty fast because your stub assembly is small and simple. It also gives you flexibility which is good I think.
Ok, that’s it. And you can download our sample plugin. It is well commented and well organized. At least we think so. One side note, the sample plugins are actually the ones gets preloaded in iPDF 1.0. It’s a dirty little secret we hope you all can keep to yourselves only. J