Start Your Other Engine: Debugging in ThingStudio, and a New Widget

in features

debugging iot apps

Powerful debugging has always been part of ThingStudio. However, with great power comes great responsibility, and we realized it was time for a new way of doing things.

With last month’s launch of 0.3.0, you may have noticed that in the IDE your publish messages no longer showed in the debug overlay or on the debug route, while your subscribe messages still did. Curious…

More recently, you may have also noticed that there is now no debug overlay at all in the IDE. Debugging functionality in ThingStudio has a new home, one where it will better serve you: the viewer.

Multiple JavaScript engines

Prior to 0.3.0 and 0.3.1 (oh yeah, 0.3.1 is out, btw), both the IDE and the viewer contained live streams of all your data, allowing you to do fun stuff like preview your templates directly in the IDE and, as mentioned previously, view live data in the debug overlay. This created a problem, however, which a fair number of people ran in to: you could break your IDE. Not all of ThingStudio mind you, but your own development experience could come to a halt with one bad line of code.

The reason for this is that everything – your data, your custom JS, your templates, your feed processors, etc., were all running on the same JavaScript engine as the ThingStudio IDE. These features were nice to have, and we really enjoyed using them, but since they created the ability for users to break their experience in ThingStudio, they had to go.

Going forward, your code does not execute in the IDE and with an update in the next week or so, your data will also not be passing through the IDE (we’re currently testing this).

Update 11/18: Your IDE is now data-free. The only place your data exists in ThingStudio is in the viewer. How about that?

Clearly you still need to be able to debug, so what now?

Debugger in the viewer

There is a new feature in the viewer of your app called “Debug” (clever name). Access it by tapping the link in the footer nav of your app (unless you’ve spun your own nav, in which case message us and we’ll help you get it setup). The debugger will pop up and you’ll see a tabbed list of subscribe data, publish data and, at the moment, a placeholder for Runtime errors.

This debugger is not a route, but rather a state of the application. This creates a really fluid debugging experience, as you could, for example, access the template you want to debug, publish the messages you want to test by interacting with it, toggle the debugger and at a glance confirm that the application is indeed sending the data you expect. Give it a try, the experience is really nice and very informative.

The Runtime errors tab is still being developed, and feel free to share with us any requirements you’d like to see fulfilled by it.

Now, on to widgets.

What’s up with widgets?

Good news! We know it’s been a spell since we last released any new widgets due to our focus on 0.3.0 and related updates. The wait for new widgets is officially over with the release of the “state” slider button. This widget bears conceptual kinship with the existing state button.

We believe these “stateful” widgets are the right answer to visualizing and interacting with many aspects of connected / IoT apps. The reason is that your interface does not immediately know if when you sent the “landing gear down” message if the landing gear is, in fact, down. So, your UI should not immediately reflect this when it may or may not be true.

Here’s a quick look at the new widget in action. The section below describes exactly what’s happening here. If the widget below is already showing “on” or “off”, reload the page to catch the “waiting” state where the widget is requesting information from a “real” device on the other end. We’ve rigged a little bot for this demo to simulate a real device acknowledging commands a couple of seconds after you click the slider.

Note: you may see this bouncing back and forth if other people are reading the post at the same time as you. This is not a bug, it’s another IoT UI design consideration we’ve accounted for.

Share this app: App link

The behaviors of a stateful widget

  • When a stateful widget is rendered, the widget will request the current status from the related connected device by sending a “reqStatus” message. Until then, the widget will present visual language indicating an unknown state
  • When the device responds with its current state, the widget will update to reflect reality
  • When the widget sends a command, it will again assume the visual language of an unknown state
  • When the device responds either confirming or denying the request, the widget will again update to reflect reality

What widgets do you want to see?

We should have another widget out in the next two weeks or so, and this widget is already decided upon. What other widgets would you like to see us create in the future? Let us know in the comments.

Paul likes to work on growth, product & design. Tweets occasionally @paulisloud.

Leave a Reply

Your email address will not be published. Required fields are marked *