Closed russhwolf closed 5 years ago
In the absence of any feedback I plan to go ahead with this change. This will also add flexibility around exposing the Settings
interface to platforms that don't have an included implementation. See #17 for a potential use-case there.
Implemented in version 0.3
Right now the library contains interface methods which are implemented by expect declarations. Historically this is because the initial implementation used the expect/actual functionality, and the interface was added later to better allow consuming code to mock the library in unit tests. However this now feels redundant, since the expect/actual declarations aren't adding much.
As a result I am considering removing the
PlatformSettings
class and replacing it with separateAndroidSettings
andIosSettings
classes that implement theSettings
interface directly. Since common code mostly will just be interacting with the interface anyway this will probably only require consumers to update their instantiation code and not other usage. I'm interested in feedback on whether there's a good reason not to do this other than backward-compatibility.