-
Are SmartApps always distributed in source (groovy) form?
-
Anyone know details on the smartapp execution layer? Like, what is the OS, how is the groovy code compiled, what are runtime libraries etc.
From what I understand, the app is distributed in source form because home owners will simply copy the source into their own apps or simply directly copy published apps into “My Apps” and have it run on their smartthings deployment.
the act of installing simply copies another app (in source form) into the user’s smartthings account.
Am I understanding this correctly?
That is correct. Whatever is under the covers re Groovy execution is pretty much irrelevant to how you use the platform.
Thanks. I was interested in groovy execution details because I want to understand more about how the apps are given permission to perform operations and how they are isolated from each other. Presumably, since groovy compiles to JVM bytecode, I’d think that there is a separate JVM for each user’s set of smartapps and some other in-VM framework that isolates the “state” and regulates the capabilities an app is permitted to access. Probably the JVM is futher modified in same way to disallow things like threading and loading JARs etc, but all this is just speculation of how I would build such a system.
1 Like
Your description sounds like pretty much the way I understand it to work. The state and settings of each instance of a SmartApp are isolated and unique to that instance. There is no direct way for SmartApps to communicate with each other, as there is only a single “global” variable: location.mode. There are indirect ways to do this using device intermediaries, usually a virtual device. That use is rare, I believe.
1 Like
I’m not sure what “source form” means in your question here.
No – the official SmartApps installed via the SmartThings mobile app are not necessarily ever distributed as “source code”. SmartThings has give us a “template library” of many example SmartApps, but this is unrelated to the runtime environment. The IDE is currently available to all SmartThings account holders, so if they have some source code (and some very limited libraries can be imported), they can paste and “self publish” to their account… but the published code is Java Bytecode that runs under in a cloud of Java VM’s … etc.
Here is some info from the Documentation that may phrase it much better than I, but do let me know what you are aiming at regarding the term “source form”:
Not as rare as you think, Bruce.
And, SmartApps can expose REST-API’s as well as call REST-API’s, therefore, two SmartApps could interact via their … REST-API’s.
But everything else you say is consistent with my understand … All the code for SmartApps and SmartDevice Handlers is “sandboxed” in several ways, not the least of which is the inability to define or instantiate Objects, and no “shared memory” access … just indirect access through wrappers of the Device Instance Objects (and a few other structures like “location.mode”, Event send and subscribe, and restricted set of methods (hub action, http, …).
By source form I mean the SmartApp is installed into a smartthings user account in source form where it is then compiled and deployed to whatever infrastructure SmartThings has on the backend. That is, when a user wants to install a new app, he/she can inspect the code of that app before installing it using the web IDE. Although the apps appear as templates, I can simply take that app, publish it to my apps, and hey presto, I have an app installed for me to use.
That means groovy source code.
Right… but that only applies to the particular set of SmartApps (and Device Handlers) that have published open source code. As time goes on, the proportion of open source SmartApps vs. closed source will change. Maybe the majority will be closed source. Maybe.
That’s why SmartThings has a submission, review, and approval process for “published” SmartApps (i.e., those that you install directly from the “marketplace” section in the mobile App). Users will have to trust many App choices without having seen the source code first.
The lack of an integrated simple “rules engine” continues to be a bit frustrating, because “rules” would likely be depicted as a flow chart or something (see IFTTT for really simple analogy), and these would never be closed-source. Users could grab a rule and not only set the various devices and parameters, but probably load it into the “rules editor” and make super easy changes (e.g., add another condition or action, etc.).