-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
question: design limitation precludes a common event handler? #226
Comments
Unique subscription names are a limitation of the underlying API, not just the SDK, but I can't think of any reason offhand why they need to be unique. We'll investigate. |
We're pursuing an API change that will no longer require subscription names to be unique. We'll leave this issue open and update it when we have a release date. A work-around you could do in the meantime is to declare the handler separately from the handler registration commands. It's still more code than should be necessary, but a little more maintainable than having a separate inline function in each subscribedEventHandler call.
|
When defining device subscription handlers, you cannot name a common handler across subscriptions. The SDK design seems to impose a unique handler name for each subscription. If I want to support nearly all SmartThings capabilities, I would have a potentially LARGE number of subscriptions to handle, but the current design forces me to declare a unique handler for each, resulting in an unnecessary proliferation of code.
What I want to do is this:
However, I get a subscriptionName conflict error if I try to do that. What I seem to be forced to do is define unique handlers for each like this:
Is there a better way to accomplish this or perhaps this is a needed design change in the SDK?
The text was updated successfully, but these errors were encountered: