AllJoynCodeGen Tool
[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]
We've created a code generation tool, AllJoynCodeGen, that generates a complete Windows Runtime component using an XML description of one or more AllJoyn interfaces derived from a specification or device.
The Windows Runtime component generated by this tool can be consumed in any supported language (JS, C#, C++/CX, etc.) using APIs that are available in the Universal Windows SDK. This means that the same component can be used on any platform that has the AllJoyn OneCore package (router service and C API dll.) A developer can then use the component to create a producer and/or a consumer of that interface.
Note For more details about the AllJoyn C APIs, you can download the AllJoyn Core SDK and documentation at The AllSeen Alliance.
The basic flow is as follows:
- An XML file authored in the AllJoyn XML (currently DBus introspection format) that describes the service is fed into the codegen tool.
- The AllJoynCodeGen tool generates code that results in a Windows Runtime component. This generated code relies on MSAJAPI.lib and Windows.Devices.AllJoyn from the Windows 10 SDK.
- The developer builds an application that consumes this component.
- At runtime, the developer's application will load the Windows Runtime component generated by the tool (e.g.: foo.dll,) as well as the in-box DLLs MSAJAPI.dll and Windows.Devices.AllJoyn.dll.
The following workflow diagram illustrates this process:
The AllJoynCodeGen tool currently exists as a command line tool shipped with the Windows 10 SDK. To run the tool pass a valid XML file using the following string:
AllJoynCodeGen –i Foo.xml –o c:\users\developer1\documents\Foo\
The generated classes wrap functionality exposed by the Core C API. Because the generated code is an abstraction, this is not a 1-to-1 mapping. This table below shows which Core C++ APIs are wrapped by each generated code class. The following placeholders are used for generated names in the table:
<Foo> is the name of the interface defined in the xml file
<Signal> is the name of a signal, taken from the xml file
<Method> is the name of a method, taken from the xml file
<Property> is the name of a property, taken from the xml file
Windows Runtime Class | Description | Core C++ API |
---|---|---|
<Foo> Watcher |
Searches for producers that advertise the target service |
|
<Foo>Producer |
Advertises a service and exposes handlers for AllJoyn events. |
|
<Foo>JoinSessionResult |
Reports the success or failure of joining a session, and exposes a <Foo>Consumer instance for the session if the join was successful. |
|
<Foo>Consumer |
Interacts with a service after it has been discovered. |
|
<Foo><Method>CalledEventArgs |
Arguments passed to methods in EventAdapters.<Foo>ServiceEventAdapter. |
|
<Foo>Signals |
Exposes methods and handlers to send and receive signals. Used by both producers and consumers. |
|
<Foo><Signal>ReceivedEventArgs |
Arguments passed to a signal in <Foo>Signals. |
|
<Foo><Method>Result |
Used by method implementations in I<Foo>Service to report the success or failure of the call, as well as any return values. |
|
The generated code needs to be contained in a component that shares the same interface name as the XML. For example, if the XML for a toaster is defined as com.microsoft.sample.toaster, we would create a runtime component com.microsoft.sample.
Alternatively, you can name the component whatever you want (e.g. fooCodeGenComponent), but you must manually update the root namespace under the Project properties to be the same as the interface name. (NOTE: you can find the root namespace in the pch.h file that is generated from the AllJoynCodeGen tool).