So as I am getting deeper into DQMH usage, one of the questions I keep asking is "Should this be a status update broadcast or it's own broadcast broadcast?" On the one hand, I might argue that a broadcast should only be necessary if there is a payload. But what if the listener wants to take action on the "notification"? It is obviously much easier for it to register for separate broadcasts than to try and parse/select on a status string, which is probably going to be more verbose than say a brief message label (ala Messenger Library observer notifications). So know I have to think about if any of the listeners might care to react to my messages? Smells like coupling to me. So the logical conclusion for me is that most updates going to the external world would be better served by having its own broadcast event, so my module does not care about who is listening. So now, what is the status update broadcast good for? I would guess only notifying about State of the MHL, but since the MHL isn't actually a state machine, that could get murky. Suddenly the Status Update Broadcast, while a convenient swiss army knife for broadcasting, seems riddled with practical gotchas.
Would some of the experts mind chipping in? Thanks!
