SIMPL# Pro – Lesson 6 – Sig Groups
This content can be purchased as part of the following courses:
SIMPL# Pro – Fundamentals CourseCourse DetailsAdd to Cart |
Leave a CommentComments
2022-04-25 13:30:59Hello Troy,
You can do things like this, correct. One of the reasons why I didn't demonstrate too many abstractions is because I didn't want to clutter the lesson topic with other semantics. It is a good solution for small and medium sized programs, as it's likely one of the easiest to implement as well! If you're on a team with other developers, it could very well be the easiest for the team to maintain too depending on the programmers.
One thing I would be careful with, is to keep scalability in mind. Having to create a method for each button is not a very scalable approach for developing larger systems, and that's where design patterns might be a good consideration. If you duplicate the logic out to multiple buttons, you're also introducing the overhead of additional checks to see that the args signal is a bool value (i.e. digital is pressed).
A better approach in my opinion is to avoid the large conditional if and/or switch statements as much as possible, especially when dealing with larger codebases for improved maintainability. Having large if and/or switch statements violates some of the SOLID design principles because you have to go back and touch that code when you want to add/remove things from it. The CTI courses on the Crestron website unfortunately don't show any alternatives either, which was one gripe I had with a few of those videos. The main takeaway here for now, is to learn how the signal object behaves with user actions and feedback. Some of the other lessons will dive into some basic concepts with design patterns, showing how you can better restructure your applications if you're still using VTPro UI's. I plan on extending this to show how you can utilize WebSockets in a much cleaner way too.
As a mention in some of the future lessons too, we explain how named constants in general (i.e. enums, fields, etc) have the benefit of a single source of truth. Changing the number on a global scale is made easier, in addition to the benefit of readability as Troy has pointed out. If you're developing a framework to manage your UI and domain logic however, the main focus will be on the readability of the internal mechanics over the readability of which signals are being pressed via the code, since the data will most likely be external at that point (i.e. configuration file, database, etc).
If there is enough interest I may create an advanced series that focuses more on the overall implementation of programs, rather than just the fundamentals. I know that a lot of people struggle with understanding how to use the SDK, however. My hope is that this course can focus on solving some of the SDK usability issues, and build intuition for solving some confusion around its inner-workings.
Troy - It sounds like you're well on your way to thinking about not only how to write the code, but also how to think about writing better code. That is always good to see.
Best regards,
Troy- 2022-04-25 13:04:00You can also refactor the IF statements to make the code more self-documenting, making it easier to understand & maintain. A simple example is shown below. Just a thought.
from ControlSystem.cs:
#region Event Handlers
void XPanel_SigChangeEvent(BasicTriList currentDevice, SigEventArgs args)
{
switch (args.Sig.Type)
{
case eSigType.Bool:
{
if (args.DeserializeButtonPressed())
{
// handle the button press here
...
from SigEventArgsExtensions.cs:
public static class SigEventArgsExtensions
{
public static bool DeserializeButtonPressed(this SigEventArgs args)
{
return args.Sig.BoolValue && args.Sig.Number == (uint)XPanelControls.DeserializeButton;
}
public static bool HideButtonPressed(this SigEventArgs args)
{
return args.Sig.BoolValue && args.Sig.Number == (uint)XPanelControls.HideButton;
}
public static bool ShowButtonPressed(this SigEventArgs args)
{
return args.Sig.BoolValue && args.Sig.Number == (uint)XPanelControls.ShowButton;
}
}
the enum:
enum XPanelControls
{
DeserializeButton = 100,
HideButton = 101,
ShowButton = 102,
FormattedText = 103
}
- 2022-03-09 13:19:47The course material takes a progressive approach to these topics. Once you learn about sigs, groups, devices, ports, and the other concepts, we dive into a basic implementation of patterns like MVP. There are many other options, but as you go through the course you'll have a better idea on how to handle these things. If we gave the solution to avoiding large conditional branches of logic right away, it may have been confusing to some people. Hope this helps!
- 2022-03-09 08:40:09There is a note in this video that we shouldn't use large if statements or switch statements to build out our signal logic. Can you expand on that and maybe offer some other techniques or patterns you would suggest?
Thanks!
- 2022-04-25 13:30:59Hello Troy, You can do things like this, correct. One of the reasons why I didn't demonstrate too many abstractions is because I didn't want to clutter the lesson topic with other semantics. It is a good solution for small and medium sized programs, as it's likely one of the easiest to implement as well! If you're on a team with other developers, it could very well be the easiest for the team to maintain too depending on the programmers. One thing I would be careful with, is to keep scalability in mind. Having to create a method for each button is not a very scalable approach for developing larger systems, and that's where design patterns might be a good consideration. If you duplicate the logic out to multiple buttons, you're also introducing the overhead of additional checks to see that the args signal is a bool value (i.e. digital is pressed). A better approach in my opinion is to avoid the large conditional if and/or switch statements as much as possible, especially when dealing with larger codebases for improved maintainability. Having large if and/or switch statements violates some of the SOLID design principles because you have to go back and touch that code when you want to add/remove things from it. The CTI courses on the Crestron website unfortunately don't show any alternatives either, which was one gripe I had with a few of those videos. The main takeaway here for now, is to learn how the signal object behaves with user actions and feedback. Some of the other lessons will dive into some basic concepts with design patterns, showing how you can better restructure your applications if you're still using VTPro UI's. I plan on extending this to show how you can utilize WebSockets in a much cleaner way too. As a mention in some of the future lessons too, we explain how named constants in general (i.e. enums, fields, etc) have the benefit of a single source of truth. Changing the number on a global scale is made easier, in addition to the benefit of readability as Troy has pointed out. If you're developing a framework to manage your UI and domain logic however, the main focus will be on the readability of the internal mechanics over the readability of which signals are being pressed via the code, since the data will most likely be external at that point (i.e. configuration file, database, etc). If there is enough interest I may create an advanced series that focuses more on the overall implementation of programs, rather than just the fundamentals. I know that a lot of people struggle with understanding how to use the SDK, however. My hope is that this course can focus on solving some of the SDK usability issues, and build intuition for solving some confusion around its inner-workings. Troy - It sounds like you're well on your way to thinking about not only how to write the code, but also how to think about writing better code. That is always good to see. Best regards, Troy
- 2022-04-25 13:04:00You can also refactor the IF statements to make the code more self-documenting, making it easier to understand & maintain. A simple example is shown below. Just a thought. from ControlSystem.cs: #region Event Handlers void XPanel_SigChangeEvent(BasicTriList currentDevice, SigEventArgs args) { switch (args.Sig.Type) { case eSigType.Bool: { if (args.DeserializeButtonPressed()) { // handle the button press here ... from SigEventArgsExtensions.cs: public static class SigEventArgsExtensions { public static bool DeserializeButtonPressed(this SigEventArgs args) { return args.Sig.BoolValue && args.Sig.Number == (uint)XPanelControls.DeserializeButton; } public static bool HideButtonPressed(this SigEventArgs args) { return args.Sig.BoolValue && args.Sig.Number == (uint)XPanelControls.HideButton; } public static bool ShowButtonPressed(this SigEventArgs args) { return args.Sig.BoolValue && args.Sig.Number == (uint)XPanelControls.ShowButton; } } the enum: enum XPanelControls { DeserializeButton = 100, HideButton = 101, ShowButton = 102, FormattedText = 103 }
- 2022-03-09 13:19:47The course material takes a progressive approach to these topics. Once you learn about sigs, groups, devices, ports, and the other concepts, we dive into a basic implementation of patterns like MVP. There are many other options, but as you go through the course you'll have a better idea on how to handle these things. If we gave the solution to avoiding large conditional branches of logic right away, it may have been confusing to some people. Hope this helps!
- 2022-03-09 08:40:09There is a note in this video that we shouldn't use large if statements or switch statements to build out our signal logic. Can you expand on that and maybe offer some other techniques or patterns you would suggest? Thanks!