Leaderboard

Having dealt a lot with hardware systems. There were a few conclusions I cam to quite a few years ago.That is that with hardware settings, you should always rely on the device to tell you what you can and can't do. If you start restricting user input values before sending to the device, you very quickly end up trying to replicate the device logic which can get very complex. With this in mind, it becomes just a case of setting max/min values to the controls. Additionally, most modern devices give readable error responses, so usually you only need to bubble them back to the UI. Similarly. When it comes to device state. You should not try and maintain it in the software, rather, interrogate any state information as and when you need it. Maintaining device state in the software will vastly over complicate your code and lead to hard-to-debug disparities between the actual device state and that of your software. This situation is totally avoidable and means that very simple recovery procedures can be facilitated without complex code and the code can reflect state without logic. If you bear in mind these "rules-of-thumb". You devices will do all the hard-work and greatly simplify your code as well as being far more robust.

<blockquote class='ipsBlockquote'data-author="Mike Le" data-cid="101054" data-time="1359502271"><p> This makes sense, but does that mean EVERY time the UI queries a setting, it has to go through the Controller to query the Hardware Actor? </p></blockquote> The preferred way to think about your actors is that they post information, rather than requesting it. That turns your issue around slightly:<br /> - The hardware actor stores it's own settings. If they change then it notifies someone who cares... probably the controller, which in turn notifies the UI.<br /> - The UI then does what it wants with the information.