Challenge 3: Designing a Shared/Platform Split — Solution

// Note-taking app: KMP shared/platform design notes
//
// commonMain (fully shared, no expect/actual needed):
//   - Note data model (data class Note(val id: String, val title: String,
//     val body: String, val updatedAt: Long)) — pure data, no platform
//     dependency at all.
//   - Note validation logic (e.g. "title must not be blank") — pure
//     business logic, works identically everywhere.
//   - Network sync logic — using a KMP-aware networking library (Ktor)
//     that already handles its own platform differences internally, so
//     the sync logic itself is just shared Kotlin calling that library.
//
// expect/actual split (same shape, genuinely different platform APIs):
//   - Local file storage — the general "save/load a Note" API can be
//     declared as an expect interface/class in commonMain, with actual
//     implementations backed by each platform's real storage API
//     (e.g. Android's file system / Room vs iOS's file system / Core
//     Data equivalent, or a KMP-aware library like SQLDelight that
//     already handles this split internally).
//
// Fully platform-specific (no sharing attempted):
//   - The note list UI screen — built natively per platform (Jetpack
//     Compose on Android, SwiftUI on iOS), per the traditional KMP
//     approach covered in this chapter.
//   - Push notification handling — registering for and receiving push
//     notifications is inherently tied to each platform's own
//     notification system (Firebase Cloud Messaging plumbing vs Apple
//     Push Notification service), with no meaningful logic to share
//     beyond "what do we do once a notification arrives," which itself
//     could live in commonMain as a callback triggered from each
//     platform's native handler.

/*
No runnable code for this challenge — it's a design/reasoning exercise.

Notes:
- The general rule from the chapter: pure logic and data go in
  commonMain; anything needing a real platform API (storage, UI,
  notifications) either gets an expect/actual pair (if the same
  capability exists differently on each platform) or stays fully
  platform-specific (if there's no meaningful logic to share at all,
  like a UI screen).
- Reaching for a KMP-aware library (Ktor, SQLDelight) before hand-writing
  expect/actual is usually the better first move, since those libraries
  already did this design work.
*/