I'm taking my inspiration from Andmore, which like Dartboard, is an adjunct to an external SDK.
Portability and SDK support are related simply because SDK details vary according to platform, for example, the representation of the installation location. Native language support is also a portability concern which spills over to emulator and device support.
Andmore, like SWT, implements OS-specific fragments for multi-platform support and I have created 3 such fragments, based on the Andmore template, for Linux, Windows and Macosx 64-bit. For a first step, each fragment contains parameters which feeds into a utility class for checking if a Dart or Flutter SDK is installed. This check is extracted from the current preferences implementation. By this step, the preferences code has been cleaned of logic based on operating system. This improves maintainability and test coverage, so I hope OS fragments will be accepted.
As regards SDK support, I like the way Andmore, at start up, checks if a usable Android SDK is installed and presents the user with options if a remedy is required. The Android SDK Manager then allows the user to download and install the latest stable version of the SDK after accepting relevant terms and conditions. I imagine something along the same lines for Dart and Flutter SDKs will come to Dartboard. In fact, as the Android SDK is a Flutter dependency, I guess we should throw in the Android SDK Manager too.
I'm taking my inspiration from Andmore, which like Dartboard, is an adjunct to an external SDK. Portability and SDK support are related simply because SDK details vary according to platform, for example, the representation of the installation location. Native language support is also a portability concern which spills over to emulator and device support.
Andmore, like SWT, implements OS-specific fragments for multi-platform support and I have created 3 such fragments, based on the Andmore template, for Linux, Windows and Macosx 64-bit. For a first step, each fragment contains parameters which feeds into a utility class for checking if a Dart or Flutter SDK is installed. This check is extracted from the current preferences implementation. By this step, the preferences code has been cleaned of logic based on operating system. This improves maintainability and test coverage, so I hope OS fragments will be accepted.
As regards SDK support, I like the way Andmore, at start up, checks if a usable Android SDK is installed and presents the user with options if a remedy is required. The Android SDK Manager then allows the user to download and install the latest stable version of the SDK after accepting relevant terms and conditions. I imagine something along the same lines for Dart and Flutter SDKs will come to Dartboard. In fact, as the Android SDK is a Flutter dependency, I guess we should throw in the Android SDK Manager too.