Under Review
over 2 years ago

SDK 4.2.0 Beta 1 won't compile AppBase.getProperty

Given

  return Application.getApp().getProperty(s);
The compiler reports
  ERROR: fr235: test.mc: '$.Toybox.Application.AppBase.getProperty' is deprecated.
But fr235 doesn't support Application.Properties.getValue, so I *have* to use getProperty when compiling for fr235.
markw65
  • over 2 years ago

    I think that the new compiler "advertises" itself as generating optimized code and not as it breaks old code. So it shouldn't change behaviour. And as it was pointed out by markw65 this is the only option for fenix3 or fr235, so it's not like "if you turn on strict then this is not good any more, use the new syntax". We have no choice but to use the old getProperty for devices that can have api level <2.4.0 so even strict shouldn't stop compiling this code! I think it shouldn't even give a warning when the device (possibly) doesn't have a newer api to use, but certainly not an error.

  • over 2 years ago in reply to markw65

    In fact I actually thought that was the case for getProperty; my impression was that it only worked on ciq-1.x devices, and that the newer apis *had* to be used in ciq-2.0 and later.

    I think I see my confusion. If you're using it to get properties controlled by settings, then you *have* to use Application.Properties.getValue on newer devices; but if you're just using it as generic storage, you can choose between getProperty and Storage.getValue.

  • over 2 years ago in reply to peterdedecker

    No it's not fine if deprecation of getproperty means removal.

    Sorry, I was thinking more generically: if a feature has been, or will be removed in newer devices, then deprecating it, followed by making it a compilation error (for such devices) makes sense.

    In fact I actually thought that was the case for getProperty; my impression was that it only worked on ciq-1.x devices, and that the newer apis *had* to be used in ciq-2.0 and later.

    But if it does indeed work everywhere, and has some advantages over the newer apis, then yes, I agree, it shouldn't be deprecated (although that's somewhat orthogonal to this issue, which is that type check level is being used to determine whether deprecated apis are errors or not).

  • over 2 years ago in reply to markw65

    "its fine to deprecate AppBase.getProperty for newer devices"

    No it's not fine if deprecation of getproperty means removal.

    I think we've established that retaining getproperty/setproperty is important:

    - backwards compatibility: it's used all over the place in a lot of projects

    - memory based (only flushes to disk at app closure), so a lot faster than storage if speed is of the essence

    - doesn't have the disk access (file not found) problems Storage has 

    If deprecation has the meaning we advise to use the new methods of access but we still leave it to be available then it's ok.