Developers

[kyleabaker]

I've noticed in at least one of the sdk examples that a port is being created and reused for more than one screen (stored in m.port). Will this cause problems stacking screens with the same port or should I be creating a unique port object for each screen?

[destruk]

When you check a port, it removes the keypress from the queue. So really, one port or multiple ports shouldn't make much of a difference.

[TheEndless]

Sharing a port allows you to use the same wait loop to process events from multiple components (e.g., an roImageCanvas on top of an roVideoPlayer with roSystemLog enabled). If you don't have that need, then it doesn't really matter which approach you take.

[gabek]

I like the approach of creating one central event bus, with one loop. Each component can re-use the same port assigned to that loop and all callbacks can come through that central point. Not everybody needs that, but I find that it cleans things up.

[belltown]

"gabek" wrote:
I like the approach of creating one central event bus, with one loop. Each component can re-use the same port assigned to that loop and all callbacks can come through that central point. Not everybody needs that, but I find that it cleans things up.

With only one event loop handling all events from all components, you'd need a way to know which component generated which event. That might be harder to do if they share the same port, depending on the complexity of your code.

[gabek]

"belltown" wrote:
With only one event loop handling all events from all components, you'd need a way to know which component generated which event. That might be harder to do if they share the same port, depending on the complexity of your code.

It's true! My logic is broken up by component. As messages come in it gets routed to a function for that component type that determines who is expecting that callback. I suppose it sounds more complex typing it out than I think it is 🙂 But centralizing that code has been cleaner for me.