So, if it is possible to code an app as a single app, why would one instead adopt a parent/child structure? What's the advantages/disadvantages of each model?
Many times the parent app may be the management /configuration and the child (device) each manage a specific device from the common parent (common cloud device model)
Other times each child app is a worker or individual automation, and you want it to process events/actions independently.
HE can running multiple things in parallel (it has 4 cores if all are turned on), so it can do 4 things at a time. Having multiple apps/devices allows you to take advantage of the parallelism.
For most simple automations, none of this is needed.
1 Like
As a specific example to illustrate the above, consider a couple built-in apps. Motion Lighting allows you to create multiple child apps, and in this case I'm not sure there's much benefit beyond organization (all the child apps will show up under the parent, so it's kind of a grouping of related automations). This isn't strictly necessary, but a lot of users might prefer it.
Consider also something like Rule Machine. Here, the parent app not only provides this organization (something I guess you can't escape even if you wanted to) but also some function. Having neither written it nor seen the code, I can't say everything for sure, but the parent app definitely at least handles the storage of global variables. It also likely allows rules to "talk" to one another: setting Private Boolean, cancelling timed actions, or anything you can call on one rule from another.
A related consideration: you can also have multiple different child apps with the same parent app. The (parent) Groups and Scenes app has both a Group child and a Scenes child app, so just two related child apps grouped together, plus at least a couple different versions of Groups (again mostly transparent to the user, and anything you create now would be the latest version, similar to RM itself also has at least four or so different child apps, all different versions of Rule (again mostly transparent to the user, though you can tell which version each child instance is in list view, and as of a firmware update shortly after the introduction of 4.0, you're also no longer allowed to create new instances of older child versions).
1 Like
Maybe a simpler example.
There are example apps in the Hubitat/Public webpage examples One of them averages multiple temperatures.
So from the average temperatures parent you can:
- create one child to average all the indoor thermometers.
- create a 2nd child app to average all the outdoor temperatures
All accomplished from the same "Parent" code.
The only limit is the amount of temperatures you have to average. Actually I read the software limit is 500 child apps from one parent. I've not yet tried to test this limit 
Thanks for your answers. Does the parent/child structure make sense when the parent and children are interrelated such that situations like the below arise?
childApps.each { child ->
child.method()
}
parentMethod()
In this example, parentMethod() should not execute until after each child has completed its child.method() process. Is there a way to do this in Hubitat's implementation of groovy? And does this suggest that perhaps the parent/child structure isn't a good idea?
I follow this pattern in some apps. I think it's valid, but I probably do it more to facilitate interactions between peers of the same parent.
An example is an audio system app that I created. The app handler for button events attempts to enable a predetermined group setting. Before enabling a new one, though, I want to make sure the other groups are all disabled.
So, a given child asks the parent to call the ungroup method on all of its children. Then this child enables its group.
If you need peers to communicate, they can do this directly with shared memory (@Field static ....)
Assuming the peers are the same code module (ie same child)
I don't really need peers to communicate. I just need peers to update their state, and for the parent to be able to access that state only after its actually been updated. The sharing of state, so to speak, makes it seem like I should combine everything into one app. But the organization would be much cleaner if separated.
I would suggest separate as you are thinking.
Does the parent always need the state or sometimes?
ie the parent could read it or the children could push it - it depends if one way or the other has less calls.
I have done both in applications, parent pulls it, and other time children push it. I have cases the parent needs it but not every run, so I have the parent gather it when it needs it.
