You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
-
was not meant to be a production code =) just something I was putting together for myself
Prints are just for debugging. I was under the impression that unless you actually connect to the console it will make no difference. Device is usually just passively sending the data via BLE and I only connect to it to see if all ok or to flash an update
When LED was getting stuck, it was draining the battery quickly. I was adding the code to minimize the drain.
clearWatch - as per API, if no parameter is supplied, all watches will be removed. This is just in the onInit stage and not used anywhere else. I think it was in the original code, so I just left it there
Did not understand the state part
user130485
@allObjects
@user130485
downloaded your code and gave my understanding of it a shot...
Three things that bothers me about the code are:
And there is a 4th thing - not really adding to the code - is the source formatting... if it is structurally off, I get mislead in the logic... So my first action was to adjust it to support my (human) reading abilities and my understanding what happens when and in what relation to other sections of the code.
Regarding code design:
setInterval()is very powerful and allows straight forward and very concise code. Unfortunately, the outside world that we try to catch with the intervalled code is 'not so intervally', and thtt is why I usually resort to a monitored state machine: state machine for tracking the all state transitions, and monitored to detect irregularities in the timing of states and transitions.Intervalled code is fine if it does not interfere with state. (Sure one can have gazillions of synchronization flags / semaphores, but that does make the code not more robust or components more loosely coupled).