Overall refactoring ideas

[nicolabortignon]

Writing down some thoughts on how to improve the overall architecture and maintainability of the code base.
We can use this threads to reference the more broader refactoring principles, and queue up ideas.

In general, if you, who are reading, are someone that cares about architecture designs, design patterns, and clean code, this could be a good task to sink your teeth in (I'm looking at you, 2nd year degree in computer science, fresh of your C++ object oriented programming course 👀 )

• Device assets that are critical for the knob operations should be made static, and accessible via a singleton pattern. (sensors, motor, screen, etc).

• Interfacing with Device assets should be done through high level interfaces (getter and setter when accessing properties), or more comprehensible semantic for the final use case (ie.: hide all the filtering of sensors to the final user, normalize sensors)

• The system has a clear semantic.

  • There is a SmartKnobDevKit main class where all the initialisation of the board are done. All the singleton mentioned before are initialized here.
  • The SmartKnobDevKit class is responsible to initialize the MainContainer, the container of all the user interface and interaction code. A MainContainer has a list of Apps (more to this later). And a NavigationMenu (more to this later as well)
  • Apps are the semantic entity of a finite user use case. A light switch experience is an App. The Onboarding flow is an app. Each App should be in it's own folder.
  • Apps should implement the AppInterface. The way an App interacts with the system (SmartKnobDevKit) that it's operating on, is only through methods exposed by the AppInterface. Ie.: don't try to access static methods from methods that are not part of AppInterface.
  • C++ doesn't have interfaces in a Java like term. AppInterface is therefore implemented as a virtual class. This class should expose all the methods that an App needs to implement to operate. For instance the App lifecycle is dicted here (ie.: AppMount, Render, AppUnmount). In the constructor of the App, we inject a reference to the static method in SmartKnobDevKit, and are visibile within all the methods described in the Interface.
  • An App, can have multiple Views. A View is a single rendering screen. Views is an object in itself with an interface to implement. If there is more than one View, the App object should implement a navigation menu.
  • (this one is risky and needs more thinking). App and View extend (aside their interfaces) the same object. Something like 'InteractiveObject'. The reason why we want to do this, is because we want to have Apps being able to have nested Apps. In this case moving from a view to a view, from an app to an app, or from a view to an app, should be treated in the same way. This implies that the navigation menu in an app, should support InteractiveObject.
  • A byproduct of the design of having apps holding apps, is that the interaction are cloaked by the current entity that is displayed. What it means is that it's the responsability of the developer to implement an interaction that allows the user to navigate out of the current InteractiveObject, back to the parent one.

• InteractionManager. We should adopt a eventListener approach to event handling and dispatching. Javascript has a good model that we can borrow from and it's well understood. Since we have nested InteractiveObject, we want the event to bubble to the parent (and to the granparent if needed) for handling specific interaction. The InteractionManager should be injected through the InteractiveObject.
  This mean that InteractiveObject should have a parent reference.

I'm sure there are a lot of other considerations, and I'd love to use this first post to expand on those, and keep track of when the above are implemented.