Explore – Alfan Nasrulloh

Migrasi Android dari API 28 ke API 35: Menghadapi Dependency yang Saling Menggantung

Saya menghadapi sesuatu proses pekerjaan yang mesti dilakukan tapi cukup malas dan menunda untuk dikerjakan. Agak malas karena ngerjain satu hal tapi harus mengerjakan yang lain juga. Kesalahan di satu hal bisa merembet ke yang lain, begitu juga sebaliknya. Proses ini adalah upgrade API level android dan gradle.

Google kini mewajibkan minimal target API level 35 untuk aplikasi yang ingin dirilis atau di-update di Play Store. Bagi banyak developer yang masih bertahan di API 28, migrasi ini bukan sekadar ganti angka—tapi sebuah proses kompleks yang melibatkan dependency, build system, dan refactor kode besar-besaran.

⚠️ Kenapa Migrasi Ini Mendesak?

Google Play Policy: Mulai 2025, aplikasi baru dan update harus menargetkan API 35.
Banyak aplikasi lama masih di API 28, karena tidak pernah di-update sejak 2019–2020.
Perubahan besar di dependency seperti AndroidX, Jetpack, AGP, dan Gradle membuat migrasi tidak bisa dilakukan parsial.

🔄 Tantangan Migrasi: Dependency yang Saling Menggantung

Update satu dependency sering memicu error di dependency lain.
Banyak library yang sudah deprecated atau tidak kompatibel dengan AGP terbaru.
Proses migrasi bisa jadi loop tak berujung kalau tidak dilakukan secara menyeluruh.

🧱 Komponen yang Harus Diupdate Bersamaan

Untuk migrasi yang sukses, kamu harus menyentuh hampir semua lapisan build system:

🔧 File Terkait Gradle & Build System

File	Fungsi
`build.gradle (project)`	Versi Gradle Plugin & Kotlin DSL
`build.gradle (app)`	Target SDK, compile SDK, dependency
`gradle-wrapper.properties`	Versi Gradle minimum
`gradle.properties`	Flag konfigurasi build
`libs.versions.toml`	Manajemen dependency versi modern
`settings.gradle`	Konfigurasi modul dan plugin
`AndroidManifest.xml`	Target SDK dan permission yang deprecated
`proguard-rules.pro`	Penyesuaian obfuscation untuk library baru

🧹 Refactor Kode: Hadapi Deprecated API

Banyak API lama (seperti AsyncTask, getExternalStorageDirectory(), dll) sudah deprecated.
Perlu migrasi ke API modern seperti WorkManager, Storage Access Framework, dan ActivityResult API.
Gunakan lint dan IDE inspection untuk mendeteksi deprecated usage.

📦 Strategi Migrasi Modular

Audit dependency: Cek versi dan kompatibilitas dengan AGP terbaru.
Update Gradle wrapper dan AGP dulu: Pastikan build system stabil.
Migrasi ke libs.versions.toml: Untuk manajemen versi yang lebih maintainable.
Refactor kode deprecated: Gunakan IDE dan dokumentasi resmi.
Testing bertahap: Gunakan emulator API 35 dan unit test untuk validasi.

🧪 Studi Kasus & Strategi Praktis Migrasi

Untuk menghindari migrasi yang membingungkan dan penuh error, lakukan pendekatan berikut:

Install Android Studio terbaru Pastikan kamu menggunakan versi terbaru agar kompatibel dengan AGP dan SDK level 35.
Buat proyek baru dari template bawaan Gunakan template “Empty Compose Activity” atau “Basic Views” untuk melihat struktur modern.
Review struktur proyek baru Perhatikan versi Gradle, AGP, libs.versions.toml, settings.gradle, dan konfigurasi build.gradle.
Bandingkan dengan proyek lama Identifikasi perbedaan versi, plugin, dan struktur dependency.
Terapkan secara bertahap ke proyek lama Mulai dari update Gradle wrapper, lalu AGP, lalu dependency, lalu refactor kode deprecated.
Gunakan version catalog (libs.versions.toml) Ini akan memudahkan tracking versi dan menghindari konflik antar modul.

Dengan pendekatan ini, kamu bisa belajar dari proyek baru yang sudah sesuai standar modern, lalu menerapkannya ke proyek lama secara sistematis dan minim risiko.

✅ Penutup: Migrasi Bukan Sekadar Update, Tapi Rebirth

Migrasi dari API 28 ke 35 bukan hanya soal memenuhi kebijakan Google, tapi juga kesempatan untuk membersihkan, merapikan, dan memodernisasi proyekmu. Dengan pendekatan modular dan dokumentasi yang rapi, kamu bisa mengubah proses yang menyakitkan jadi investasi jangka panjang.

Kediri, 8 Sep 2025

Belajar Flutter bagi Pengembang Native

Sebagai developer yang sudah terbiasa dengan Java, Kotlin, dan Swift, kamu mungkin sudah sangat akrab dengan XML layout di Android dan Storyboard di iOS. Tapi ketika harus membangun aplikasi lintas platform, muncul pertanyaan besar: Haruskah saya belajar Flutter? Jawabannya: ya, jika kamu ingin efisiensi, modularitas, dan satu codebase untuk dua platform utama.

Blog ini adalah roadmap belajar Flutter yang dirancang khusus untuk kamu yang berasal dari dunia native. Kita akan transisi secara bertahap, tanpa membuang keahlian yang sudah kamu miliki.

🧠 Tahap 1: Memahami Paradigma UI Baru

Flutter menggunakan pendekatan declarative UI berbasis Widget Tree. Ini mirip dengan View Hierarchy di Android atau Scene Graph di iOS.

Container = View
Text = TextView / UILabel
Column = LinearLayout (vertical)
Row = LinearLayout (horizontal)
Stack = FrameLayout / ZStack

Mulailah dengan membangun layout sederhana menggunakan Scaffold, AppBar, dan BottomNavigationBar. Anggap saja ini seperti membuat Activity atau ViewController.

📐 Tahap 2: Layout & Responsivitas

Kalau kamu terbiasa dengan match_parent, wrap_content, dan AutoLayout, Flutter punya padanannya:

Gunakan Expanded, Flexible, dan SizedBox untuk kontrol ukuran.
MediaQuery dan LayoutBuilder membantu membuat UI yang adaptif.
Hindari dulu animasi atau gesture kompleks—fokus pada layout yang familiar.

Tips: Buat layout nested seperti XML-style agar transisi terasa lebih natural.

🔄 Tahap 3: Navigasi & Lifecycle

Navigasi di Flutter menggunakan Navigator.push() dan pop(), mirip dengan Intent di Android atau segue di iOS.

Lifecycle-nya juga punya padanan:

initState() = onCreate() / viewDidLoad()
dispose() = onDestroy() / deinit
didChangeDependencies() = mirip onResume() atau viewWillAppear()

Dokumentasikan perbandingan lifecycle ini untuk referensi pribadi—sangat membantu saat debugging.

🔥 Tahap 4: Integrasi Firebase & Plugin

Flutter punya ekosistem plugin yang matang, terutama untuk Firebase:

firebase_core, firebase_auth, cloud_firestore, firebase_analytics
Setup-nya mirip dengan build.gradle dan Info.plist, tapi lewat pubspec.yaml
Modularisasi setup agar bisa reuse di proyek lain

Tips: Bandingkan setup Firebase di Flutter vs native untuk insight tambahan.

🧮 Tahap 5: State Management Bertahap

Mulai dari yang paling sederhana:

setState() → cocok untuk state lokal
Provider → untuk state global yang ringan
Riverpod atau Bloc → untuk aplikasi kompleks dan scalable

Jangan langsung lompat ke Bloc atau Redux—biar nggak over-engineered di awal.

🧱 Tahap 6: Modularisasi & Struktur Proyek

Karena kamu suka arsitektur modular, Flutter bisa disusun seperti ini:

Kode

lib/
├── core/
├── shared/
├── features/
│   ├── auth/
│   ├── dashboard/
│   └── settings/

Gunakan pubspec.yaml seperti kamu pakai libs.versions.toml di Gradle. Buat komponen reusable seperti CustomButton, AppTextField, dll.

🔌 Tahap 7: Native Bridge & Optimasi

Kalau kamu butuh akses ke fitur native (sensor, BLE, dll), gunakan Platform Channels:

Flutter → Kotlin/Swift → native API
Bisa modularisasi channel agar tetap maintainable

Optimasi ukuran APK/IPA:

flutter build apk --split-per-abi
Deferred loading untuk fitur jarang dipakai
Kompres asset dan gunakan tree-shaking

🎯 Kesimpulan: Flutter Bukan Pengganti, Tapi Pelengkap

Flutter bukan berarti meninggalkan Java, Kotlin, atau Swift. Justru, kamu bisa memanfaatkan semua keahlian native untuk membangun aplikasi lintas platform yang efisien dan scalable. Dengan satu codebase, kamu bisa hemat waktu, biaya, dan tenaga—tanpa mengorbankan kualitas.

Kediri, 8 Sep 2025

Memborong PZEM-016

Setelah dua kali gagal menggunakan pzem-004t untuk membaca parameter arus AC, saya menemukan modul lain yang sejenis tetapi beda yaitu pzem-016. Modul pzem-016 sama-sama membaca parameter arus AC tetapi dia menggunakan RS485 sebagai protokol komunikasinya, sehingga lebih universal dan lebih mengikuti standar industri.

Saya langsung beli dua buah walaupun harganya lebih mahal dari pzem-004t, dengan harapan bisa lebih stabil, lancar, dan mudah digunakan. Saya sedikit lebih yakin karena saya sudah berhasil membaca pzem-017, yang dipakai untuk membaca parameter arus DC, dan tidak ada kendala.

Sebenarnya saya pernah pengalaman memiliki pzem-017 yang rusak, tetapi saya masih memiliki keyakinan kalau modul dengan protokol RS485 lebih stabil dan awet.

Semoga,

Membuat Server Foto seperti Google Photos

Seminggu ini saya agak mengesampingkan project PLTS ataupun mikrokontroller saya. Perhatian saya tersita oleh riset dan eksperimen untuk mencari alternatif atau cara agar saya tidak ketergantungan dengan layanan google photos. Pasalnya, storage saya di google one, suatu layanan storage dari google berbayar, sudah mulai mendekati penuh.

Selama beberapa tahun ini, lupa dari sejak kapan, saya berlangganan google storage sebesar 100 GB. Penyimpanan ini termasuk untuk gmail, drive, dan google photos. Layanan ini sangat membantu saya yang memang seneng fotografi, mengabadikan momen, dan suka menata arsip digital terutama foto. Saya tidak perlu pusing kehilangan hasil jepretan karena secara otomatis foto-foto saya di-backup ke cloud oleh google photos, selain backup manual yang sering saya lakukan juga ketika HP penuh.

Saya lebih percaya hasil backup google photos daripada backup manual yang sudah saya lakukan. Backup manual sering kali menyebabkan redundancy dan juga kemungkinan foto yang ter-skip. Selain itu, kedisiplinan dalam membuat kerapihan pengarsipan foto digital kadang naik dan turun sehingga tidak konsisten.

Alternatif Solusi

Seminggu yang lalu, sejak tulisan ini dibuat, saya menemukan solusi open source sebagai alternatif dari Google Photos. Ada beberapa produk yang direkomendasikan oleh AI dan salah satunya bernama Immich. Sampai sekarang saya masih amazed dengan Immich, mirip sekali dengan Google Photos. Bagi orang yang sudah terbiasa pakai google photos, saya yakin akan mudah sekali menyukainya. Fitur-fitur seperti people face recognition, smart search, timeline, maps, dll, tersedia juga di immich. Hal ini tidak terlepas dari kemajuan teknologi machine learning yang juga disematkan di immich.

Setelah itu saya terbawa suasana hingga melakukan eksperimen penuh dengan immich. Awalnya saya coba di laptop untuk melakukan evaluasi dari fitur-fitur dan pengalaman pengguna. Cukup puas dengan eksperimen lokal di laptop, saya tingkatkan dengan eksperiman di lingkungan server, sehingga bisa terintegrasi juga dengan smartphone.

Menyiapkan Dukungan System

Sebelum menjalankan Immich, saya perlu menyiapkan lingkungan sistem dimana aplikasi ini berjalan. Saya sampai tiga kali install operating system untuk server untuk ujicoba mana yang paling optimal. Server yang saya gunakan adalah komputer tua berumur 10 tahun an dengan casing dari komputer yang memiliki usia 10 tahun lebih lama lagi. Instalasi pertama saya menggunakan antiX, sebuah distro linux berbasis debian. Awalnya saya pakai yang versi arsitektur 32-bit karena saya pakai pc tua dengan os bawaan windows 7 32-bit. Setelah saya install ternyata bermasalah dengan Docker yang tidak lagi mendukung os 32-bit.

Instalasi kedua saya menggunakan AntiX-core yang 64-bit. Distro linux ini sangat ringan sesuai dengan yang diiklankan. Tetapi kompensasinya docker daemon tidak otomatis jalan. Untuk bisa menjalankan docker, ada beberapa step yang harus dilakukan terlebih dahulu secara manual. Sehingga ketika komputer restart, docker tidak langsung berjalan. Otomasi sudah coba saya lakukan dan ternyata belum berhasil. Immich sempat berhasil berjalan, tetapi masih ada kekurangan sana-sini.

Yang terakhir, saya buat agak lebih mapan dan lebih teratur. Saya tambahkan HDD satu lagi yang saya khususkan hanya untuk menyimpan foto dan metadatanya. Sedangkan HDD yang satunya saya isi dengan sistem operasi. Pemisahan ini saya lakukan untuk membuat sistem ini lebih modular dan lebih mudah dalam perawatan. Selain itu, dari sisi software, saya mencoba menggunakan ubuntu server yang harapannya lebih stabil dan lebih mudah untuk menjalankan docker dan daemon-nya.

Perubahan menjadi dua HDD ini agak memakan waktu karena perlu melakukan beberapa hal di haardware dan juga software. Di hardware saya perlu memindah jeroan CPU dari casing awal yang hanya punya satu slot HDD ke casing CPU lain, sebuah casing lama saya yang kebetulan lama nganggur, yang punya slot HDD hingga 4 atau 5 slot. Sedangkan sisi software, saya perlu ekspansi partisi HDD yang tadinya saya pakai buat ujicoba sebelumnya dengan foto yang sudah terupload hingga 200 GB. Ekspansi partisi ini saya lakukan karena partisi OS sudah tidak diperlukan di HDD kedua. Masalahnya partisi OS ada di sebelah kiri, dan saya belum menemukan cara atau tool untuk expansi partisi HDD ke sebelah kiri. Akhirnya, HDD kedua ini saya hapus total partisinya dan memulai dari awal lagi.

Bersambung… (cerita migrasi foto)

Membangun PLTS Atap: Backup PLN

Pada tulisan sebelumnya tentang Membangun PLTS Atap: UPS Modif, saya telah berbagi cerita mengenai awal mula pencarian energi alternatif untuk PC saya. Saat itu, saya mulai mencari solusi agar perangkat saya tetap bisa beroperasi dengan sumber daya yang lebih efisien dan berkelanjutan. Kini, saya akan melanjutkan ke tahap berikutnya dalam pengembangan sistem ini.

Upgrade ke LiFePO4: Investasi untuk Masa Depan

Setelah mempertimbangkan berbagai opsi, akhirnya saya memutuskan untuk membeli baterai LiFePO4 sebagai penyimpanan daya utama. Keunggulan utama dari teknologi ini adalah umur pakai yang lebih panjang, efisiensi yang lebih tinggi, dan kestabilan daya yang lebih baik dibandingkan baterai SLA atau AGM. Dengan kapasitas yang mencukupi, LiFePO4 memberikan fleksibilitas dalam sistem cadangan daya saya.

Memaksimalkan Daya dengan Inverter 3000 Watt

Agar bisa memanfaatkan baterai LiFePO4 secara optimal, saya juga memilih untuk menggunakan inverter 3000W. Keputusan ini didasarkan pada kebutuhan daya yang cukup besar, terutama untuk backup lampu, server, dan bahkan AC saat terjadi pemadaman listrik. Dengan inverter berkapasitas besar, sistem ini mampu memberikan cadangan energi yang lebih andal dan dapat menangani beban daya lebih tinggi tanpa kendala.

Sistem Sementara: Backup PLN Tanpa Solar Panel

Saat ini, saya belum memiliki solar panel dan solar charge controller (SCC), sehingga sistem sementara ini hanya berfungsi sebagai cadangan daya untuk PLN. Artinya, baterai diisi ulang dari listrik PLN, lalu digunakan sebagai UPS untuk menjaga perangkat tetap menyala saat terjadi pemadaman listrik. Meskipun belum sepenuhnya mandiri, langkah ini sudah menjadi awal yang baik dalam transisi menuju energi terbarukan.

Langkah Berikutnya: Pemasangan Solar Panel dan SCC

Tahap selanjutnya dalam proyek ini adalah memasang solar panel dan SCC agar sistem ini benar-benar bisa bekerja secara off-grid. Dengan adanya solar panel, baterai tidak lagi bergantung pada PLN untuk pengisian daya, melainkan dapat menggunakan energi matahari secara langsung. SCC berperan penting dalam mengatur aliran daya dari panel ke baterai, memastikan efisiensi pengisian yang optimal dan melindungi sistem dari overcharge.

Kesimpulan: Menuju Energi Mandiri

Membangun PLTS Atap bukanlah proses instan, melainkan perjalanan bertahap yang membutuhkan pemikiran strategis dan investasi yang tepat. Dari UPS modif, baterai LiFePO4, inverter 3000W, hingga perencanaan pemasangan solar panel dan SCC, setiap langkah membawa saya lebih dekat menuju sistem energi yang lebih efisien, berkelanjutan, dan mandiri.