Basic applet development
Until now, the UD App has been talked about as a browser application, but it actually provides a platform for doing whatever the user community chooses to do with this tool. The number and type of future innovations seems boundless. At the moment, the horizon is wide open for devising various styles and creating applets that add a new look and feel. And also, the possibilities for new kinds of interactions between the user and the vault data are vast. At some future point, there will need to be an automated way to load or pipe data to the vault, something that lies, to some extent, within the scope of what applets do.
At the time of writing this, no developer community has come together around the goal of building applets for the UD App. It could be, since you are reading this, that you are at the very leading edge of it. There is not a news letter or email chain. There's not a dedicated website or Git repository. This article is just the start of what I hope grows into something that people care about and that they will use to make life better for themselves and perhaps eventually, their clients.
The developer will need to create the following items in order to produce an applet:
- An optional CSS file.
- A modified addons.js file, one that contains an entry, in other words a stanza, for their application.
Adding code to 'addons.js'
The required fields for a minimal applet are 'provider', 'contact_info', 'selection_string', and 'draw_method'. The following are explanations of all of the platform-significant fields:
'provider' - this is a unique string that you use to differentiate your stanza, and can be used as a key to get stanza information when the applet is running.
'contact_info' - this is an email that can be used to report issues with your applet code.
'selection_string' - this string value will be used in the dropdown box during vault construction or authoring. This string is stored in the vault with the node that is configured to use your applet code.
Recommendations for developers
The following are some recommended practices, some things to do and not do when developing your own applet.
Use the TrackingObject
Each of the sample applets are using the object provided in the app interface as app['tracker'] in order to generate ids for any objects that will be part of the tab cycle. The sample applets (listed below) show how this tracker is used. The object has a next() and a down() method that inform the tracker of the current vault location. The tracker can then provide appropriate ids that reflect the relative location from the current scope item.
Don't pollute the global space
By encapsulating your applet methods in a container object, there will be fewer naming collisions. The global methods that are declared in the addons.js file should also be unique, so that they don't collide with names of other applets that describe a similar function. A good practice for these globally visible methods is to include the applet name in the method itself. For all other methods, a good practice is to wrap them in an object that can be easily tied to your applet.
Use vault storage only if necessary
If you use a scope item (taken from app['scopeItem']) and then add fields to that scopeItem, it will inevitably be saved by users, and become a permanent part of their vaults. This increases vault size and ultimately performance, so follow a policy of only saving to the vault when it is appropriate. It should go without saying, adding child nodes or labels will result in those items becoming a permanent part of the vault if the users saves, and this is probably the normal case.
You will see that other applets will use the method of creating a temporary vault item and installing it as a guest. That is done with the following two lines:var myItem = SharedGlobal.app['createNewVaultItem']();
This prevents the vault from retaining myItem, but also allows the UD App to temporarily incorporate it into the working structure that users experience and interact with. The need for this approach is limited to certain cases where info is stored somewhere other than the vault but is loaded when the user visited an applet instance.
A list of sample applets
- list (Default-format.js)
- wrapping comma-separated list (Default-format.js)
- key-value pairs (Default-format.js)
- two-level view (Default-format.js)
- entire branch (SampleCustomizer.js)
- table (SampleCustomizer.js)
- deep doc (Snippetizer.js)
- file cabinet (FileCabinet.js)
Our company was founded in July 2017 by Bradley Pliam.
The headquarters is currently in Austin, Texas.
Ideas that have been in gestation since the early 2000s have now finally been given 'wings'.
The mission of the company is to deliver happiness in the form of value and great user experience via high quality software, being honest about what is being delivered, and up-front about any current limitations. The world of software has some great things, along with some insidiously bad aspects. We intend to be a positive influence.
Meet our current staff...