Updated Construction and Activation phases concepts (markdown)

Neil Dorin
2020-02-11 21:58:23 -07:00
parent 1fc951ad53
commit ce0359448e

@@ -2,9 +2,9 @@
The Essentials system architecture is a loose collection of "things" - generally real or logical Devices - that all need to relate to each other. In the interest of keeping Essentials extensible and flexible, we use an non-ordered collection of objects that should only have references to each other in the least-binding way possible. Meaning: Devices should be designed to be able to function without related objects present, and when they are present they should only retain loose reference to those other objects for memory management and later deconstruction as Essentials grows into a real-time configurable environment.
In order to facilitate this loose coupling, Essentials devices go through five phases during the startup process: Construction and DeviceManager addition; pre-activation; activation; post-activation. We will describe what is optimal behavior for each of the steps below:
In order to facilitate this loose coupling, Essentials devices go through five phases during the startup process: Construction; addition to `DeviceManager`; pre-activation; activation; post-activation. We will describe what is optimal behavior for each of the steps below:
### 1. Construction and addition to the `DeviceManager`
### 1. Construction and addition to the DeviceManager (`PepperDash.Essentials.Core.DeviceManager`)
In general, a device's constructor should only be used to get the "framework" of the device in place. All devices are constructed in this stage. Rooms and fusion bridges included. Simple devices like IR driver devices, and devices with no controls can be completely spun up in this phase. All devices are added to the `DeviceManager` after they are constructed, but may not be fully functional.