Ultimately, the structure of your module project (or projects, as most modules will consist of multiple sub-projects) is up to you. However, there are a few common structures that are used in most module scenarios. Primarily, breaking the projects up by scope, with another "common" project, is useful. Each project usually represents a JAR in the build process, and the common jar can be marked as applying to all scopes. Of course, this can also be accomplished through package structure and handled in the build process. The important point is that the resulting JAR files should be carefully tailored to their scopes, to reduce the amount of code unnecessarily loaded into scopes which don't use it.
The chapter on localization will discuss this topic more in depth, but in short, all string data that might be presented to the user should be held in external "resource bundle" files. There are several schemes for managing these files, but the easiest is simply to have a single file for each scope in the root package of your module and to load it into the BundleUtil in the hook. The section on Localization has more information about how this system works.
Design Best Practice
Strings that represent identifiers, names, etc., such as the "module id", should be defined in a single place in the common project, instead of repeatedly in code. For example:
Now, all parts of your module can access the static values, and you don't have to worry about mistyping an identifier.
These byte utility classes are provided by the driver API and are very useful when writing protocol based drivers.
Useful functions for serializing most basic data types to byte arrays.
Similar to ByteUtilies, but for BCD encoding, with both Little and Big Endian support.
Provides convenience functions for working with the EDT, and a useful coalescingInvokeLater () function that can be used to group multiple calls into a single event.
Many functions for displaying errors, but also other dialogs such as info and warning messages, and prompts.
Used for retrieving icons provided with Ignition.
3rd Party Libraries
Ignition also includes a number of 3rd party libraries that are exposed through our API. To view a full list of available libraries you can view the dependency tree provided by Maven, available by calling
mvn dependency:tree from the commandline where you module (or one of our example module's)
pom.xml is located.