Homework — feel why DI is worth it.

1. Move everything to Koin. Make sure object Network is deleted and MenuScreen uses koinViewModel(). The menu should load as before.
2. Try factory vs single. Temporarily change single { MenuRepository(get()) } to factory { ... } and, via Logcat (or a println in the constructor), watch how many times the repository is built. single — once; factory — on every request.
3. DI's payoff in tests (the important part). A test shouldn't need a real network. With DI you can hand it a fake repository:

class FakeMenuRepository : MenuRepository(FakeApi()) {
    override suspend fun getMenu() = listOf(MenuItem(1, "Test pizza", "…", 8.5, "pizza", null))
}

// in the test:
startKoin { modules(module { viewModel { MenuViewModel(FakeMenuRepository()) } }) }

Without DI, MenuViewModel would build Network.api itself — and the test would always hit the network. With DI you swap the dependency in one line. That's the point of DI: not "prettier code," but the ability to substitute dependencies — in tests, in different builds, dev vs prod.

To submit: (1) the menu screen (via Koin), (2) the Logcat line [Koin] started with N definitions.

Next. The graph is ready and clean. In lesson 7 we add a Room cache — it's just one more single { } in the modules, and the menu starts working even offline. DI now lets the app grow painlessly.