QwikAppChild

[jgab 2,202]

This is  a easy and powerful way of creating QuickAppChildren.
Repo: 

Please login or register to see this link.

Usage:

Alt1. Create children from initialization table

Please login or register to see this code.

Will load existing children defined in table.
Will create missing children defined in table but not loaded.
Will remove existing children not defined in table.

Alt2. Load existing children and create new children "manually"

Please login or register to see this code.

So, at startup, you either decide what children you are going to have and create the initialization table, and then call self:initChildren(children).
The table can have static children (children that should always be created), but one could also add children by scanning for external devices or reading user preferences what children should be created.
At the end we have a table of all children there should be, and we let  self:initChildren(children) do all the work.
The way to change the number of children is to restart the  QA so the initialization table will be recalculated and self:initChildren(children)  is called again.
This also means that if a user delete a child in the web UI, the child will be recreated when the QA starts up if it's in your initialization table.

Alternatively, at startup you load already created children with self:loadExistingChildren() and then dynamically creates children when ex. a user requests it by some action, ex. by clicking a button. If the user deletes a child in the web UI it will not be automatically re-created by self:loadExistingChildren() - because it doesn't exist anymore....

The uid is an unique identifier defining this child. Two children with the same uid can't be created.
self:createChild(uid,...) with the uid of an existing child, will delete the existing child and create a new with the same uid (but it will get a new QA deviceId).
After QA startup, self.childDevices is a table mapping QA deviceIds to Lua child objects.
self.children is a table mapping uids to child objects.

.store is an optional parameter that will store the key/values as internalStorage keys in the child QA. It can be a good place to store child specific parameters if you don't want to pollute the quickAppVariables of the child.

.room is an optional integer being the roomID the child QA should be placed in.

UI is an optional UI definition table, creating custom UI elements for the child QA.
Ex.

Please login or register to see this code.

Each entry is one line in the UI.
To place several items on the same line group them in a list:
 

Please login or register to see this code.

This makes it possible to place a label before a button on the same line in the UI. Something that is not possible with the Web UI designer.

Buttons and switches also supports onLongPressed etc.
 

Please login or register to see this code.

select also takes options={...} and value=<val> arguments. multi takes options={...} and values={...}.

slider takes min,max, and step arguments.

 

When creating children for external devices, it can be wise to chose the uid to be the uid of the external device. Ex. Hue devices have uids, and most systems have uids.

When creating a fixed set of children for ex. two temperature sensors, we can ex. give them the uid 'temp1' and 'temp2'. Then when the children are loaded we can refer to them as (ex. calling an update method on them:

Please login or register to see this code.

Classes for children inhereits from QwikAppChild:

Please login or register to see this code.

Children will have two QwikAppChild specific instance variables defined

Please login or register to see this code.

If you have stored something in the internalStorage, you can pick it up in the constructor.

Please login or register to see this code.

 

Edited January 21 by jgab

[jgab 2,202]

Example:
 

Please login or register to see this code.

 

This QA creates 2 children, ChildA and ChildB.

Please login or register to see this image.

/monthly_2025_01/image.png.be5bef5af7fa73c9cdc7d77235412d0e.png" />

 

The main QA updates the children every 5s with some random values.

The strategy is that the data is sent to both children and they pick out their own data (the A key response. the B key of the data table).
 

The children also communicate with each other through
self.parent.children.childA

resp.

self.parent.children.childB

This way they can update properties an UI elements in the other children.

When we drag the slider in childB it will update the value property of childA.