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
Parents
  • over 2 years ago in reply to Brandon.ConnectIQ

    I always compile with Strict. I didn't think to try without, because this really doesn't look like a type checker error. Checking for deprecated functions should really be a separate option. Also, functions should only be deprecated when there's an alternative - ie its fine to deprecate AppBase.getProperty for newer devices; but deprecating it for devices that have to use it makes no sense at all...

Comment
  • over 2 years ago in reply to Brandon.ConnectIQ

    I always compile with Strict. I didn't think to try without, because this really doesn't look like a type checker error. Checking for deprecated functions should really be a separate option. Also, functions should only be deprecated when there's an alternative - ie its fine to deprecate AppBase.getProperty for newer devices; but deprecating it for devices that have to use it makes no sense at all...

Children
  • 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.