Seeking external input: Other platform implementations

[russhwolf]

Currently Multiplatform Settings has Android and iOS implementations. It could be nice to be able to use it on other platforms as well.

I've done some initial explorations here but am interested in hearing others' needs and use-cases

It would be straightforward to do a macOS implementation since NSUserDefaults exists there just like iOS. I have also begun to look at using the storage api for a JS implementation.

What are other platform APIs that would be useful to expose through this library

[russhwolf]

Also related to this: what demand is there for adding arm32 in addition to arm64 support on iOS? I see there was a fork to add this. My understanding is 32-bit iOS devices are mostly on the way out at this point but I spend a lot more time on the Android side of things in my day job.

[kgonyon]

As far as I know, the only devices supported by Apple that are not 64bit are their watches. All supported iPhones, iPads, iPods, and Apple TVs are all 64bit. By supported I mean still receive updates to their OS from Apple.

I cannot speak for other shops, but we do not support any device that is not currently supported by Apple themselves. I could see this being different for companies dealing with business to business services. Our shop also doesn't deal with Apple Watch applications so not sure about those devices.

From my perspective there are few cases where arm32 support would be required.

[r4zzz4k]

What do you think about plain JVM? I believe Properties should suite well as a backing storage.

[galex]

I would need that for a React-Kotlin app. Using storage in JS sounds good!

[russhwolf]

In regards to JS, there are some limitations to Storage compared to SharedPreferences and NSUserDefaults.

1. There's not a built-in way to have separate named instances. Rather, there tends to be a single localStorage instance. For the moment I think I'm going to handle that by not implementing a Settings.Factory in JS, and instead just having a constructor with a Storage parameter that defaults to localStorage.
2. I have made some attempts at a listener API but have pulled back from that for now. It's a bit complex because window.addEventListener() will only respond to "storage" events from other documents which is a pretty significant behavior difference compared to the mobile implementations.

Since I'm more experienced on the mobile side and haven't done much JS myself, I'd like to hear if these limitations seem problematic to others.

[russhwolf]

Also, similar limitations seem to apply to Properties on the JVM. The Factory situation is a little different because multiple Properties files are easily possible, but they're not backed by a String name in the same way so it would be difficult to mold the existing Factory API to this implementation. As to listeners, there's no listener API at all that I'm aware of for getting callbacks on properties updates.

[galex]

For the JS part, I understand the limitations of the platform and I don't mind it. I guess using val settings: Settings = factory.create("my_settings_name") on JS would throw an exception?

My goal is to create an object class for my local storage and having different ways to get a Storage instance because of the limitations seems fair to me.

[russhwolf]

My current plan is to just not have Factory implementations for JS and JVM. You'd instantiate in JS via val settings: Settings = Settings(localStorage) and probably I'll even make localStorage a default value since the only alternative is sessionStorage which is much less likely to be what you want.

[russhwolf]

JS and JVM implementations have been added in version 0.3. They are behind @Experimental annotations because I haven't tested them closely. Please try them out and give feedback!

[eskatos]

On the JVM platform Preferences might be a better fit than Properties. Preferences are stored in a standard location and can notify changes to listeners.

Initially commented at #29 (comment)

[russhwolf]

Interesting. I remember looking briefly at Preferences and thinking it wouldn't be a good fit, but looking at it again now I can't remember why. I'll take a crack at that implementation and see how it goes.

[russhwolf]

Ok I definitely like Preferences a lot better than Properties on the JVM. Not sure how I missed it the first time. The only real issue I'm running into is that update listeners are forcibly run on a background thread, which makes it hard to fit into the existing test framework. I think I can work around that though.

So given that, I have a question for JVM users @r4zzz4k @gergelydaniel @eskatos et al: Would you rather I replace the existing properties implementation or maintain both?

[eskatos]

With my current use case, Preferences without a way to choose where and how the settings are stored would be enough for me.

On the other hand, with a Properties based implementation one could easily chose where the settings are stored. IIUC the sole limitation is no onModify.

If one needs to both manage where the settings are stored and to use onModify then with Preferences they could provide a PreferencesFactory of their own. Maybe not trivial but doable.

Going further, depending on the deployment needs, one could also write a JVM impl with yet another watchable configuration storage JVM lib like commons-configuration, jetcd, whatever.

I would say that this project should at least provide a JVM implementation that fulfill the contract and support onModify. Preferences seems to be a good fit because it's part of the JRE and supports change notification. I think it should be the default.

Note that I'm not saying a Properties backed implementation is a bad idea, and I think it would be valuable with some use cases where onModify isn't needed.

[eskatos]

About other platforms, I'd be interested with support for macos, windows and linux. My use case is a small desktop application sharing ~all code but the ui.

Like you wrote, NSUserDefaults on macos should do, it supports change notifications.

Windows could use the registry via platform.windows, it also supports change notifications.

Linux is a bit more problematic as there's either nothing, or desktop environment specific things (gnome-config, kde-thing etc..). I think that starting from nothing would be the best bet. Something like using text files in $HOME/.config/applicationName/ (see freedesktop spec), maybe libconfig or libconfuse or just kotlin-common, and maybe platform.linux.inotify for onModify, or maybe some other options ...

</wishful-thinking>

I know this would be quite a lot of work. I'm just writing down my wishes :) I'm in no hurry and don't have much time but I could give a hand if you plan to move this project towards supporting more platforms.

[russhwolf]

For JVM, I think I'm going to leave both implementations in for now, but might deprecate the properties one.

For desktop native, I guess I never documented it here but macOS actually is already included using the NSUserDefaults implementation. I'll take a look at Windows at some point but no promises it will be soon. Open to contributions there if you know the right platform.windows API to use. And for all of them, something I'd like to do once CI is in place is deploy to all platforms even where there isn't an implementation, which would allow consumers to add their own. That's essentially what the ask was in #17.

[russhwolf]

With the release of v0.5, Common code is now being compiled to all platforms. This should lower the barrier to experimenting with new platform implementations.

For anyone interested in contributing such an implementation, I'm definitely open to PRs. However I think it's likely that for most platforms that don't yet have an implementation, there isn't a good API in the stdlib to use. Since I'd like to keep the core library lean, I'd ask that you put any new implementation that requires new external dependencies in a separate module.

[russhwolf]

I have a Windows registry implementation updated from @r4zzz4k's which is passing tests locally on an old Windows 7 box, but failing CI (see #46). Would love thoughts/feedback from anyone with more Windows dev experience than myself.

[russhwolf]

Also while I'm in here, I've experimented a little bit with using DBM on Linux via sdbm but no idea if that's useful or not for interop purposes. See #41. I can get it working on Mac (both via platform.darwin.DBM, and via cinterop) but not sure what's missing in the Linux config.

[russhwolf]

Windows support via the registry is now released in version 0.6

[chris-hatton]

Just for the show of hands, I have a project underway in which I'll be developing a Web Client alongside Desktop Compose, Android and iOS; so I am interested in a browser Web Storage API / IndexedDB backed Kotlin/JS version.

Edit: I should have looked harder, this exists already 😂

[russhwolf]

Web Storage is there. If you think there's a use-case for IndexedDB let me know, as I've never worked with it.

[russhwolf]

There's a reasonable amount of coverage across platforms at this point so I'm closing out this issue in favor of having separate tickets for any other new implementations anyone wants to propose. See for example #113.