Belajar Desktop Developer - Multi-Window & Multi-Process

#Pendahuluan

Di episode 23 CatatanKu resmi menjadi platform dengan plugin. Namun aplikasi desktop yang dipakai serius jarang bertahan dengan satu jendela saja: editor utama, panel preview, jendela pengaturan, dan komposer catatan baru sering kali berdampingan. Masalahnya bukan sekadar "membuka jendela" — tapi bagaimana proses di baliknya bekerja.

Episode ini membedah multi-window & multi-process: pola desain window, model proses di Tauri, Electron, dan Flutter, mengapa isolasi proses membuat aplikasi lebih stabil sekaligus aman, dan bagaimana window-window berkomunikasi tanpa berbagi memori secara membabi buta.

#Mengapa Multi-Window

Multi-window bukan hiasan. Beberapa alasan nyata:

• Konteks paralel — pengguna membuka beberapa catatan sekaligus (SDI, single-document interface) seperti browser tab.
• Fitur berdampingan — editor + jendela preview yang bergerak bebas, bukan panel yang menempel.
• Pemisahan tugas — jendela pengaturan terpisah dari jendela utama, sehingga kerusakan di satu window tidak mengacaukan yang lain.
• Alur fokus — komposer yang menonjol (modal floating) memaksa pengguna menyelesaikan satu tindakan.

Keputusan arsitektur kedua adalah SDI vs MDI (multiple-document interface). Aplikasi modern mayoritas memilih SDI dengan beberapa window — satu catatan per window — karena lebih sederhana, lebih mudah diisolasi, dan sinkron dengan model mental OS.

#Model Proses di Balik Window

Pertanyaan pentingnya: apakah satu window = satu proses? Jawabannya tergantung framework — dan ini menentukan stabilitas serta strategi komunikasi kalian.

#Electron: Main + Renderer per Window

Di Electron setiap BrowserWindow mendapat renderer process Chromium sendiri. Main process adalah pengatur: membuat window, meneruskan IPC, dan mengelola lifecycle. Satu renderer crash → window itu bisa di-reload tanpa menjatuhkan aplikasi — ini isolasi proses yang nyata.

#Tauri: Core Rust + Webview per Window

Tauri memakai satu core Rust untuk semua window, lalu setiap window adalah webview (WebKitGTK di Linux, WKWebView di macOS, WebView2 di Windows). Komunikasi window ↔ core lewat IPC; core yang memegang state penting, webview hanya "wajah".

#Flutter: Satu Isolate, Banyak Native Window

Flutter desktop berjalan dalam satu Dart isolate dan membuka window native (Window.toWindow()). Karena satu isolate, window berbagi heap — pemisahannya bukan isolasi proses, melainkan disiplin state di sisi kalian. Ini trade-off: lebih ringan, tapi satu kesalahan global bisa memengaruhi semua window.

#Isolasi Proses: Stabilitas dan Keamanan

Isolasi proses memberi dua hal sekaligus:

• Stabilitas — crash, hang, atau plugin bermasalah (episode 23) terkurung di satu window, bukan merobohkan seluruh aplikasi.
• Keamanan — setiap window bisa diberi permission minimal sendiri (episode 14). Window yang membuka konten tidak tepercaya tidak mendapat akses ke database penuh.

Konsekuensinya: jangan berbagi memori antar window. Renderer tidak boleh saling memegang referensi state. Cara berbagi yang benar:

• Database lokal (episode 8) sebagai sumber kebenaran — semua window membaca/menulis dari sana.
• IPC via main/core sebagai bus pesan — bukan pointer sharing.

#Komunikasi Antar Window

Semua komunikasi antar window melewati satu otoritas pusat: main process (Electron) atau core (Tauri).

// main process
function broadcast(event: string, payload: unknown) {
  for (const window of BrowserWindow.getAllWindows()) {
    window.webContents.send(event, payload);
  }
}
 
// renderer A menerima
ipcRenderer.on("note:updated", (_e, note) => refreshView(note));

use tauri::{Manager, Emitter};
 
#[tauri::command]
fn note_updated(app: AppHandle, note: Note) {
    // broadcast ke semua window yang mendengarkan "note:updated"
    let _ = app.emit("note:updated", note);
}

Pola ini sama dengan streaming AI di episode 21: event dengan payload, diterima siapa saja yang butuh. Tidak ada window yang memanggil state window lain secara langsung.

#Perilaku Spesifik Platform

Multi-window tidak lepas dari kebiasaan tiap OS:

• macOS — pengguna mengharapkan "Reopen windows" saat aplikasi dibuka ulang; jendela terakhir yang aktif sebaiknya di-restore.
• Windows — window terkelompok per aplikasi di taskbar; grouping dan snap behaviour datang dari OS, jangan ditimpa.
• Linux — perilaku ditentukan window manager (tiling vs floating); aplikasi harus menyesuaikan, bukan memaksa.

Terapkan dengan logika kondisional platform dari episode 25 — karena menulis multi-window yang "benar di satu OS" dan rusak di OS lain adalah pitfall klasik.

#Common Pitfalls

• Kehilangan referensi window — window yang tidak disimpan dalam WindowManager bisa di-garbage collect; simpan semua referensi.
• Berbagi state via referensi memori — renderer A mengubah state renderer B secara langsung; selalu via database + IPC.
• Mengabaikan restore state — pengguna membuka ulang aplikasi dan semua window hilang; persist posisi/ukuran.
• Meniru perilaku OS lain — memaksakan grouping ala Windows di macOS; ikuti konvensi platform.
• Terlalu banyak window — setiap window renderer memakai memori (episode 16); buka window sesuai kebutuhan, tutup yang tak terpakai.

#Penutup

Inti yang harus dibawa pulang:

• Multi-window (SDI) memisahkan konteks pengguna dan mengisolasi kerusakan; model proses berbeda per framework — Electron (renderer per window), Tauri (core + webview per window), Flutter (satu isolate, window native).
• Isolasi proses adalah keamanan sekaligus stabilitas; berbagi data lewat database + IPC, bukan memori.
• Komunikasi antar window melalui otoritas pusat dengan pola event (broadcast), dan state window dikelola satu WindowManager terpusat.
• Hormati perilaku platform untuk multi-window — macOS, Windows, dan Linux punya konvensi berbeda.

Di episode 25 berikutnya kita memakai semua yang sudah dibangun untuk menuntaskan janji utama desktop development: cross-platform mastery — satu codebase yang benar-benar berjalan di Windows, macOS, dan Linux dengan adaptasi platform yang tepat. Sampai jumpa di episode 25!