I now want to display options to configure the devices selected. If we focus on the avatar device list at the bottom, I want to be able to edit options for each device, not necessarily all devices displayed on screen at the same time, but at least provide a list of the devices to click on and display a settings page allowing for the device preferences to be modified.
I am not sure how best to display the device list and forward onto a page to display the devices settings. Any help would be appreciated.
You need dynamic pages for this, and you can use conditionals, loops, variables, and whatever you need in there to get the specific things displayed that you want. My Dimmer Button Controller app is one example that does this (with the list of bulbs/lights): Hubitat/apps/DimmerButtonController at master · RMoRobert/Hubitat · GitHub. See, in particular, the block beginning with dynamicPage(name: "pageButtonConfig", title: "Button ${btnNum} Configuration", //... and other methods it calls, perhaps most notably makeTurnOnSection().
This is what I do above. However, as of 2.3.1, I'd no longer recommend this exact approach; it won't work as some users expect with the "Swap Apps Device" feature because that feature doesn't have a way to know any way that your app internally uses device IDs (which get swapped with this feature), nor is there a platform-provided way for your app to know that devices were swapped, much less what for what. (Built-in apps are allowed to be special in this regard, which is why this even works with Dashboard JSON swapping tiles for swapped devices and whatnot, we have been told.) Bruce has given me some ideas for how to work around this problem, but I haven't implemented any of them yet.
Perhaps you can be creative enough to come up with something easy and functional. My first guess was to have the app internally assign its own ID, perhaps sequential, to the selected devices, store that matchup, then use that app-assigned ID for setting names internally...but I'm still not sure how it would know what to match up with what if anything changes. A very specific problem, for sure, but one that may catch some users off-guard nonetheless...
Thanks @bertabcd1234, I'll take a look at your button controller and play around with the concepts.
If I am working with the settings stored directly on the device though, could this still work? i.e. I don't intend to store device specific settings inside the app, only provide an interface to capture them?
There was the discussion not too long ago around pseudo devices that could sit above the actual device, allowing for the swapping without changing references, but I don't expect it would cater for this situation where you want to change the actual device being used... Perhaps I'll start by developing my first app
Hmm, I thought you were looking to present settings (inputs) in the app tied to specific devices, or at least that's what came to my mind when I read that since that's what I've done before, as you saw me link to. But, yeah, if you're just reading device attributes and presenting them but not storing anything that needs to remain associated with them in the app, I don't see any concerns there. (Unless you literally mean "settings" on the device, i.e., the drivers own inputs, which apps don't have access to...unless you have a parent/child relationship and some way to pass them back and forth, in that case.)
I do want read and write for the device preference settings. So for example my avatar driver has settings for image url's, etc. I want to display the current value on screen, but also allow for it to be updated by the user. I'm expecting I will need to setup methods in the driver to allow for this, and it would make sense that this may only be possible for those devices created by the app as child devices...
Setting things should be do-able by a command, regardless of parent/child relationship--apps can use commands and attributes of any (user-selected) device. Apps can't directly set device preferences (or state or anything else), and to call methods or access data that isn't one of these two things would take a parent/child thing--then you have full control and the ability to call and pass around pretty much whatever you need to with your own methods.
Sounds like you're aiming for a parent/child thing anyway, so you'll probably be good! (And if they're child devices, the "Swap Apps Device" feature won't work with them, anyway, so nothing in my original post concerning that feature applies, anyway...though I am still trying to think of a better way to do this kind of thing.)
My first guess was to have the app internally assign its own ID, perhaps sequential, to the selected devices, store that matchup, then use that app-assigned ID for setting names internally...but I'm still not sure how it would know what to match up with what if anything changes. A very specific problem, for sure, but one that may catch some users off-guard nonetheless...
