Everything I’m reading in the forums tells me that the tiles{} stanza in metadata{} is completely ignored by the new mobile app (and the classic app refuses to run), so why do I see it in every DTH example? Even ones pointed to from the new dev portal and with commits from as recently as a couple of months ago (like here, and here)?
Likewise, why do they also contain capability declarations like “Actuator” that has been deprecated for almost three years, now?
What am I missing?
The Classic app was still working in December and tiles{} isn’t actually breaking anything. It remains to be seen if it gets removed from any handlers or it isn’t considered worth the effort given their days are numbered.
The Actuator and Sensor capabilities remain incredibly useful for use with certain legacy SmartApps, given the absence of any way of authenticating all devices that is exposed to community developers. Arguably they shouldn’t really be deprecated at all as far as handlers are concerned.
There are plenty of other deprecated capabilities whose continued use is less justified (Holdable Button and Outlet for example), but even then there may be legacy SmartApps that still use them or look for them so it doesn’t seem wise to remove them once they have been used. Deprecation has to start with the apps really.
Whose days are numbered? Handlers?
Yes. Groovy Device Type Handlers and SmartApps use the legacy platform which is on its way out. No firm dates for final switch off but if it is still here at the beginning of next year I’d speculate that would be the result of slippage in dates.
Is there a better way to support a device which is today handled (or, failing to be properly handled, in the new app) via a groovy DTH?
If it’s a hub connected zwave or zigbee device, there’s still no other option. If it’s a WiFi device, it’s probably best to use the tools in the new dev portal.