Published on February 3, 2023.

Back in December, I wrote about a project that I was working on called Petal. In this post, I want to give an update on that project, discuss what I learned, and how that project lead me to what I think is a better approach.

Petal Player

Petal is a custom Tulip Player. My goal with the project was to extend Tulip's core functionality in ways that aren't possible using plugins.

• Inject dynamically generated content into a Tulip app step.
• Receive and act on events that were generated by a Tulip app. For example, to do something when a button was clicked, such as process a form.
• Make API calls without using Tulip connectors.
• Access local resources, including the workstation itself and devices connected to it, such as printers, Phidgets, etc.
• Access resources on the local network, especially network printers, without needing a gateway.

While I consider the project a success on a technical level, I wasn't thrilled with the implementation. For example, to inject dynamic content into a step, you have to add text controls to it, which essentially served as tokens. For example, a Text field with a value of "{{petalTemperature}}" indicates to Petal that it needs to get the current temperature (which it did using a Phidget) and update the token accordingly.

Here's a screenshot of the Tulip App Editor, showing a step with a couple of tokens.

Click the image to view a larger version.

And here's what that step looks like when it's viewed in Petal.

Click the image to view a larger version.

The use of tokens isn't too bad, I suppose. However, in order for Petal to detect that there are tokens that need to be processed, it has to constantly scan the contents of the HTML viewer that displays the Tulip app. Again, that's not terrible, but it's also less than ideal.

Another awkward implementation detail has to do with how Petal gets information about the Tulip app, including the app name, the app version, the station name, the user that's logged in, and the step that the user is on. To pass that info to Petal, I created an app variable, and positioned it on the app's Base Layout, outside of the viewable area. I then added an "On Step Enter" trigger to the Base Layout, which set that variable in such a way that (1) Petal detected the step change event and (2) pulled and parsed the information.

Here's what that trigger looks like in the Tulip App Editor.

Click the image to view a larger version.

But I think my biggest disappointment with Petal's implementation is that it feels very "un-Tulip-like." Tulip is an elegant, easy-to-use, no-code platform. And while none of what I described above requires writing code (other than in the Petal app itself), Petal's implementation seems to me to be anything but "elegant" and "easy-to-use."

As the project progressed, I became concerned with the custom player approach in general. Specifically, I worry that as Tulip continues to evolve the platform and release new versions of the Tulip Player, at some point Petal might not support all of the functionality that the official player supports. At that point, what would a Tulip customer, who was using Petal, do?

A Different Approach

When I realized that I wasn't happy with Petal, I started to think that there might be a better way to achieve my primary goal - which, again, was to extend Tulip in ways that we can't do with plugins.

In order to achieve most of those secondary, specific goals, I needed an application running on the workstation, or running on the local network, that Tulip could reach out to. I realized that I could do that with a Web app, and with Tulip plugins making calls to the app.

I had developed Petal using Xojo, which not only supports developing desktop apps, but Web apps as well (and mobile and console apps, too). So naturally, I used Xojo to develop the Web app. As a result, I was able to reuse a lot of the code that I had originally written for the desktop app. This made developing the Web app quick and easy. Best of all, Xojo Web apps are stand alone applications, so there's no need to install a Web server. That makes deployment incredibly easy as well.

Here's a screen shot of the Xojo Web project, showing the code that gets the current temperature via a Phidget.

Click the image to view a larger version.

The Web app is essentially a Web API. You can make a call to it to get things like the current temperature, information about the device that the Web app is running on, access local resources, including printer, Phidgets, IoT devices - anything, really.

To send API calls from Tulip, I developed a few custom plugins. For example, one plugin makes a call to the Web app to get the current temperature. Here's what that plugin looks like in the Tulip Custom Widget Editor.

Click the image to view a larger version.

I then built a very basic Tulip app to test everything. Here's a short animation that shows the app running in Tulip Player.

Click the image to view a larger version.

There isn't much to it, because it's really just a proof of concept. But it works, and this new approach feels much more "Tulip-like."

What I really like about this approach is that, in theory, you can extend Tulip so that it does whatever you need it to do. Need to access a local database? No problem. Need to print to a local printer. No problem. Want to connect to local sensors and IoT devices. It can do that, too. It's simply a matter of adding the functionality to the Web app, and building a simple Tulip plugin.

Wrapping Up

I find it interesting that projects like Petal often result in an entirely different outcome than what I originally expected. I really thought that I was "on to something" with the custom Tulip Player concept. Regardless, I'm pleased with the Web app / custom widget approach that I ultimately settled on, and I'm excited about using it to extend Tulip.

If you're interested in learning about other Tulip-related work that I've done with Xojo, check out these posts:
• Tulip and Xojo: No-Code Meets Low-Code
• Tulip and Xojo: Job Status Web App
• Tulip and Xojo: Job Status Android App
• Xojo: Develop A Web App to Resolve Mixed Content Issues With Zebra Printers