Min required SDK version for existing code

Hi,

Is there a method to "calculate" the minimum version of SDK required for a code. Like the memory tools of the simulator that indicates the maximum memory used, perhaps the "max version" used during the executed code is written somewhere ? I know I can reduce the needed version and try to execute then wait for a crash, but perhaps there is something more .... clean and accurate ;o)

Context (why I ask it) : I added some code that use functions of SDK3.1, and that exclude some devices which only support 3.0. But in the reality, these devices never execute theses functions (Wifi is needed and they don't have). So I will return back the min version of my widget to 3.0. But I'm wondering if I can minimize the requirements to <3.0 for the widget to get available on older devices... 

  • I use a min SDK of 1.2 in really everything.  I'll exclude some devices by just not having them as targets, and in other cases, determine things with "has",

    Using wifi as an example, you really can't use the CIQ version for that - the non pro F6 devices, and the non music 245 and Venu sq don't have wifi for example.  And even things like floors aren't available on the 245's or venu sq devices - they don't have a baro.

  • Jim, I never said that I use the CIQ version to "not execute WiFi code", I check with System.getDeviceSettings().connectionInfo[:wifi] ;o). I use Wifi as an example to explain that I probably exclude some device that in reality could execute my app. The final goal is exactly to know if I need some "has" for the app to be available to more devices.

    For example I already find "Toybox.Cryptography" and "Menu2" that required 3.0, but it take time to find it ...

    So, the core of my question is : Is there a way to easily know what is the minimum version of CIQ needed by the executed code ? Or better, (I know I dream Joy) list all functions that have been executed and the CiQ associated Relaxed , and I know, it would be better to check this as the development progresses, but it's too late Sweat smile.

  • In the case of Menu2, that's another place I use "has".  If Menu2 is available, I use it, other wise I just use Menu.

  • Thanks Jim, but it's not my question... I don't really need help (from now) on the how to do, but on the how to find where... 

  • There isn't really a "where" except the API Doc, where it has "Since" and "Supported devices", but I'm saying with "has" you might not need a new list of things and can protect your code in the event you miss something..

  • I think the point here is OP wants to unconditionally support features X, Y and Z, and wants to know the easiest way to determine which devices (or which minimum SDK version) supports those features. (e.g. By some fancy analysis of the code). I don't think "has X" *alone* helps if you want the app to be unavailable when X is not supported.

    One crazy idea could be to just use/check all the features you're worried about in unit tests, set the minimum version to 1.2, run the unit tests for all devices, and see which devices crash. Then you could keep raising the minimum version until all the devices pass. Not sure if this could be fully automated unless you generate the version-specific manifest.xml files in advance, each with the full set of devices for a given version.

    In reality, it would probably be more practical to check the supported devices/versions in the docs.

  • OK thanks to you guys. I will continue to do as you said !

    But finaly, the more I go ahead the more I found things that requiered SDK3.0 ... If it's for having a double size of the code, I think it will be better to rewrite a new app named "lite" Joy

  • You could use exclusions to create different versions of the same app for different devices.

    That's my preferred way of doing it as opposed to having 2 or more versions in the store. (Although I can see the pros and cons of both approaches.)

  • Or jungles and have a different source for "with xyz" and "without xyz".

    I do that for on device maps yes/no, .Use code for MapTrackView if yes, or breadcrumbs for no.

    I find this is cleaner than using exclusions in many cases.

  • Jungles may be cleaner, but there's more code/memory overhead IIRC, which is why I don't use them.