feat: implement platform-specific Logger implementations

[SmilingPixel]

No description provided.

[Copilot]

Pull request overview

This PR implements a cross-platform logging utility for a Kotlin Multiplatform Compose application. It provides a common Logger interface with platform-specific implementations for Android, JVM, and WasmJs.

Changes:

• Added common Logger interface with LogLevel enum and convenience extension functions
• Implemented Android-specific logger using Android's Log API
• Implemented JVM-specific logger using System.out/err
• Implemented WasmJs-specific logger using println

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
composeApp/src/commonMain/kotlin/io/github/smiling_pixel/util/Logger.kt	Defines the common Logger interface, LogLevel enum, and convenience extension functions for logging
composeApp/src/androidMain/kotlin/io/github/smiling_pixel/util/Logger.android.kt	Android implementation using android.util.Log API
composeApp/src/jvmMain/kotlin/io/github/smiling_pixel/util/Logger.jvm.kt	JVM implementation routing ERROR to System.err and other levels to System.out
composeApp/src/wasmJsMain/kotlin/io/github/smiling_pixel/util/Logger.wasmJs.kt	WasmJs implementation using println for console logging

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing iOS implementation for Logger. The project's build.gradle.kts configures iOS targets (iosArm64 and iosSimulatorArm64), but there is no corresponding Logger.ios.kt file in composeApp/src/iosMain/kotlin/io/github/smiling_pixel/util/. This will cause a compilation error for iOS targets. An iOS implementation should use NSLog or print for logging.

Suggested change

	expect object Logger {
	fun log(level: LogLevel, tag: String, message: String)
	object Logger {
	fun log(level: LogLevel, tag: String, message: String) {
	println("[$level][$tag] $message")
	}

[Copilot]

The WARN log level is currently being written to System.out. Consider routing WARN messages to System.err as well, since warnings typically indicate potential problems that should be visible in error streams. This would be more consistent with common logging practices where both warnings and errors are sent to stderr.

Suggested change

	val stream = if (level == LogLevel.ERROR) System.err else System.out
	val stream = if (level == LogLevel.ERROR || level == LogLevel.WARN) System.err else System.out

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing documentation for the LogLevel enum. The enum should have KDoc comments explaining what each log level represents and when it should be used (e.g., DEBUG for debugging information, INFO for informational messages, WARN for warning messages, ERROR for error conditions).

Suggested change

	enum class LogLevel {
	DEBUG, INFO, WARN, ERROR
	/**
	* Represents the severity of a log message.
	*
	* Loggers can use this level to filter or format output depending on
	* how important or noisy a given message is.
	*/
	enum class LogLevel {
	/**
	* Fine‑grained diagnostic information that is useful during development
	* and troubleshooting, but typically too verbose for production logs.
	*/
	DEBUG,
	/**
	* General informational messages that describe the normal flow of the
	* application, such as lifecycle events or high‑level state changes.
	*/
	INFO,
	/**
	* Potential problems or unusual situations that are not necessarily
	* errors but might require attention or investigation.
	*/
	WARN,
	/**
	* Error conditions indicating that an operation has failed or that the
	* application is in an unexpected state and may not be able to continue
	* normally.
	*/
	ERROR

[Copilot]

Missing documentation for the extension functions. These convenience functions (d, i, w, e) provide a simpler API for logging but lack KDoc comments explaining their purpose and parameters. Consider adding documentation that clarifies they are shorthand methods for the different log levels.

Suggested change

	fun Logger.d(tag: String, message: String) = log(LogLevel.DEBUG, tag, message)
	fun Logger.i(tag: String, message: String) = log(LogLevel.INFO, tag, message)
	fun Logger.w(tag: String, message: String) = log(LogLevel.WARN, tag, message)
	/**
	* Logs a debug-level message using this [Logger].
	*
	* Shorthand for calling [log] with [LogLevel.DEBUG].
	*
	* @param tag A short tag identifying the log source.
	* @param message The message to be logged.
	*/
	fun Logger.d(tag: String, message: String) = log(LogLevel.DEBUG, tag, message)
	/**
	* Logs an info-level message using this [Logger].
	*
	* Shorthand for calling [log] with [LogLevel.INFO].
	*
	* @param tag A short tag identifying the log source.
	* @param message The message to be logged.
	*/
	fun Logger.i(tag: String, message: String) = log(LogLevel.INFO, tag, message)
	/**
	* Logs a warning-level message using this [Logger].
	*
	* Shorthand for calling [log] with [LogLevel.WARN].
	*
	* @param tag A short tag identifying the log source.
	* @param message The message to be logged.
	*/
	fun Logger.w(tag: String, message: String) = log(LogLevel.WARN, tag, message)
	/**
	* Logs an error-level message using this [Logger].
	*
	* Shorthand for calling [log] with [LogLevel.ERROR].
	*
	* @param tag A short tag identifying the log source.
	* @param message The message to be logged.
	*/

[SmilingPixel]

@copilot open a new pull request to apply changes based on the comments in this thread

[Copilot]

@SmilingPixel I've opened a new pull request, #12, to work on those changes. Once the pull request is ready, I'll request review from you.