e.g.
// in entry point class that extends appbase
var val;
if (Toybox.Application has :Properties) {
// ciq >= 2.4.0
val = Application.Properties.getValue("foo");
} else {
// ciq < 2.4.0
val = AppBase.getProperty("foo"); // compiler warns that AppBase.getProperty is deprecated
}
Regardless of what device this code is built for, the compiler will warn that AppBase.getProperty is deprecated. I would argue this is confusing and misleading because:
1) getProperty is not deprecated for devices with CIQ < 2.4.0. In fact, for those devices getProperty is *required*, if you want to read persisted data
2) Even for devices with CIQ >= 2.4.0, the warning may be confusing because it still implies that your code is wrong because it calls that function (even though as written, it will never be called for those devices.)
Here's an example of where the deprecation warning may have led to confusion (or not, it's hard to say):
(it's a deprecation warning triggered by an SDK sample which correctly shows code which can run on both older devices and newer devices, using old deprecated enums for older devices, and new non-deprecated enums for newer devices)
Nonetheless, the issue of the deprecation warnings has come up many times in the forums.
I realize this is sort of a no-win situation here. I don't have any good suggestions for fixing it. But I do think there needs to be a way for the compiler to convey that code which uses deprecated symbols *may* be correct after all.
