I want to drill down into the TagSubscription to get the specific TagChangeListener for each tag. Our Ignition module creates TagChangeListeners and attach listeners to a distinct tag path through the GatewayTagManager.subscribeAsync() call.
Unfortunately, the return list from tagSubscriptionModel.getAllSubscriptions is empty.
Sure. We are currently doing that. Do you know if there is any call similar to getAllSubscriptions() or getListeners() ?
We want to prevent attaching more than one listener, of the same type, to an Ignition tag.
Or, querying the TagManager’s listeners, getAllListeners(), and comparing that to what we have bookkept ?
Are you really creating your own instance of TagSubscriptionModel for something or was that just part of your code sample?
If you subclassed it then you could access one of the protected internal fields but I don’t really see what use creating your own TagSubscriptionModel in the first place is.
I just sub-classed a TagSubscriptionModel to RsTagSubscriptionModel.
How can the TagChangeListeners registered with the new RsTagSubscriptionModel catch the TagChangeEvent that occurs at the IG Gui ?
I have switched adding FilteredTagChangeListeners to the GatewayTagManager using subscribeAsync to adding them to the RsTagSubscriptionModel by calling subscribe.
I can see the collection of TagSubscriptions in RsTagSubscriptionModel here:
Collection<TagSubscription> subscriptions = rsTagSubscriptionModel.getSubscriptions(providerName);
logger.info("num tag subscriptions " + subscriptions.size());
However, the FilteredTagChangeListener is not called when there is a TagChangeEvent from the IG GUI when a user clicks a toggle switch.
I think you’re missing the point I was trying to make: there is no reason for you to be subclassing or instantiating this class. It doesn’t do anything for you. It’s meant for bookkeeping, and the parts of the Ignition system that allow you to register listeners use it for that.
If you create your own nobody is using it but you.
I haven’t had to do this for tag subscriptions (none of my modules interact directly with tags) but the core requirements would apply to any such book-keeping. Specifically, there would be a collection held in one of your class objects that is in turn, one way or the other, persisted by a reference from your gateway hook. Such that the gateway hook’s teardown of your module in shutdown would be able to tear down your listeners, too. Or some collection of objects managed by your hook will themselves tear down the listeners. In a pinch, you could use a static field in one of your classes to hold the root collection, but I try to avoid that.
I would probably use something like a Map<TagPath, Listener> for your case.
Thanks so much for the feedback @pturmel. The GatewayHook that we’ve implemented does maintain the TagChangeEventListeners mapped to a full tag Path. @Kevin.Herron Would you know why the TagSubscrptionModel is listed in the Ignition SDK / API, yet it is not expected to be used by a module developer ?
Can you list any specific example of how the TagSubscriptionModel is used by a module developer ?
You’re just looking at Javadocs generated for everything in the gateway-api artifact (well, everything in all the artifacts that constitute the “SDK”, which is just anything that needs to be public to make various modules).
Just because it’s in there doesn’t mean it’s something useful to you or something you will need. TagSubscriptionModel might just be in there because it’s used as a parameter to GatewayTagProvider::setup, which is in gateway-api.
I don’t know what all module authors are up to but it’s probably not being instantiated and used by any module authors.