[shared_preferences] Convert legacy codepath to Kotlin

[stuartmorgan-g]

Since this plugin already uses Kotlin code for the new codepaths, it doesn't fall under our usual policy of currently not converting code to Kotlin, we just never bothered to do the conversion for the old code. This converts the legacy implementation to Kotlin so that the plugin is consistent. The process for this conversion was:

• use the Android Studio auto-conversion to Kotlin
• fix up type nullability (the auto-convert assumes non-annotated types, including any generics, are nullable)
• remove Throws annotations that aren't needed in Kotlin
• autoformat
• do a couple of conversions from direct Java translation to more idiomatic Dart, especially around collection filtering and mutation

I did also remove some duplicate string constants and switched to the copies that the non-legacy Kotlin code already had, since sharing those constants was now trivial, and less duplication is better.

Per our usual best practice, this doesn't convert the tests in the same PR, so that we guarantee that we aren't masking a regression with an accidental test change. I'll convert the unit tests in a separate PR with no changes to functional code.

Part of flutter/flutter#188630

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[stuartmorgan-g]

This change was needed because the tests used to get away with returning a null binary messenger because the Java code never actually tried to use it. In Kotlin it exploded right away because that property isn't nullable, and Kotlin actually enforces nullability :)

[gemini-code-assist]

Code Review

This pull request converts LegacySharedPreferencesPlugin and SharedPreferencesListEncoder from Java to Kotlin, alongside minor updates to SharedPreferencesPlugin.kt and LegacySharedPreferencesTest.java. The review feedback suggests several improvements to the Kotlin implementation, including resolving method call ambiguity by explicitly referencing SharedPreferencesApi.setUp, optimizing collection operations in clear and getAllPrefs to avoid intermediate allocations, and replacing unchecked casts with type-safe filterIsInstance calls.

[gemini-code-assist]

Using .filter { ... }.mapValues { ... } creates an intermediate map and requires a force-unwrap (value!!). Using buildMap is more idiomatic, performs the filtering and transformation in a single pass, and allows Kotlin to smart-cast value to a non-nullable type, eliminating the need for value!!.

Suggested change

	private fun getAllPrefs(prefix: String, allowList: Set<String>?): Map<String, Any> {
	return preferences.all
	.filter { (key, value) ->
	key.startsWith(prefix) && value != null && (allowList == null || allowList.contains(key))
	}
	// Force-unwrapping is safe here due to the `value != null` in the filter above.
	.mapValues { (key, value) -> transformPref(key, value!!) }
	}
	private fun getAllPrefs(prefix: String, allowList: Set<String>?): Map<String, Any> {
	return buildMap {
	preferences.all.forEach { (key, value) ->
	if (key.startsWith(prefix) && value != null && (allowList == null || allowList.contains(key))) {
	put(key, transformPref(key, value))
	}
	}
	}
	}

[stuartmorgan-g]

Changed.

Using .filter { ... }.mapValues { ... } creates an intermediate map and requires a force-unwrap (value!!). Using buildMap is more idiomatic

Which is funny because Gemini suggested the code being reviewed here when I did a local Gemini review specifically prompting for a focus on idiomatic Kotlin.

[gemini-code-assist]

Instead of an unchecked cast with @Suppress("UNCHECKED_CAST"), you can use filterIsInstance<String>() which is fully type-safe and idiomatic in Kotlin.

Suggested change

	@Suppress("UNCHECKED_CAST") val listValue = (value as Set<String>).toList()
	val listValue = value.filterIsInstance<String>()

[stuartmorgan-g]

Gemini suggested this locally as well; I chose not to do it since while it is "safer", it's a behavioral change from the old code, and would cause invalid data to be silently dropped instead of erroring, which I'm not convinced we want in the very unlikely event that it does happen. And if we do want that, it should be a separate intentional change, rather than a side-effect of the Kotlin conversion.

[gemini-code-assist]

Instead of an unchecked cast with @Suppress("UNCHECKED_CAST"), you can use (stream.readObject() as List<*>).filterIsInstance<String>(). This is safer, avoids the warning suppression, and is consistent with the implementation in SharedPreferencesPlugin.kt.

Suggested change

	@Suppress("UNCHECKED_CAST") return stream.readObject() as List<String>
	return (stream.readObject() as List<*>).filterIsInstance<String>()

[stuartmorgan-g]

Same as above.

[tarrinneal]

Besides a couple nits, this is fine. I'm curious if you looked into overlapping code with the newer SP for clean up at all?

[tarrinneal]

Probably wasn't anything here before either, but the comment could be in here instead.

[stuartmorgan-g]

Moved into the string.

[tarrinneal]

IN WHAT?

[stuartmorgan-g]

Huh, I wonder how I did that. Restored the rest of this comment.

[stuartmorgan-g]

Besides a couple nits, this is fine. I'm curious if you looked into overlapping code with the newer SP for clean up at all?

I intentionally did not, but I did mean to add a TODO in the legacy file about that and forgot. I'll add it.