Hydra 3 introduced a new direction of our well-received plugin framework. While previous versions of Hydra were targeted solely at Win32 Delphi developers and enabled them to build plugin-based systems for that platform, Hydra 3 widens the scope of the product by providing support for a new goal and target audience: Delphi developers that seek to leverage the .NET framework in their application development.
Hydra 4 expanded on this to also add support for Silverlight plugins, as well as FireMonkey and 64-bit Delphi hosts and plugins.
The all new Hydra 5 adds support for creating CPU native pluigins in Oxygene, C#, Swift and Java via oiur new Island platform in Elements 9.1 and later, and mixing those into your Delphi or >NET host applications, as well.
Ever since it was originally announced, the Delphi community has had a love/hate relationship with .NET. Being spoiled by the richness in RAD development they had been enjoying for years, the community was quick to dismiss .NET as something that might bring benefits to MFC or Visual Basic developers, but would bring little benefit over Delphi and its powerful VCL class library and RAD form designers. Many also saw .NET as the latest development fad that would excite people for a while but quickly die out for lack of serious adoption.
Three significant releases later, it has now become obvious that these assumptions were wrong. The .NET 2.0 core framework has introduced significant development advances in the .NET languages, such as Generics that make .NET development attractive and, with the new services branded under 3.0, Microsoft has introduced a significant new paradigm for user interface design that is likely to revolutionize how tomorrow's Windows desktop applications will look and feel. The third party market for .NET has developed strongly, with a vast range of professional components being available in all imaginable areas – while at the same time the Delphi component market seems to be winding down, as many third party vendors scale down their support in favor of .NET or are leaving the market altogether.
As developers eye the new features and technologies becoming available on the .NET side, it becomes an attractive option to leave Delphi behind and fully leverage the new platform for future development.
Unfortunately, this is not an easy decision for many developers, for a multitude of reasons. To start with, most developers are not in a vacuum and able to start fresh on a new project, but have existing code bases written in Delphi, either in the form of existing projects that need to be extended and maintained, or at least have large class or function libraries or base frameworks that are time-proven and well-tested. These days, while customers expect ever more features and better quality in less and less time, it is usually not economically feasible to just abandon the entire investment in existing Delphi code (often many thousands or even millions of lines of code) just to get the product to a new platform.
Just like Microsoft is not dropping everything and rewriting Office in .NET (as many .NET-skeptics often demand as a sign of Microsoft's trust in their own technology), most commercial Delphi developers cannot afford to throw away their investment just to start clean.
This is the situation that triggered the initial idea for Hydra cross-platform plugins: what if there was a way for Delphi developers to preserve their existing investment in solid, working Win32/Win64 code written in Delphi, but at the same time enable them to extend that codebase, using new .NET-based technologies? What if developers could use .NET, Generics, Windows Presentation Foundation, LINQ and all the other benefits of the .NET framework when writing new code for their applications, while keeping the existing parts of their application code basically untouched without porting and retesting?
This is the vision that we had with Hydra, and that we're delivering with its first release. After a few relatively simple (depending, of course, on project size and complexity) steps for adjusting an application's architecture to be open to extensibility, your Delphi project can be seamlessly extended with new code written in either Delphi or .NET.
Among others, the following scenarios are imaginable:
Because Hydra allows seamless mixing and matching of managed and unmanaged code in any imaginable combination of the above, this gives you the flexibility to plan the move to .NET according to your own needs.
Hydra supports versions 7 and 2009 through XE2, as well as .NET 2.0 through 4.0 in Microsoft Visual Studio 2010 and 11 (including C#, Oxygene and Visual Basic .NET).
But let us get a little more technical and see how this works in practice.
The foundation of Hydra's extensibility is based on the concept of plugins . Most basically put, a plugin is simply an object that provides a certain functionality that your main application (the host) needs.
Plugins can be written using any of the supported development tools (Delphi or any supported .NET language), and one or more plugin is usually compiled into a DLL, a so-called plugin module. A host application can load any plugin module, regardless of what platform it was developed with, allowing you to mix Delphi and .NET functionality in the same application.
In theory this can be any kind of functionality, but the most commonly used types are either visual plugins or non-visual plugins, for both of which project templates are provided in the supported IDEs:
A visual plugin is a plugin that provides a user interface to be shown within the host application. When developing a visual plugin, a standard design surface (the VCL form designer for Delphi or the WinForms and WPF/XAML designers for .NET) can be used to design the GUI in the familiar way.
The host can then embed the plugin into its own UI in any arbitrary way. How this will look will largely depend on the application. Plugins can be shown on tab-sheets or in separate windows, or they can integrate seamlessly anywhere within a larger form. For example, the Delphi WPF sample we ship with Hydra presents a standard VCL form, but a portion at the bottom of the form is used to show a .NET Windows Presentation Framework based plugin that displays a graph leveraging the next generation display and animation technologies provided by WPF.
Note: As the plugin can be embedded seamlessly into the UI, it is up to your host's decision whether the end user will be able to tell where the host ends and the plugin begins.
Non-visual plugins, as the name suggests, do not normally provide a user interface of their own (although it is entirely possible for a non-visual plugin to open dialog boxes or windows of its own), but instead will be used to perform other tasks or services needed by the host application (such as performing certain calculations).
While Hydra's base library provides implementations for the most general tasks involved with working with plugins (for example embedding a visual plugin into your form), most non-trivial applications will need some application-specific communication between hosts and plugins. Going back to the Delphi WPF sample illustrated above, the host needs to inform the plugin of changes to its controls, so the graph can adjust accordingly. Plugins might also need to communicate back to the host, for example in response to user actions within the plugins UI.
This communication is handled with the use of custom interfaces that can be implemented on the plugin, the host or both, allowing the two to call each other. Plugins can implement interfaces to expose the functionality they are providing, just as the host can implement interfaces to make itself accessible to any plugin that is active.
To enable this communication across the boundaries of Delphi and .NET, the Hydra IDE integration provides sophisticated support for converting interface declarations between the two development platforms. You can write your custom interface(s) using .NET code and then import the DLL into Delphi to generate a Delphi unit with the appropriate interface declarations or you can write your interface in Delphi and then import the unit to generate code that compiles under .NET for any of the supported .NET languages.
With some restrictions as to the types that can safely be passed between platforms, you are free to define any and all interfaces you need.
You also have full flexibility as to which of your plugins implement what interfaces. For example, you might define a range of interfaces and have every plugin implement a selective subset. Your host can then use the availability of certain interfaces to determine what functionality is or is not provided by a given plugin, or to decide which plugin to use in which context.
Another powerful feature that has been part of Hydra since version 2, and that is seamlessly supported for .NET plugins in Hydra 3 and beyond, are actions and menu merging.
Hydra allows plugins (both visual and non-visual) to define a list of actions (comparable to Delphi's Action Lists), as well as a partial menu and toolbar structure that places these actions. Host applications can choose to provide menu merging, allowing the actions defined in the plugins to automatically show up in the host's menu and toolbar system as the plugin is loaded.
Support is provided for the three most popular menu and toolbar systems in use for Delphi: the standard VCL menus, Toolbar 2000 and the Developer Express ExpressBars component suite. Support for custom or other toolbar systems can be easily added, if necessary.
As mentioned above, Hydra supports seamlessly merging actions in menus and toolbars defined in both managed (.NET) an unmanaged (Delphi) plugins into the Delphi host.
Menu and toolbar merging is illustrated by the Actions sample that ships with Hydra, which has been expanded to include a new C# based plugin module to illustrate the concept.
For host applications, the Module Manager component is provided to perform the task of managing plugin modules. Available on both the Delphi and the .NET side, you can use the module manager component to load the plugin modules you need. This is based on application-specific logic, which can be as simple or as complex as you wish, for example:
Once modules are loaded, you can use the Module Manager to query for available plugins, check what interfaces are implemented or which .NET attributes were attached to a given plugin, as well as create instances of the plugins you need.
Once again, differences between managed and unmanaged plugins are completely abstracted away and taken care of by the underlying library; your host can simply work with all plugins without ever knowing whether the plugin is implemented in Delphi or .NET (although it can of course find that out, if it needs to).
The mixed mode sample that is shipping with Hydra illustrates the current capabilities of mixing hosts and plugins at will; the sample provides host and plugin implementations for just about all supported languages (Delphi, C#, Oxygene) and platforms (VCL, FireMonkey, WinForms, WPF and Silverlight), and any combination of hosts and plugins can be loaded.
We hope this page has given you a good summary of mixed-mode applications with Hydra, what goals we are trying to achieve with the product and how the various technical aspects come together to form a full Hydra application.