DEV Community: Cahyanudien Aziz Saputra

Membangun HadisKu 4.0

Cahyanudien Aziz Saputra — Mon, 09 Nov 2026 20:25:40 +0000

Setelah sekitar tiga bulan pengerjaan, HadisKu 4.0 akhirnya dirilis.

Ini bukan pembaruan biasa. Saya memutuskan untuk membangun ulang HadisKu dari awal. Versi sebelumnya, HadisKu 3.x, sudah berjalan dan digunakan oleh pengguna. Namun, semakin lama saya mengembangkan aplikasi ini, semakin banyak hal yang ingin diperbaiki.

Saya ingin pengalaman membaca hadis menjadi lebih baik. Bukan hanya dari sisi tampilan, tetapi juga bagaimana pengguna menemukan, membaca, menyimpan, dan mempelajari hadis.

Keputusan tersebut membawa saya pada satu pekerjaan besar: memulai kembali.

Mengapa Membangun Ulang?

HadisKu versi sebelumnya dibangun menggunakan Flutter. Secara fungsional, aplikasi berjalan dengan baik. Namun, saya merasa perlu memiliki kontrol lebih besar terhadap pengalaman aplikasi Android.

Akhirnya, saya memilih Kotlin dan Jetpack Compose untuk membangun versi baru.

Perubahan ini bukan sekadar mengganti teknologi. Saya juga menata ulang navigasi, struktur halaman, dan cara pengguna berinteraksi dengan koleksi hadis.

Ada beberapa hal yang ingin saya capai:

Membuat pengalaman membaca teks Arab lebih nyaman.
Menghadirkan pencarian yang lebih baik untuk koleksi hadis yang besar.
Memastikan koleksi hadis dapat diakses sepenuhnya secara offline.
Memberikan lebih banyak fleksibilitas dalam pengaturan tampilan.
Menambahkan alat yang membantu pengguna mempelajari dan mengelola hadis.

14 Kitab Hadis

Salah satu bagian utama HadisKu adalah koleksi kitab hadis.

Pada versi 4.0, tersedia 14 kitab hadis, mulai dari Shahih Bukhari, Shahih Muslim, hingga berbagai kitab lainnya.

Setiap hadis dilengkapi teks Arab, terjemahan Indonesia, keterangan derajat hadis, dan informasi perawi.

Seluruh koleksi tersedia secara offline. Pengguna tidak perlu mengunduh kitab satu per satu atau bergantung pada koneksi internet untuk membaca.

Saya ingin bagian ini menjadi fondasi utama aplikasi: membuka kitab, membaca hadis, dan menemukan referensi tanpa hambatan yang tidak perlu.

Pencarian Lintas Kitab

Sebelumnya, pengguna harus membuka kitab tertentu untuk mencari hadis. Sekarang, pencarian dapat dilakukan sekaligus dari seluruh 14 kitab.

Pengguna cukup memasukkan kata kunci seperti sabar, shalat malam, atau adab makan. Hasil pencarian akan menampilkan hadis yang relevan dari berbagai kitab.

Pencarian juga mendukung nomor hadis dan pemilihan beberapa kitab sekaligus.

Ini salah satu perubahan yang cukup penting bagi saya. Dengan koleksi puluhan ribu hadis, kemampuan menemukan referensi dengan cepat sama pentingnya dengan kemampuan membaca hadis itu sendiri.

Beberapa Hal Kecil yang Membuat Perbedaan

Tidak semua perubahan harus berupa fitur besar.

Saya menambahkan fitur Lanjutkan Membaca agar pengguna dapat kembali ke hadis terakhir yang dibuka. Ada juga fitur untuk menyimpan hadis pilihan sehingga lebih mudah ditemukan kembali.

Kemudian, saya membuat fitur Jelajah untuk mengelompokkan hadis berdasarkan tema seperti thaharah, shalat, puasa, zakat, dan haji.

Tujuannya sederhana. Tidak semua pengguna datang dengan kata kunci atau nomor hadis tertentu. Terkadang mereka hanya ingin membaca dan mempelajari hadis berdasarkan suatu pembahasan.

Alat Belajar

Di versi 4.0, saya juga mulai mengembangkan HadisKu menjadi lebih dari sekadar aplikasi untuk membaca hadis.

Ada beberapa alat baru:

Pembuat Kartu Hadis

Pengguna dapat membuat gambar dari hadis pilihan untuk dibagikan. Tersedia berbagai pilihan latar, termasuk ilustrasi yang dibuat menggunakan AI dan foto dari galeri perangkat.

Catatan Pribadi

Pengguna dapat menulis catatan dan menyertakan referensi hadis di dalamnya. Referensi tersebut dapat dibuka langsung untuk melihat hadis terkait.

Biografi Imam

Tersedia informasi singkat mengenai para imam hadis, termasuk perjalanan dan kitab yang mereka susun.

Ilmu Dasar Hadis

Saya menambahkan 38 istilah penting dalam ilmu hadis, seperti sanad, matan, mutawatir, ahad, shahih, hasan, dan dhaif.

Saya berharap bagian ini dapat membantu pengguna yang ingin mulai memahami ilmu hadis secara bertahap.

Menyesuaikan Pengalaman Membaca

Setiap orang memiliki kebiasaan membaca yang berbeda.

Karena itu, HadisKu 4.0 memberikan beberapa pilihan pengaturan:

Mode terang dan gelap.
Ukuran teks Arab dan terjemahan yang dapat diatur secara terpisah.
Pengaturan perataan teks.
Pilihan urutan teks Arab dan terjemahan.
Pengaturan tata letak kartu hadis.

Saya tidak ingin memaksakan satu cara membaca kepada semua pengguna.

Tetap Gratis dan Offline

Ada satu hal yang tidak berubah dari versi sebelumnya: HadisKu tetap gratis.

Tidak ada iklan, tidak ada kewajiban berlangganan, dan pengguna tidak perlu membuat akun untuk mengakses koleksi hadis.

Saya juga tetap mempertahankan pendekatan offline-first. Membaca hadis tidak seharusnya bergantung pada koneksi internet.

Pengembangan dan operasional aplikasi tentu membutuhkan biaya. Dukungan sukarela dari pengguna membantu menjaga keberlangsungan proyek ini. Namun, dukungan tersebut tidak menjadi syarat untuk menggunakan HadisKu.

Apa Selanjutnya?

HadisKu 4.0 merupakan fondasi baru untuk pengembangan berikutnya.

Masih ada beberapa hal yang ingin saya kerjakan, seperti sinkronisasi catatan, peningkatan pengalaman membaca, dan pengembangan pencarian berdasarkan sanad maupun perawi.

Namun, saya tidak ingin terburu-buru menambahkan fitur hanya demi memperbanyak daftar pembaruan.

Setiap fitur harus memiliki alasan yang jelas dan memberikan manfaat bagi pengguna.

Penutup

Membangun ulang aplikasi yang sudah berjalan selama ini bukan pekerjaan kecil. Ada banyak keputusan, perubahan, dan pekerjaan yang tidak selalu terlihat dari luar.

Namun, saya merasa keputusan untuk memulai kembali adalah langkah yang tepat untuk perjalanan HadisKu selanjutnya.

HadisKu 4.0 sudah tersedia di Google Play Store.

Unduh HadisKu

Semoga aplikasi ini dapat membantu lebih banyak orang membaca dan mempelajari hadis.

HadisKu dikembangkan sebagai bagian dari perjalanan pengembangan aplikasi independen.

KasirCepat 26.10.29: QRIS, Data Pelanggan, Utang, dan Perbandingan Stok

Cahyanudien Aziz Saputra — Mon, 02 Nov 2026 06:52:24 +0000

KasirCepat versi 26.10.29 menghadirkan beberapa fitur baru untuk membantu pengelolaan transaksi, pelanggan, dan persediaan barang. Pembaruan ini juga mencakup sejumlah perbaikan pada penggunaan keyboard, pemindai barcode, navigasi kasir, dan pengelolaan lisensi.

Pembayaran QRIS

Kini KasirCepat mendukung metode pembayaran QRIS. Pengguna dapat menyimpan gambar QRIS dan menampilkannya saat proses checkout.

Ketika QRIS ditampilkan, gambar dapat diketuk untuk membuka tampilan layar penuh. Dengan begitu, pelanggan lebih mudah memindai kode menggunakan aplikasi pembayaran mereka.

Data Pelanggan

KasirCepat kini menyediakan pengelolaan data pelanggan. Pengguna dapat menambahkan pelanggan baru, mengubah informasi, mengarsipkan data, serta mencari pelanggan berdasarkan nama atau nomor telepon.

Data pelanggan juga terintegrasi dengan fitur pencatatan utang.

Pencatatan Utang Pelanggan

Transaksi dengan metode pembayaran utang kini dapat dihubungkan dengan data pelanggan.

Pengguna dapat melihat jumlah utang yang belum dibayar untuk setiap pelanggan dan mencatat pembayaran langsung dari halaman utang. Riwayat ini membantu pemilik usaha memantau tagihan pelanggan tanpa harus mencatatnya secara terpisah.

Perbandingan Stok

Fitur Perbandingan Stok memungkinkan pengguna membandingkan jumlah persediaan antara dua tanggal, termasuk perubahan stok untuk setiap produk.

Tersedia dua mekanisme pencatatan:

Free: menggunakan snapshot stok yang dibuat secara manual.
Pro: snapshot stok dibuat secara otomatis setiap hari dengan penyimpanan riwayat hingga 12 bulan.

Dengan perbandingan ini, pengguna dapat melihat perubahan persediaan dalam periode tertentu dan mengetahui produk yang mengalami penambahan atau pengurangan stok.

Perbaikan dan Penyempurnaan

Selain fitur baru, versi ini juga membawa beberapa perbaikan:

Keyboard dan pemindai barcode: keyboard tetap dapat digunakan ketika pemindai barcode perangkat keras aktif. Input dengan rangkaian karakter cepat dikenali sebagai hasil pemindaian, sedangkan pengetikan normal tetap diteruskan ke keyboard.
Navigasi POS: tombol kembali kini menutup pencarian produk yang sedang aktif terlebih dahulu. Konfirmasi keluar hanya muncul ketika pencarian sudah tidak terbuka.
Keamanan perangkat: pemeriksaan keamanan kini memastikan PIN, pola, kata sandi, atau biometrik benar-benar telah didaftarkan, bukan sekadar memeriksa dukungan perangkat keras.
Pengelolaan lisensi: label "Hapus Lisensi" diubah menjadi "Cabut Lisensi" agar lebih sesuai dengan tindakan yang dilakukan. Animasi loading juga ditambahkan selama proses pencabutan lisensi berlangsung.
Pengingat kedaluwarsa lisensi: pengingat kini muncul setiap hari mulai lima hari sebelum lisensi berakhir hingga tanggal kedaluwarsa, termasuk ketika lisensi berakhir pada hari tersebut.

Perbarui KasirCepat

KasirCepat versi 26.10.29 tersedia melalui Google Play Store.

Unduh atau perbarui KasirCepat

Informasi lebih lanjut tentang KasirCepat: https://flagodna.com/kasir-cepat/

KasirCepat dikembangkan untuk membantu usaha mengelola transaksi dan persediaan dengan aplikasi kasir yang dapat digunakan tanpa langganan.

Setelah MTA Portal Dirilis, Apakah MTA ONE Akan Berhenti?

Cahyanudien Aziz Saputra — Wed, 28 Oct 2026 11:28:38 +0000

Ini bukan sekadar tulisan tentang aplikasi. Ini tentang kecewa, lelah, dan sesuatu yang selama ini saya rawat seorang diri. Saya perlu menceritakannya dengan jujur.

Pesan dari pembuat aplikasi

Assalamu’alaikum warahmatullahi wabarakatuh.

Saudara-saudaraku, saudara seiman, seagama, satu payung yang sama.

Perkenalkan, nama saya Cahyanudien Aziz Saputra. Saya pembuat aplikasi MTA ONE dan juga mengikuti kajian MTA di Kabupaten Sragen.

Tulisan ini adalah lanjutan dari tulisan saya sebelumnya, Di Balik MTA ONE & Brosur MTA: Tentang Niat, Salah Paham, dan Tetap Melangkah. Kalau Anda belum membacanya, saya sangat menyarankan untuk membaca bagian pertama terlebih dahulu. Di sana saya bercerita tentang awal mula aplikasi ini, kenapa saya membuatnya, dan kenapa pada Januari 2026 saya berniat menghibahkan MTA ONE dan Brosur MTA Lengkap kepada MTA secara gratis.

Pertama, saya ingin mengucapkan selamat datang.

Entah Anda mengikuti perjalanan MTA ONE sejak versi pertama sekitar tahun 2020, atau baru menggunakannya sampai versi 4 pada tahun 2026, saya mengucapkan terima kasih. Kita memiliki kebutuhan yang sama: ingin mengikuti kajian yang disiarkan MTA dengan lebih mudah melalui aplikasi di handphone.

Hari ini, 28 Oktober 2026, saya menulis tulisan ini setelah memikirkan banyak hal.

Ternyata cukup melelahkan mengelola aplikasi seorang diri, dengan unduhan yang sudah melewati 21 ribu. Kadang saya berhenti sebentar dan berpikir: ternyata sudah sejauh ini perjalanan kita.

Dari siaran radio yang tidak bersuara. Dari brosur mingguan yang terlambat saya perbarui. Dari alamat kajian yang datanya perlu diperbaiki. Dari MTA TV yang tidak menampilkan gambar.

Semua itu pernah terjadi. Semua itu saya hadapi dan coba perbaiki satu per satu.

Saya tidak menulis ini untuk menghitung jasa. Saya menulis karena selama ini ada banyak hal yang saya simpan sendiri, dan belakangan ini saya mulai merasa tidak nyaman untuk terus diam.

Kecewa.

Ya, mungkin itulah inti tulisan saya kali ini.

Saya kecewa. Saya lelah. Dan jujur, saya tidak tahu harus menjelaskan perasaan ini dengan kata apa lagi.

1. Apakah saya tidak dianggap ada?

MTA ONE mulai dirilis sekitar tahun 2020. Aplikasi ini kemudian diunduh dan digunakan oleh ribuan orang.

Saya tidak ingat persis tahun berapa, tetapi masih pada masa pandemi, ketika Silaturahim Ahad Pagi dilakukan secara daring, saya pernah dihubungi oleh almarhum Pak Rudi untuk ikut Zoom Ahad Pagi. Kami berbincang, dan saya mendapat kesempatan menjelaskan sedikit tentang aplikasi MTA ONE.

Lalu, mungkin sekitar tahun 2023 atau 2024, saya diundang ke Sekretariat MTA Pusat. Saat itu ada pembicaraan mengenai iklan yang muncul di MTA ONE. Beberapa pengguna mengeluhkan iklan pinjaman online. Pada waktu itu, kesimpulan pembicaraan yang saya ingat adalah aplikasi boleh diteruskan, tetapi iklan pinjaman online diminta untuk dihapus.

Saya tidak ingat siapa saja yang hadir dan tidak ingin mengarang detail yang sudah lupa. Yang jelas, setelah itu saya tetap melanjutkan aplikasi ini.

Kemudian pada Januari 2026, saya membuat proposal fisik. Isinya sederhana: saya ingin menghibahkan MTA ONE dan Brosur MTA Lengkap kepada MTA secara gratis.

Saya datang membawa dokumen, lalu bertemu dengan salah satu pihak di sekretariat. Setelah beberapa waktu, saya mengonfirmasi apakah proposal itu sudah disampaikan. Saya diberi tahu bahwa proposal tersebut sudah disampaikan dan sudah dibaca pimpinan pusat.

Lalu, apakah saya mendapat respons?

Tidak.

Benar-benar tidak ada respons yang memberikan kejelasan. Tidak ada jawaban bahwa proposal itu diterima. Tidak ada jawaban bahwa proposal itu ditolak. Tidak ada penjelasan apakah ada bagian yang perlu dibicarakan atau diperbaiki.

Beberapa minggu dan bulan berikutnya, saya menanyakan kelanjutannya melalui kontak yang saya miliki dan melalui email resmi MTA. Hasilnya sama: tidak ada jawaban yang menjelaskan apa keputusan mereka.

Saya memahami bahwa sebuah organisasi punya banyak urusan. Saya juga memahami bahwa proposal saya bukan satu-satunya hal yang harus dipikirkan. Namun, apakah sesibuk itu sampai tidak ada satu jawaban pun yang bisa diberikan selama berbulan-bulan?

Saya tidak sedang meminta agar proposal saya diterima. Saya hanya berharap ada jawaban.

Kalau ditolak, katakan ditolak. Saya bisa menerima itu dan melangkah. Kalau diterima, kita bisa membicarakan bagaimana menyerahkan aplikasi tersebut dengan baik. Tetapi kalau tidak ada jawaban sama sekali, apa yang harus saya lakukan?

Kalau Anda mengirim pesan singkat kepada seseorang dan berharap mendapat balasan, apakah Anda selalu menuntut agar jawabannya sesuai keinginan Anda? Tidak. Kadang kita hanya ingin tahu bahwa pesan itu dibaca dan dijawab dengan jelas.

Begitu pula dengan proposal saya.

Yang membuat saya kecewa bukan karena saya tidak mendapatkan apa yang saya inginkan. Yang membuat saya kecewa adalah tidak adanya kejelasan, padahal saya sudah berusaha menyampaikan niat saya secara langsung dan tertulis.

Rasanya seperti sudah mengulurkan sesuatu dengan dua tangan, tetapi dibiarkan tetap terulur tanpa tahu apakah akan diterima atau ditolak.

2. MTA Portal dirilis. Kenapa?

Sebelum melanjutkan, saya ingin mengingatkan Anda untuk membaca tulisan pertama. Saya pernah bercerita bahwa ketika MTA ONE mulai dikenal, ada anggapan bahwa saya bukan warga MTA, mencari keuntungan dari agama, menampilkan iklan yang mudarat, bahkan ada yang mengatakan warga MTA dilarang menggunakan MTA ONE.

Mengingat itu, saya masih bertanya-tanya: kenapa tidak tabayyun? Kenapa tidak bertanya langsung kepada saya? Kenapa menyimpulkan niat seseorang tanpa mencoba mencari penjelasan darinya?

Saya tidak habis pikir.

Pada awal Oktober 2026, MTA Portal dirilis. Jujur, awalnya saya kaget. Benar, ada aplikasi MTA Portal sekarang?

Dulu saya sempat bergabung dalam grup tim IT pusat, seingat saya sebelum tahun 2023. Saat itu salah satu hal yang dikerjakan adalah database warga. Saya belum punya pengalaman yang cukup dalam pengelolaan data, jadi saya tidak banyak membantu. Bidang saya lebih dekat dengan pengembangan aplikasi seluler.

Ketika MTA Portal dirilis, saya mencoba menggunakannya. Kesan pertama saya terus terang: kok begini? Menurut saya, ini belum siap untuk dirilis ke publik.

Saya tahu kalimat itu terdengar keras. Namun itulah kesan saya ketika mencoba aplikasi tersebut. Saya tidak ingin berpura-pura memberi penilaian yang lebih baik hanya karena aplikasi itu diterbitkan oleh organisasi yang sama-sama saya ikuti.

Kalau Anda mengikuti perkembangan MTA ONE, beberapa fitur yang ada di MTA Portal bukan hal baru bagi saya. MTA TV, radio online, brosur, rekaman pengajian dalam enam kategori, Al-Qur’an, tanggal Hijriah, jadwal salat, alamat kajian, dan kabar MTA—semua itu sudah pernah ada di MTA ONE. Kebutuhan-kebutuhan tersebut juga tercantum dalam proposal yang saya ajukan pada Januari lalu.

Saya tidak sedang menuduh bahwa MTA Portal dibuat berdasarkan proposal saya. Saya tidak memiliki bukti untuk menyimpulkan itu. Tetapi urutan peristiwa ini tetap sulit saya abaikan: proposal saya tidak mendapat jawaban yang jelas, sementara beberapa kebutuhan yang saya tawarkan untuk diserahkan kemudian muncul dalam aplikasi resmi.

Sekarang, coba tempatkan diri Anda pada posisi saya.

Saya datang dengan niat menyerahkan aplikasi yang sudah saya buat dan rawat. Saya tidak menawarkan penjualan. Saya tidak menawarkan kerja sama bisnis. Saya ingin menghibahkannya secara gratis. Saya menunggu jawaban selama berbulan-bulan. Tidak ada jawaban yang jelas.

Lalu sebuah aplikasi resmi dirilis, dengan sejumlah fitur yang selama ini juga saya kembangkan dan tawarkan untuk diserahkan.

Bagaimana seharusnya saya merasa?

Bayangkan Anda ingin memberikan sesuatu kepada orang lain. Tangan Anda sudah terulur di depan orang itu. Yang Anda tunggu bukan harus tangan yang menerima—kalau ditolak pun Anda bisa memahami. Yang Anda tunggu setidaknya adalah respons. Tetapi tidak ada jawaban. Lalu suatu hari, di depan Anda, orang itu menjulurkan tangan dengan membawa sesuatu yang serupa.

Apakah Anda memahami maksud saya?

Saya senang MTA akhirnya mempunyai aplikasi sendiri. Saya benar-benar senang jika MTA bisa mengembangkan layanan digitalnya sendiri dan mengelolanya secara langsung. Tetapi senang melihat aplikasi resmi hadir tidak otomatis menghapus kekecewaan saya terhadap hal yang terjadi sebelumnya.

Dua hal itu bisa benar pada saat yang sama.

Saya mendukung adanya aplikasi resmi. Saya juga kecewa karena proposal saya dibiarkan tanpa kejelasan, sementara sejumlah kebutuhan yang saya usahakan kemudian muncul dalam aplikasi resmi.

Tentang pengalaman menggunakan MTA Portal

Ada persoalan lain yang ingin saya sampaikan: pengalaman teknis saat mencoba MTA Portal.

Ketika membuka halaman awal, saya melihat sejumlah permintaan jaringan untuk data yang tampaknya tidak semuanya diperlukan saat itu juga. Berikut sebagian catatan dari satu sesi pengujian saya:

16:43:45 HTTPS GET  qrsarmta.cloud /absensimta/api/v1/radio/integrity/nonce
           200 application/json 181 B 53 ms

16:43:45 HTTPS GET  api.mta.or.id /api/v1/perwakilan?limit=300
           200 application/json 18.7 KB 1.43 s

16:43:45 HTTPS GET  api.mta.or.id /api/v1/binaan?limit=1000&page=1&status=1
           200 application/json 3.8 KB 183 ms

16:43:45 HTTPS POST adapter-pa.googleapis.com /play.gateway.adapter.phonesky.BrowseService/GetItems
           200 application/grpc 1.5 KB 339 ms

16:43:46 HTTPS GET  api.mta.or.id /api/v1/majlis-pusat
           200 application/json 248 B 81 ms

16:43:46 HTTPS GET  api.myquran.com /v2/sholat/kota/cari/Kab.%20Aceh%20Jaya
           200 application/json 164 B 216 ms

16:43:46 HTTPS GET  api.mta.or.id /api/v1/cabang?limit=1000&page=1
           200 application/json 80.2 KB 4.90 s

16:43:46 HTTPS GET  api.myquran.com /v2/sholat/kota/cari/Darul%20Hikmah
           200 application/json 140 B 217 ms

16:43:46 HTTPS GET  api.myquran.com /v2/sholat/kota/cari/Kec.%20Darul%20Hikmah%20%C2%B7%20Kab.%20Aceh%20Jaya
           200 application/json 188 B 179 ms

16:43:46 HTTPS GET  play.google.com /store/apps/details?id=id.mta.portal&hl=id
           200 text/html 170 KB 274 ms

16:43:49 HTTPS POST qrsarmta.cloud /absensimta/api/v1/radio/token
           403 application/json 45 B 64 ms

16:43:51 HTTPS GET  lh.googleusercontent.com /...rw-w28-h28-v1-e15
           200 image/webp 384 B 73 ms

16:43:51 HTTPS GET  lh.googleusercontent.com /...rw-w112-h112-v1
           200 image/webp 2.1 KB 74 ms

16:43:53 HTTPS GET  qrsarmta.cloud /absensimta/api/v1/radio/integrity/nonce
           200 application/json 181 B 49 ms

16:43:56 HTTPS POST qrsarmta.cloud /absensimta/api/v1/radio/token
           403 application/json 45 B 50 ms

16:43:58 HTTPS GET  qrsarmta.cloud /absensimta/api/v1/radio/integrity/nonce
           200 application/json 181 B 46 ms

Ini bukan benchmark resmi. Ini catatan dari pengujian saya sendiri, pada perangkat dan koneksi yang saya gunakan. Namun, dari sini terlihat bahwa aplikasi meminta data cabang dalam jumlah besar, termasuk permintaan dengan waktu tunggu hampir lima detik dalam sesi tersebut.

Pertanyaan saya: apakah data sebanyak itu memang perlu dimuat ketika pengguna baru membuka halaman depan? Mengapa data dari fitur yang belum tentu dibuka harus ikut diminta sejak awal?

Setiap permintaan jaringan memiliki biaya: kuota, waktu tunggu, dan pekerjaan tambahan untuk perangkat. Dampaknya tentu berbeda antara perangkat dan jaringan. Tetapi bagi pengguna dengan handphone yang terbatas atau koneksi yang lambat, cara aplikasi mengambil data bukan hal sepele.

Menurut saya, aplikasi yang dibuat untuk memudahkan warga seharusnya juga memperhatikan hal-hal seperti ini. Fitur banyak saja tidak cukup. Cara fitur itu disajikan juga menentukan apakah aplikasi benar-benar nyaman digunakan.

Saya menyampaikan ini karena saya melihatnya dan mengujinya sendiri. Bukan untuk mengejek pembuatnya. Saya berharap aplikasi itu diperbaiki.

3. Kenapa radio online MTA sekarang seperti eksklusif?

Bagian ini yang paling membuat saya lelah selama beberapa minggu terakhir.

Sejak MTA Portal dirilis, radio online MTA tidak lagi dapat diakses secara publik melalui jalur pihak ketiga seperti sebelumnya. Dari pengujian saya, aksesnya sekarang dibatasi melalui mekanisme yang digunakan oleh layanan resmi MTA, termasuk situs MTA dan aplikasi MTA Portal. Akibatnya, MTA ONE tidak lagi bisa ikut menyebarkan siaran radio tersebut dengan cara yang sama.

Saya ulangi: radio online MTA sekarang terasa eksklusif untuk jalur resmi MTA. Orang yang ingin mendengarkannya melalui aplikasi lain, atau membantu menyebarkannya lewat aggregator radio, ikut terdampak. Ini bukan persoalan kecil bagi saya. Inilah yang membuat fitur radio di MTA ONE berulang kali berhenti berjalan.

Pertanyaan saya: bukankah radio online dibuat agar bisa didengarkan melalui internet? Kenapa sekarang orang yang ingin mendengarkan harus melewati jalur tertentu saja?

Sekarang ada banyak aggregator radio online. Mereka mengumpulkan siaran dari berbagai tempat agar orang lebih mudah menemukan dan mendengarkannya. Saya mengambil contoh urfan.id. Saya tidak kenal pembuatnya. Dari yang saya lihat, ia berusaha me-relay siaran radio online MTA agar bisa didengarkan melalui situsnya.

Dengan mekanisme akses yang sekarang saya temui, apakah layanan seperti itu masih bisa memutar radio MTA?

Saya tidak mengatakan pemilik radio tidak boleh mengelola layanan miliknya. Tentu mereka punya kewenangan atas infrastrukturnya. Tetapi kalau akhirnya hanya layanan resmi yang bisa mengakses siaran, maka jangkauan radio itu ikut ditentukan oleh keputusan tersebut.

Apakah eksklusivitas seperti ini lebih penting daripada membuat siaran dapat didengar lebih banyak orang?

Saya sungguh tidak memahami pertimbangannya.

Apa yang saya temukan secara teknis

Bagi Anda yang berkecimpung di bidang IT, saya jelaskan berdasarkan pengujian yang saya lakukan.

Pada akses radio yang saya amati, terdapat pemeriksaan melalui layanan qrsarmta.cloud, termasuk endpoint radio/integrity/nonce dan radio/token. Saya juga menemukan permintaan ke layanan Google Play Integrity melalui aplikasi MTA Portal.

Google Play Integrity adalah layanan untuk membantu pengembang memeriksa integritas aplikasi dan perangkat, lalu menggunakan hasil pemeriksaan itu untuk mengambil keputusan di sisi server. Teknologi semacam ini mempunyai kegunaan, misalnya untuk keamanan aplikasi dan mencegah penyalahgunaan layanan.

Yang membuat saya bertanya-tanya adalah konteks penggunaannya di sini: pemeriksaan tersebut tampak menjadi bagian dari mekanisme untuk mendapatkan akses radio. Artinya, mendengarkan radio tidak lagi hanya soal memiliki alamat siaran dan koneksi internet; ada pemeriksaan tambahan yang harus dilewati sebelum akses diberikan.

Saya juga mengamati bahwa situs radio melakukan permintaan yang berulang dalam interval tertentu. Dari lalu lintas jaringan, terlihat adanya akses ke layanan menggunakan koneksi pengguna dan informasi yang secara teknis tersedia dalam komunikasi web, seperti alamat IP dan jenis browser. Saya tidak memiliki akses ke kode server, sehingga saya tidak bisa memastikan seluruh data yang disimpan, berapa lama data dipertahankan, atau bagaimana data itu digunakan. Tetapi mekanisme pemeriksaan akses tersebut cukup terlihat dari pengujian yang saya lakukan.

Saya ingin mengajukan pertanyaan secara langsung: untuk apa pembatasan seketat itu diperlukan dalam konteks mendengarkan radio dakwah?

Teknologi Play Integrity tidak salah. Teknologi ini juga bukan hanya untuk perbankan. Tetapi ketika pemeriksaan integritas menjadi syarat akses radio, dampaknya nyata: layanan pihak ketiga kesulitan ikut menyebarkan siaran. Pertanyaan saya tetap sama: mengapa akses radio dakwah harus dibuat seperti ini?

YouTube saja memiliki berbagai cara untuk membuat konten dapat ditonton dan dibagikan, sementara akses radio ini justru terasa semakin tertutup. Saya tidak sedang menyamakan seluruh sistem teknis keduanya. Saya sedang mempertanyakan prioritasnya: apakah pembatasan akses ini benar-benar lebih bermanfaat daripada memudahkan lebih banyak orang untuk mendengarkan?

Ini radio dakwah. Saya kira tujuan utamanya adalah agar orang dapat mendengarkan kajian.

Saya tidak ingin terus bermain kucing dan tikus

Sebenarnya saya masih bisa mencoba menambal MTA ONE agar radio tetap dapat diputar. Saya sudah melakukan beberapa percobaan. Ada cara yang sempat berhasil, tetapi kemudian akses berubah dan cara itu tidak lagi berjalan.

Lalu saya mencoba lagi. Setelah itu berubah lagi.

Sampai kapan?

Saya hanya ingin ikut menyebarkan siaran radio MTA. Tetapi yang saya hadapi sekarang seperti permainan kucing dan tikus: setiap kali saya menemukan jalan, jalan itu berubah lagi. Saya harus memeriksa ulang, menulis kode lagi, menguji lagi, dan mengeluarkan waktu untuk masalah yang tidak saya kendalikan.

Saya tidak ingin terus mengejar mekanisme akses yang sengaja atau secara teknis membatasi layanan pihak ketiga. Kalau pemilik layanan memutuskan bahwa radio hanya boleh diakses melalui jalur resmi mereka, saya harus menerima kenyataan bahwa saya tidak bisa menjamin fitur radio di MTA ONE akan tetap berjalan.

Tetapi saya tetap ingin bertanya: mengapa radio online dakwah MTA harus se-eksklusif ini?

Ada orang yang memotong video pendek pengajian lalu mengunggahnya ke media sosial. Ada orang yang membagikan rekaman kajian. Ada pihak yang berusaha memperluas jangkauan dakwah melalui caranya sendiri. Mengapa untuk radio online justru terasa berbeda?

Saya tidak sedang meminta akses khusus untuk diri saya. Saya ingin pendengar yang menggunakan MTA ONE tetap bisa mendengarkan radio sebagaimana sebelumnya.

Waw. Ternyata mempertahankan sebuah fitur yang tujuannya sederhana bisa menjadi serumit ini.

4. Tuduhan itu ditujukan kepada siapa?

Saya ingin mengajak Anda membaca artikel di situs resmi MTA tentang peluncuran MTA Portal: MTA Resmi Luncurkan Aplikasi MTA PORTAL.

Di sana terdapat kalimat berikut:

“Aplikasi ini diterbitkan untuk digunakan seluruh warga atau simpatisan MTA untuk memudahkan dalam mengaji dan agar warga tidak terkecoh karena adanya pihak-pihak tertentu yang memanfaatkan untuk mencari keuntungan pribadi dengan membuat aplikasi dengan nama MTA.”

Saya ingin bertanya kepada Anda yang membaca tulisan ini: siapa yang dimaksud dengan “pihak-pihak tertentu” yang mencari keuntungan pribadi itu? Aplikasi apa yang dimaksud? Siapa pembuatnya?

Tulisan tersebut tidak menyebut nama. Karena itu, saya tidak akan mengarang nama atau mengklaim tahu pasti siapa yang dimaksud. Tetapi saya juga tidak bisa berpura-pura bahwa kalimat tersebut tidak punya dampak terhadap orang yang membuat aplikasi dengan nama MTA.

Sebelumnya saya sudah pernah mendengar tuduhan bahwa saya bukan warga MTA, mencari keuntungan dari agama, dan membuat aplikasi yang tidak semestinya digunakan. Sekarang, di situs resmi, muncul pernyataan tentang pihak tertentu yang mencari keuntungan pribadi melalui aplikasi dengan nama MTA.

Menurut Anda, bagaimana saya harus membacanya?

Saya merasa kecewa. Sangat kecewa.

Saya membuat MTA ONE karena saya sendiri membutuhkan cara yang lebih mudah untuk mengikuti kajian. Saya belajar coding dari nol. Saya merawat aplikasi ini bertahun-tahun. Saya menanggung biaya dan waktu sendiri. Pada Januari 2026, saya datang membawa proposal untuk menghibahkan MTA ONE dan Brosur MTA Lengkap secara gratis kepada MTA.

Saya tidak meminta MTA membeli aplikasi saya. Saya tidak meminta keuntungan dari pengalihan aplikasi tersebut. Saya justru menawarkan untuk menyerahkannya.

Lalu proposal itu tidak mendapat jawaban yang jelas, dan sekarang saya membaca pernyataan seperti itu di situs resmi.

Bagaimana saya tidak kecewa?

Kalau memang ada masalah dengan aplikasi pihak ketiga, sebutkan dengan jelas persoalannya. Kalau ada pembuat aplikasi yang dianggap mengambil keuntungan pribadi, jelaskan hal yang menjadi dasar pernyataan tersebut. Jangan membuat kalimat yang luas, lalu membiarkan orang-orang menebak siapa yang dimaksud.

Saya tidak punya dasar untuk menyatakan bahwa saya adalah sasaran kalimat itu. Tetapi kalimat tersebut terbit di ruang publik, tidak menyebut nama, dan muncul setelah riwayat yang saya ceritakan di atas. Dampaknya nyata: orang yang membaca bisa menghubungkannya dengan aplikasi seperti MTA ONE, sementara pihak yang dimaksud tidak pernah dijelaskan secara terang.

Saya berharap persoalan seperti ini diselesaikan dengan tabayyun dan komunikasi langsung, bukan dengan kalimat yang membuat pembaca menafsirkan sendiri.

Saya tidak meminta dipuji. Saya tidak meminta perlakuan istimewa. Saya hanya ingin niat saya tidak disimpulkan secara sepihak.

Bukankah itu hal yang wajar?

5. Lalu, apa akhirnya?

Jujur, saya lelah.

Selama kira-kira dua minggu terakhir, saya banyak menghabiskan waktu untuk mencari cara agar radio MTA tetap bisa didengarkan melalui MTA ONE. Saya mencoba patch, membuat relay radio seperti pendekatan yang saya lihat di layanan lain, sampai mencoba mengambil sumber siaran melalui YouTube.

Apakah semuanya berjalan?

Tidak.

Ada yang berhasil sebentar lalu berhenti. Ada cara yang membutuhkan biaya tambahan. Ada kemungkinan saya harus terus mengubah kode ketika mekanisme akses berubah, atau mengeluarkan biaya untuk menjalankan relay sendiri tanpa kepastian bahwa cara itu akan bertahan.

Saya sampai bertanya pada diri sendiri: apakah saya harus mengeluarkan lebih banyak uang setiap bulan hanya agar orang-orang masih bisa mendengarkan radio MTA melalui aplikasi saya? Apakah saya harus terus mengubah kode setiap kali akses berubah? Apakah saya harus menghabiskan waktu untuk mengejar mekanisme yang tidak saya kendalikan?

Apakah itu sepadan?

Saya sudah menulis di bagian pertama bahwa saya ingin sedikit lebih santai. Saya ingin tetap mengembangkan aplikasi, tetapi tidak ingin semua hal harus saya pikul sendirian.

Namun, ketika radio tidak lagi dapat diakses, saya merasa tanggung jawab saya sebagai pembuat aplikasi belum selesai. Ada ribuan orang yang menggunakan MTA ONE. Mereka tidak tahu bahwa di balik layar saya sedang mencoba berbagai cara, membaca lalu lintas jaringan, memperbaiki kode, dan menguji ulang hanya agar sebuah fitur bisa bekerja lagi.

Itulah kenapa dua minggu terakhir saya terus mencoba.

Tetapi sepertinya sudah cukup.

Saya ingin berhenti mengejar perubahan akses radio ini. Versi 4.0.9 sepertinya sudah cukup untuk menandai batas usaha saya saat ini. Saya tidak bisa menjamin radio akan terus berjalan normal, sebab jalur aksesnya tidak berada dalam kendali saya.

Saya tidak ingin menulis seolah-olah semuanya baik-baik saja. Saya sudah berusaha. Saya sudah mencoba beberapa pendekatan. Saya sudah menghabiskan waktu untuk mencari jalan keluar. Dan saya mulai menyadari bahwa saya tidak bisa terus mengorbankan waktu, tenaga, dan biaya tanpa kepastian.

Jadi, apakah MTA ONE akan berhenti?

Saya belum mengatakan bahwa MTA ONE akan langsung ditutup. Aplikasi ini masih memiliki fitur lain dan masih digunakan orang untuk kebutuhan mereka.

Tetapi saya juga tidak bisa menjanjikan bahwa MTA ONE akan terus berjalan seperti sebelumnya. Khususnya untuk radio online, saya tidak ingin terus menjanjikan perbaikan yang pada akhirnya bergantung pada layanan milik pihak lain.

Saya harus mengerem.

Bukan karena saya tidak peduli kepada pengguna. Justru karena saya peduli, selama dua minggu ini saya berusaha mencari solusi. Tetapi kepedulian tidak berarti saya harus terus memaksakan diri tanpa batas.

Untuk Anda yang selama ini menggunakan MTA ONE, saya ingin mengucapkan terima kasih. Terima kasih sudah menggunakan aplikasi ini, memberi saran, mengirim masukan, memberi ulasan, dan ikut menyebarkannya.

Dan saya benar-benar minta maaf.

Saya ulangi: saya benar-benar minta maaf karena tidak bisa menjamin aplikasi ini terus berjalan normal, terutama untuk radio online. Saya tidak mengenal sebagian besar dari Anda. Tetapi setiap hari, ada ribuan orang yang menggunakan aplikasi ini untuk mendengarkan kajian dan mengakses kebutuhan MTA dengan lebih mudah.

Saya tahu ada orang yang hanya ingin membuka aplikasi, menekan tombol radio, lalu mendengarkan. Mereka tidak seharusnya harus memikirkan semua persoalan yang saya ceritakan di sini.

Saya minta maaf karena sekarang saya harus mengakui bahwa ada bagian dari aplikasi ini yang tidak lagi bisa saya jaga sendirian.

Saya hanya ingin menepi sebentar

Saya senang MTA membuat aplikasi resmi. Saya berharap MTA Portal benar-benar diperbaiki dan dapat membantu warga serta simpatisan MTA. Saya tidak menganggap keberadaan aplikasi resmi sebagai masalah dengan sendirinya.

Tetapi saya juga tidak bisa menghapus cerita yang terjadi di baliknya: proposal yang saya ajukan tidak mendapat jawaban yang jelas, radio online yang sekarang sulit diakses melalui aplikasi lain, dan pernyataan di situs resmi yang membuat saya bertanya-tanya bagaimana pembaca akan menilai pembuat aplikasi seperti saya.

Saya sudah berusaha menjelaskan. Saya sudah mencoba memperbaiki. Saya sudah mencoba mencari jalan keluar.

Saya kecewa karena komunikasi yang sederhana saja tidak saya dapatkan. Saya lelah karena harus terus berusaha mempertahankan fitur yang aksesnya tidak saya kendalikan. Dan saya sedih karena sesuatu yang saya rawat selama bertahun-tahun sekarang membuat saya harus bertanya apakah masih masuk akal untuk terus berjuang dengan cara yang sama.

Saya tidak menulis ini agar orang membenci MTA Portal atau menyalahkan pengguna aplikasi resmi. Pengguna tidak bersalah. Mereka hanya memakai aplikasi yang tersedia untuk mengikuti kajian.

Saya menulis karena saya juga perlu didengar. Saya ingin orang tahu bahwa di balik sebuah aplikasi ada orang yang mengerjakannya, ada waktu yang dihabiskan, ada biaya yang dibayar, dan ada perasaan yang tidak selalu bisa disimpan sendiri.

MTA ONE mungkin masih akan saya rawat. Saya mungkin masih akan mengembangkan aplikasi lain. Tetapi untuk persoalan radio ini, saya ingin berhenti sebentar.

Saya hanya ingin menepi.

Terima kasih sudah membaca sampai akhir.

Wassalamu’alaikum warahmatullahi wabarakatuh.

Salam hangat dari pembuat aplikasi MTA ONE,

Cahyanudien Aziz Saputra

MTA ONE 4.0.8: Membangun Pemutar MTA TV Native

Cahyanudien Aziz Saputra — Wed, 14 Oct 2026 16:15:16 +0000

Perubahan pengalaman menonton MTA TV, pemutaran audio, dan upaya membangun aplikasi yang dapat diandalkan dalam jangka panjang.

14 Oktober 2026 · Cahyanudien Aziz Saputra

Beberapa versi terakhir MTA ONE saya gunakan untuk memperbaiki pengalaman pemutaran radio online. Pada versi 4.0.8, pengembangan berlanjut ke bagian lain: pemutar MTA TV.

Sebelumnya, pengalaman menonton MTA TV masih mengandalkan WebView. Kali ini, saya mengembangkan pemutar video native yang terintegrasi langsung dengan aplikasi, lengkap dengan pilihan kualitas video, rotasi layar, dan mode layar penuh.

Saya juga menambahkan pemutaran audio MTA TV serta memperbarui pemutar audio rekaman.

Bagi saya, perubahan ini bukan sekadar mengganti pemutar video. Ada hal yang lebih penting dalam pengembangan aplikasi: bagaimana membuat fitur yang benar-benar berguna bagi pengguna sekaligus menjaga agar aplikasi dapat terus dikembangkan dalam jangka panjang.

Dari WebView ke Pemutar Native

WebView merupakan cara praktis untuk menampilkan konten web di dalam aplikasi. Namun, untuk pengalaman menonton MTA TV, saya ingin kontrol pemutaran yang lebih terintegrasi dengan aplikasi itu sendiri.

Karena itu, pada versi 4.0.8, saya menghadirkan pemutar video native untuk MTA TV.

Kontrol pemutaran dirancang agar tidak terus memenuhi layar. Saat video diputar, kontrol akan menghilang sehingga pengguna dapat fokus pada siaran. Ketika layar disentuh, kontrol akan muncul kembali.

Saya juga menambahkan pilihan kualitas video agar pengguna dapat menyesuaikan pemutaran dengan kondisi koneksi internet yang tersedia.

Untuk pengalaman menonton yang lebih nyaman, pengguna dapat beralih antara orientasi potret dan lanskap dengan satu sentuhan. Mode lanskap menggunakan tampilan layar penuh.

Tujuannya sederhana: membuat pengalaman menonton MTA TV terasa sebagai bagian dari MTA ONE, bukan sekadar halaman web yang dibuka dari dalam aplikasi.

Mendengarkan Siaran Tanpa Menonton Video

Ada situasi ketika pengguna ingin mengikuti siaran tanpa harus terus menatap layar. Karena itu, saya juga menghadirkan pemutaran audio MTA TV secara langsung di dalam aplikasi.

Pengguna dapat memilih untuk menonton video atau mendengarkan audionya sesuai kebutuhan.

Pemutar audio untuk rekaman juga mendapatkan pembaruan. Saya menambahkan tampilan layar penuh, sampul audio yang lebih besar, animasi gelombang audio, bilah pengaturan posisi pemutaran, serta tombol untuk mundur dan maju 10 detik.

Kontrol tersebut berguna ketika pengguna ingin mengulang bagian tertentu atau melewati bagian rekaman tanpa harus mencari posisi secara manual.

Bagi saya, hal-hal seperti ini merupakan bagian dari pengalaman penggunaan sehari-hari. Fitur tidak harus besar untuk menjadi berguna; yang penting adalah apakah fitur tersebut benar-benar mempermudah aktivitas pengguna.

Perbaikan Radio dan Pengalaman Pemutaran

Pengembangan pemutar MTA TV bukan satu-satunya pekerjaan dalam beberapa versi terakhir.

Pada versi 4.0.5, saya mulai mencoba pendekatan pengelolaan stream radio yang lebih dinamis. Versi 4.0.6 melanjutkan pendekatan tersebut, kemudian versi 4.0.7 membawa pengembangan lebih lanjut untuk pengelolaan stream dan penanganan pemutaran audio.

Proses tersebut menjadi bagian dari upaya memperbaiki pengalaman radio online yang sebelumnya mengalami masalah pemutaran.

Pada versi 4.0.8, perhatian terhadap kondisi ketika terjadi gangguan juga diterapkan pada pengalaman pemutar yang baru. Tampilan pemuatan dan kesalahan dibuat lebih jelas, disertai pilihan Coba lagi dan Sambung ulang.

Tentu saja, tidak semua gangguan dapat diselesaikan oleh aplikasi. Koneksi internet yang tidak stabil atau sumber siaran yang sedang tidak tersedia tetap dapat memengaruhi pemutaran.

Namun, aplikasi perlu memberikan respons yang jelas ketika kondisi tersebut terjadi, bukan membiarkan pengguna menghadapi layar yang tidak menjelaskan apa yang sedang berlangsung atau tindakan apa yang bisa dilakukan berikutnya.

Stabilitas Tidak Berhenti pada Satu Rilis

Sebuah fitur tidak cukup hanya berfungsi ketika pertama kali dirilis. Fitur tersebut juga harus tetap dapat dipelihara ketika kebutuhan berubah, layanan pendukung mengalami perubahan, atau aplikasi mendapatkan pembaruan berikutnya.

Hal ini menjadi semakin penting untuk fitur yang bergantung pada layanan eksternal, seperti siaran langsung. Informasi stream dapat berubah atau kedaluwarsa, sementara kondisi layanan di luar aplikasi tidak selalu dapat dikendalikan sepenuhnya.

Karena itu, saya tidak ingin pemutar MTA TV hanya bergantung pada konfigurasi yang ditanamkan secara permanen di dalam aplikasi.

Pemutar native dirancang untuk memperoleh informasi pemutaran dari server, termasuk stream yang tersedia, pilihan kualitas video, dan pengaturan pemutar. Dengan pendekatan ini, aplikasi dapat menggunakan konfigurasi yang disediakan layanan saat pengguna membuka pemutar.

Jika informasi stream tidak lagi dapat digunakan, aplikasi dapat mencoba mengambil informasi pemutaran yang baru. Apabila jalur pemutaran native tetap tidak dapat digunakan, tersedia mekanisme untuk kembali ke pengalaman siaran berbasis web.

Bagi pengguna, yang penting bukan bagaimana informasi tersebut dipertukarkan antara aplikasi dan server. Yang penting adalah aplikasi memiliki mekanisme untuk menangani kondisi ketika pemutaran utama tidak tersedia.

Di sisi pengembangan, pendekatan ini membutuhkan kontrak yang jelas antara aplikasi dan layanan server. Keduanya perlu memiliki kesepakatan mengenai struktur informasi, perilaku yang diharapkan, dan cara perubahan dilakukan tanpa merusak kompatibilitas.

Perubahan pada layanan tidak seharusnya sembarangan mengubah arti informasi yang sudah digunakan oleh aplikasi. Informasi baru juga perlu dirancang agar aplikasi yang belum mengenalnya tetap dapat berfungsi dengan benar.

Ini bukan berarti gangguan akan selalu dapat dihindari. Namun, sistem dengan batasan dan mekanisme pemulihan yang jelas akan lebih siap menghadapi perubahan dibandingkan sistem yang hanya mengandalkan kondisi ideal.

Bagi saya, inilah bagian penting dari pengembangan jangka panjang: bukan hanya membuat sesuatu bekerja hari ini, tetapi juga memikirkan bagaimana menjaganya tetap dapat digunakan dan dikembangkan pada masa mendatang.

Apa yang Berubah pada MTA ONE 4.0.8?

Fitur baru

Pemutar video MTA TV native yang terintegrasi dengan aplikasi.
Pilihan kualitas video sesuai stream yang tersedia.
Peralihan orientasi potret dan lanskap dengan satu sentuhan.
Mode layar penuh untuk menonton dalam orientasi lanskap.
Pemutaran audio siaran langsung MTA TV.
Pemutar audio rekaman dengan tampilan layar penuh, sampul lebih besar, animasi gelombang audio, bilah pemutaran, serta tombol mundur dan maju 10 detik.

Peningkatan

Tampilan pemuatan dan kesalahan pemutaran yang lebih jelas.
Pilihan Coba lagi dan Sambung ulang ketika terjadi gangguan siaran.

Melanjutkan Pengembangan

Saya ingin MTA ONE terus berkembang berdasarkan kebutuhan penggunaan yang nyata. Bukan sekadar menambah fitur demi membuat daftar pembaruan terlihat panjang, tetapi memperbaiki pengalaman yang sudah ada dan menjaga agar fitur tersebut tetap dapat diandalkan.

Versi 4.0.8 membawa perubahan yang cukup berarti pada pengalaman menonton dan mendengarkan siaran. Namun, pekerjaan pengembangan tidak berhenti pada rilis ini.

Masih ada hal-hal yang perlu diuji, dievaluasi, dan diperbaiki seiring penggunaan aplikasi dan perubahan layanan pendukungnya.

Bagi saya, membangun aplikasi bukan hanya tentang menyelesaikan fitur. Ini juga tentang mengambil keputusan yang tepat agar aplikasi dapat terus dikembangkan tanpa mengabaikan stabilitas dan kebutuhan penggunanya.

Coba MTA ONE

MTA ONE dikembangkan untuk memudahkan akses ke MTA TV, radio online, rekaman audio, brosur mingguan, jadwal salat, dan berbagai informasi MTA dalam satu aplikasi.

Jika ingin mengenal MTA ONE lebih jauh dan melihat informasi lengkap mengenai fitur-fiturnya, kunjungi halaman berikut:

Lihat MTA ONE dan unduh aplikasinya secara gratis →

Cahyanudien Aziz Saputra — pengembang independen di balik FlagoDNA.

MTA ONE v4.0.8 · 14 Oktober 2026

I Missed Flutter's debugPrint After Moving to Kotlin

Cahyanudien Aziz Saputra — Fri, 02 Oct 2026 16:35:56 +0000

For more than three years, Flutter was my main environment for building applications.

Recently, I started working on several new projects with Kotlin and Jetpack Compose.

There was no dramatic problem.

Kotlin was fine. Android's tooling was fine. And Android already had a perfectly capable logging API.

But there was one small thing that kept bothering me.

Logging felt unnecessarily repetitive.

In Flutter, I could simply write:

debugPrint('User loaded: $user');

In Kotlin, the equivalent usually looks more like:

Log.d("MainActivity", "User loaded: $user")

Of course, this is not a serious problem.

It's a few extra characters.

But when you write something dozens or hundreds of times during development, these tiny decisions start becoming part of your workflow.

I kept thinking:

I don't need another logging framework. I just want the convenience I was used to.

So I built one.

GitHub: https://github.com/cas8398/debugprint

Maven Central: https://central.sonatype.com/artifact/com.flagodna/debugprint

Not another logging framework

The first mistake would have been trying to build a "better Android logging framework."

I wasn't interested in that.

Android already has Logcat, and there are plenty of mature logging libraries for applications that need structured logging, persistence, remote logging, crash reporting, or sophisticated filtering.

That wasn't the problem I was trying to solve.

I wanted something much smaller:

debugPrint.d("Loading user...")

That's it.

A tiny convenience layer for development-time logging.

That became debugprint.

The basic idea

The API is intentionally close to the mental model I had from Flutter.

debugPrint.d("Hello")
debugPrint.i("User signed in")
debugPrint.w("Cache miss")
debugPrint.e("Request failed")
debugPrint.v("Verbose information")

Custom tags are still possible when I actually care about them:

debugPrint.d("Auth", "Token expired")
debugPrint.e("Database", "Query failed")

The library is not trying to hide Android's logging system.

It simply removes some of the repetitive parts that I don't always need while developing.

Debug means debug

One thing I wanted from the beginning was for the library to behave like its name suggests.

If I'm using it for development debugging, I don't want to manually write this everywhere:

if (BuildConfig.DEBUG) {
    Log.d(...)
}

So debugprint automatically enables logging for debug builds and disables it for release builds.

The intended workflow is simply:

Debug build   → logging enabled
Release build → logging disabled

No initialization call.

No Application setup.

No configuration boilerplate.

Add the dependency and use it.

implementation("com.flagodna:debugprint:0.1.1")

The package is available on Maven Central:

https://central.sonatype.com/artifact/com.flagodna/debugprint

Automatic caller information

Another thing I found repetitive was tags.

When debugging something locally, I often don't really care about creating a meaningful logging category for every single message.

I mostly care about:

Where did this message come from?

So debugprint can derive the tag from the caller.

Instead of:

Log.d("SomeClass", "Loading...")

you can simply write:

debugPrint.d("Loading...")

and get caller information such as:

SomeClass.someFunction:42

There is an obvious trade-off here.

Finding the caller requires inspecting the stack, and stack walking is not free.

So automatic tagging can be disabled when necessary:

DebugPrint.autoTag = false

And when I already know the tag:

debugPrint.d("Database", "Loaded 120 records")

there is no reason to pay for automatic caller detection.

Lazy messages

This was probably one of the more important design decisions.

Consider:

debugPrint.d("User: $user")

The message has to be constructed before the logging function receives it.

That may be completely fine for a small string.

But sometimes the value you're formatting is expensive.

So debugprint also accepts a lambda:

debugPrint.d {
    "User: ${expensiveOperation()}"
}

When debug logging is disabled, the lambda is not evaluated.

That means the work required to construct the message can be skipped entirely.

The API stays simple, but it gives me a way to avoid unnecessary work when logging is turned off.

A small sink abstraction

At first, everything simply went to Android's Logcat.

But I didn't want the implementation to be permanently tied to one output.

So the library has a small sink abstraction.

Conceptually:

debugPrint
    ↓
  sink
    ↓
 Logcat

The sink can be replaced with a custom implementation.

That could be useful for something like writing development logs to a file or forwarding them somewhere else.

The important part for me is that the core API doesn't have to change.

debugPrint.d("hello")

can remain the same even if the destination changes.

Logging should not break the app

There is one more rule I wanted to keep:

A logging failure should never become an application failure.

If a custom sink throws an exception, debugprint treats that as a logging problem rather than an application problem.

In other words:

logging fails
     ↓
application continues

A debug utility should not be capable of taking down the application it is helping me inspect.

What I deliberately did not build

There are many things I could have added.

Timestamps.

Colors.

JSON formatting.

Log persistence.

Remote logging.

Crash reporting.

Network transport.

Analytics.

A configuration dashboard.

And probably another hundred "useful" features.

I intentionally left them out.

The point of debugprint is not to become a complete logging ecosystem.

It is supposed to stay small.

If I need a production logging system, I should use a production logging system.

If I just want to write:

debugPrint.d("Why is this null?")

I want that to be easy.

Why make it a public library?

Honestly, the original motivation was personal.

I was working on several Kotlin projects and wanted the same small convenience in all of them.

So initially, this could have remained a private utility inside one project.

Instead, I decided to turn it into my first published Kotlin/Android library and put it on Maven Central.

That made the project slightly more interesting.

Once something becomes a reusable library, even a tiny one, you have to think about API design differently.

You start asking:

Is this API actually understandable?
Is the default behavior sensible?
What should happen in release builds?
What are the performance trade-offs?
How much configuration is enough?
What should never be part of the public API?
Can I keep the dependency footprint small?

A utility that took a short time to write becomes a small exercise in software design.

Is this something everyone needs?

No.

And I think that's worth saying explicitly.

Android already provides logging.

Logcat is not missing.

There are already many mature logging libraries.

debugprint is not trying to replace them.

This library exists because I spent more than three years using one development workflow, moved to another ecosystem, and realized that I missed one tiny piece of that workflow.

That's a very small reason to create a library.

But sometimes small reasons are enough.

For me, the interesting part wasn't inventing a new logging technology.

It was noticing how much developer experience is made up of tiny conveniences that become invisible once you use them every day.

After years of writing Flutter code, debugPrint() had become one of those conveniences.

So I brought the idea with me.

Flutter
  ↓
debugPrint()
  ↓
years of muscle memory
  ↓
Kotlin
  ↓
"Why am I writing this tag again?"
  ↓
debugprint

My first Kotlin/Android library probably isn't going to change how people log on Android.

It wasn't supposed to.

I just wanted my new Kotlin projects to feel a little more familiar.

Links

GitHub repository:
https://github.com/cas8398/debugprint

Maven Central:
https://central.sonatype.com/artifact/com.flagodna/debugprint

Introducing the FlagoDNA Roadmap: Building in Public with Purpose

Cahyanudien Aziz Saputra — Sat, 19 Sep 2026 06:58:44 +0000

Today, I published the FlagoDNA Roadmap.

This roadmap is created as a way to share the direction of FlagoDNA more openly — what we are building, what we are improving, and what ideas we are exploring for the future.

FlagoDNA has always been built around a simple idea: technology should respect people.

That means building software with a focus on privacy, simplicity, and long-term independence. No unnecessary tracking. No attention-driven design. Just tools that are useful and respectful.

Why a roadmap?

As FlagoDNA grows, more people are using its applications across different needs — from daily Muslim utilities to productivity and small business tools.

A roadmap helps users understand:

What projects are currently being developed
What improvements are coming next
What ideas are still being explored

It is also a way for me, as an independent developer, to stay accountable to the direction of the ecosystem.

How the roadmap works

The roadmap is divided into three stages:

Now
Projects and improvements currently being worked on.

Next
Planned projects and updates that are being prepared.

Later
Long-term ideas that may be explored when the time and resources are right.

The roadmap is not a fixed promise or a strict schedule. Development priorities can change based on user feedback, technical considerations, and available capacity.

Current Focus

Some of the current areas of development include:

HadisKu improvements with the next beta updates
KasirCepat feature expansion
Future exploration of projects like Muslim Launcher and Tiketea

Each project has its own journey, and the goal is to continue improving them step by step.

Building Slowly, Building Meaningfully

FlagoDNA is built independently, which means progress may sometimes be slower compared to larger companies with bigger teams.

But independence also allows us to focus on what matters:

Creating software that is simple, privacy-conscious, and built with respect for users.

The roadmap is one small step toward making that journey more visible.

You can view the FlagoDNA Roadmap here:

https://flagodna.com/roadmap/

Thank you to everyone who uses, supports, and follows the development of FlagoDNA.

—
Cahyanudien Aziz Saputra
Founder of FlagoDNA

I Built Lens Browser Because the Internet Never Forgets

Cahyanudien Aziz Saputra — Tue, 08 Sep 2026 07:45:25 +0000

Every time we open a website, something happens behind the screen.

A request is sent.

A connection is created.

Scripts are loaded.

Trackers start working.

And quietly, information about us begins to leave.

Most people never see it.

They simply open a page, search for something, read an article, or watch a video — while invisible systems collect signals about their behavior.

The modern internet is powerful.

But that power often comes with a hidden cost.

Our data.

Your Data Is Not Free

Browsing history.

Interests.

Device information.

Location signals.

Online behavior.

These things have value.

Companies build products around this data. Advertisers use it to understand people. Analytics systems use it to measure behavior.

But the question is:

Do we really know how much of ourselves we give away every day?

Privacy should not be something only available to people who understand complicated settings.

It should be the default.

That is why I started building Lens Browser.

Not Another Browser

There are already many browsers.

Some are fast.

Some have beautiful interfaces.

Some have millions of users.

I did not build Lens Browser because the world needed another browser.

I built it because I wanted a browser that starts from a different idea:

The user should be in control.

A browser should be a window to the internet.

Not a tool that quietly watches the person looking through that window.

Privacy by Default

Lens Browser was designed around a simple principle:

Browse privately. No compromise.

It includes:

Dual-layer ad blocking using connection-level filtering and JavaScript interception
Anti-fingerprinting protection through Privacy Mode
Automatic deletion of history, cookies, and cached data when closing the app
Threat detection before dangerous pages fully load
Trusted and blocked domain management
Lightweight design with no account required

No sign-up.

No profile.

No unnecessary tracking.

Just open and browse.

Built Small, Built Carefully

Lens Browser is built with modern Android technology:

Kotlin
Jetpack Compose
MVVM architecture
Android WebView with custom privacy layers

The app is lightweight, around 10 MB, and supports Android 6.0+.

It is also open source under the MIT License.

I believe privacy tools should be transparent.

People should be able to understand what they use.

The Internet Was Built to Connect People

Technology should make life better.

It should help people discover, communicate, and create.

But as the internet evolves, we should not forget one important thing:

Behind every device is a person.

Not a data point.

Not a profile.

Not a target.

A person.

Lens Browser is my small contribution toward a more private internet.

A reminder that privacy still matters.

Try Lens Browser

Lens Browser is available for Android.

Download:
https://flagodna.com/lens-browser/

Rebuilding MTA ONE v4: Why I Simplified an App That Already Worked

Cahyanudien Aziz Saputra — Tue, 25 Aug 2026 06:04:31 +0000

Sometimes, rebuilding an application is not because the old version is broken.

Sometimes, it is because the application has become too complicated.

MTA ONE was already working. Users could watch MTA TV, listen to online radio, read weekly brochures, and access several other features.

But after years of development, I started to realize something:

The application was trying to become too many things at once.

And as a solo developer, maintaining everything with the same quality was becoming harder.

That is why I decided to rebuild MTA ONE version 4.

Not by adding more features.

But by simplifying it.

The Problem Was Not the Code

When an application grows, adding features feels like progress.

A new menu here.

A new category there.

Another useful feature for users.

At some point, the application becomes larger, but not necessarily better.

Some features require continuous maintenance:

Updating content
Managing data
Fixing edge cases
Handling user reports
Testing across different devices

These tasks are manageable when there is a dedicated team.

But I am building and maintaining multiple applications by myself.

So I needed to make a decision.

Should I keep expanding MTA ONE into an application with many unrelated features?

Or should I return to the core purpose?

I chose the second option.

From Flutter to Kotlin Native

One of the biggest changes in MTA ONE v4 is the technology behind it.

The previous version was built with Flutter.

For version 4, I rebuilt it using Kotlin Native with Jetpack Compose.

The migration started around August 19, 2026, and the new version was released on August 21, 2026.

The reason was not because Flutter was bad.

Flutter helped me build the previous version faster.

But for this application, I wanted more control over the Android experience, especially for:

Media playback
Performance
System integration
Long-term maintenance

Moving to native Android gives me a stronger foundation for future development.

Removing Features Was a Difficult Decision

The previous MTA ONE version had several features that were useful:

Qibla direction
Offline Quran
Prayer guidance
Daily prayers
Hijri calendar
Weather information

However, useful does not always mean it should stay inside the application.

Every feature has a cost.

A feature is not only about writing code once.

It requires maintenance afterward.

For example:

A weather feature requires weather data.

A Quran feature requires content management.

A calendar feature requires accuracy and updates.

When many features are combined into one application, the responsibility grows significantly.

I realized that if I wanted MTA ONE to continue improving, I needed to reduce the scope.

Returning to the Core of MTA ONE

MTA ONE is now focused on the features that are directly connected with MTA content.

MTA TV

The main video experience remains.

Users can watch MTA TV directly from the application with a simpler interface.

Online Radio

MTA ONE provides access to online radio channels from different regions:

Persada FM — Solo / Sragen
Suara Kesuma FM — Wonosobo
Persada FM Pacitan — Pacitan
Persada Bali FM — Bali
Skar FM — Madiun
Kharisma FM — Pontianak

The goal is simple:

Open the application, select a channel, and listen.

Weekly Brochure

Users can access the latest MTA weekly brochures.

Instead of keeping a large archive, MTA ONE focuses on providing the latest content that users frequently need.

Prayer Schedule

Prayer schedules are still available for cities and districts across Indonesia.

MTA Updates and Information

Users can also access:

Latest MTA news
MTA profile
Official study location information

A Smaller Application, A Better Direction

This rebuild taught me something:

More features do not always create a better application.

Sometimes, removing features allows the important parts to become better.

MTA ONE v4 is not a bigger application than before.

It is a more focused application.

With a smaller scope, I can spend more time improving:

Stability
Performance
User experience
Long-term maintenance

For a solo developer, focus is not just a preference.

It is a requirement.

MTA ONE v4 is the next step in that direction.

A simpler foundation for future improvements.

Try MTA ONE v4

MTA ONE v4 is now available.

You can download it from Google Play:

Download MTA ONE

Rebuilding Brosur MTA Lengkap: Why I Rebuilt an App That Already Worked

Cahyanudien Aziz Saputra — Tue, 04 Aug 2026 04:23:48 +0000

Sometimes the hardest decision in software development is not adding a new feature.

It is deciding to rebuild something that already works.

On August 3, 2026, I released Brosur MTA Lengkap version 4.0.0.

This release represents a major turning point.

It is not just an update.

It is a complete rebuild.

The uncomfortable decision

The previous version of Brosur MTA Lengkap was built with Flutter.

Flutter helped me move quickly, experiment with ideas, and bring the application to users faster.

For the early stage, it was the right decision.

But over time, the application changed.

It was no longer just a simple PDF reader.

It became a place where users could explore thousands of Islamic materials: brochures, articles, documents, and other educational content.

The needs became bigger:

Faster access to content.
Better offline support.
More reliable file management.
A stronger foundation for future development.

At that point, I had a choice:

Continue building on the existing foundation, or rebuild it properly.

I chose the harder path.

Rebuilding for the next phase

Rewriting an application means accepting that some previous work will be left behind.

It is not an easy decision.

There is always a temptation to keep adding features because the existing application already works.

But sometimes the biggest limitation is not the feature itself.

It is the foundation underneath it.

The goal was not simply changing technology.

The goal was creating an application that could continue growing for years.

From an app to a digital library

The vision for Brosur MTA Lengkap has changed.

Originally, the application was mainly a way to open and read PDF brochures.

Now, I see it as a small digital library.

A library needs more than documents.

It needs:

A simple way to discover content.
A reliable way to read.
A way to save important materials.
A way to find information quickly.

That is why version 4 focuses on the complete reading experience.

Designed around offline access

One important principle behind this rebuild is offline-first.

Knowledge should not disappear just because an internet connection is unavailable.

Version 4 improves local storage and caching so users can:

Access previously loaded content faster.
Keep reading history and favorites locally.
Open downloaded documents.
Search content without depending entirely on a server.

For educational applications, reliability matters.

The user should focus on learning, not on whether the connection is available.

Building a better way to find knowledge

As the number of documents grows, finding information becomes a challenge.

A library is only useful if people can find what they need.

That is why version 4 introduces offline full-text search.

The search system is designed to work with large amounts of content while providing more relevant results through ranking and language processing.

The goal is simple:

Help people find knowledge, not just files.

Why Kotlin Native?

This rebuild also moved the application from Flutter to Kotlin Native with Jetpack Compose.

This was not a decision because one technology is universally better than another.

Different tools are suitable for different stages.

Flutter was valuable when speed of development was the priority.

But for this next phase, I wanted deeper control over Android's native capabilities and a foundation closer to the platform where the application lives.

A new chapter for FlagoDNA

Brosur MTA Lengkap version 4 is part of a bigger direction for FlagoDNA.

I want to build software that is:

Useful.
Simple.
Privacy-respecting.
Accessible.

Not every application needs more notifications, more tracking, or more distractions.

Sometimes the best software is the one that quietly helps people accomplish something meaningful.

This rebuild is one step toward that direction.

Thank you to everyone who has used the application, shared feedback, and supported this project.

Version 4.0.0 is not the final destination.

It is a new foundation for what comes next.

Redesigning FlagoDNA Around a Mission, Not Products

Cahyanudien Aziz Saputra — Sun, 26 Jul 2026 05:32:49 +0000

Today, I launched a completely redesigned version of the FlagoDNA website.

At first glance, it might look like a visual refresh.

New layouts.

New sections.

Better typography.

A cleaner design.

But the biggest change isn't what you see.

It's the story the website tells.

The Website Wasn't the Problem

For a long time, the FlagoDNA homepage looked like many developer websites.

It showcased applications.

Visitors could browse Quran Today, HadisKu, Hijri Today, and other projects I had built over the years.

Technically, it worked.

But something was missing.

People understood what I had built.

Very few understood why I built it.

That realization completely changed how I approached the redesign.

I Never Wanted to Build Just Another App Portfolio

FlagoDNA never started with a business plan.

There wasn't a pitch deck.

There wasn't venture capital.

There wasn't even a goal to start a company.

I simply wanted to solve problems I experienced myself.

One application became another.

Each project taught me something—not only about software engineering, but about how technology quietly shapes the way people think, communicate, focus, and even practice their faith.

Eventually, I realized I wasn't just building applications anymore.

I was slowly building a philosophy.

The Real Problem Was Never Missing Apps

For years, I believed people simply needed better software.

Eventually, I realized something much bigger.

The real problem wasn't the lack of applications.

It was the digital environment surrounding them.

Modern software often competes for attention.

Notifications interrupt focus.

Advertisements become business models.

Personal data becomes a product.

Algorithms encourage people to stay longer instead of helping them leave sooner.

I didn't want FlagoDNA to become another company optimizing for engagement.

I wanted to build technology that respected people.

A Different Philosophy

That realization became the foundation of every product I build.

Before adding a feature, I ask a simple question.

Does this respect the user?

That question influences everything.

Does this feature really need an account?
Does it need an internet connection?
Are we collecting information we don't actually need?
Is this notification necessary?
Does this make life simpler—or noisier?

Those questions eventually became the principles behind FlagoDNA.

Privacy First.
No Ads.
No User Tracking.
No Selling Personal Data.
Respect Human Attention.

Technology should quietly support people—not manipulate them.

Why the Homepage Changed

The redesign wasn't about making the website prettier.

It was about telling the right story.

Previously, visitors arrived and immediately saw products.

Now they first see the mission.

Then the beliefs.

Then the principles.

Only after understanding those things do they discover the products.

Because Quran Today, HadisKu, Hijri Today, and every future project are not the story.

They're the proof.

They exist because they share the same philosophy.

Looking Beyond Individual Applications

Another reason for the redesign was to communicate where FlagoDNA is heading.

Many people naturally see FlagoDNA as an Android app developer.

That isn't wrong.

But it isn't the complete picture anymore.

The long-term vision is much broader.

FlagoDNA is gradually building a privacy-first digital ecosystem for Muslims.

Applications are only the beginning.

In the future, that ecosystem may include trusted AI, launcher experiences, shared infrastructure, developer tools, and other technologies that help Muslims embrace modern technology without sacrificing their faith, personal privacy, or attention.

Building for the Long Term

Many technology companies optimize for growth.

More engagement.

More impressions.

More advertisements.

More data.

I believe there is another way.

If someone opens one of my applications, accomplishes what they came to do, and then puts their phone away—that's success.

Technology shouldn't compete with life.

It should quietly support it.

More Than a New Website

Looking back, I don't think the previous website was bad.

It simply reflected an earlier stage of FlagoDNA.

Back then, I was focused on showing what I had built.

Today, I'm equally focused on explaining why it exists.

The redesign marks an important shift.

Not from one design to another.

But from presenting products to communicating a mission.

I hope that when someone visits FlagoDNA today, they don't simply think,

"This developer builds Android apps."

Instead, I hope they leave understanding something much more important.

FlagoDNA is building technology that respects faith, protects personal privacy, and values human attention.

Explore the New FlagoDNA

If you've followed my work over the years, thank you.

And if this is your first time hearing about FlagoDNA, welcome.

I invite you to explore the new website and discover the mission, beliefs, products, founder story, and long-term vision behind everything we're building.

🌐 https://flagodna.com

I'd genuinely love to hear your thoughts.

Every conversation, suggestion, and piece of feedback helps shape what FlagoDNA becomes next.

The Story Behind Quran Today, the Ad-Free Quran App I Built for Myself

Cahyanudien Aziz Saputra — Fri, 17 Jul 2026 04:17:27 +0000

Why I stopped looking for an "Islamic super app" and built the simplest Quran app I could open every single day

(formerly known as FastiQuran)

I didn't build Quran Today because I thought the existing Quran apps were bad.

Quite the opposite. Many of them are genuinely excellent.

I built it because I was looking for a different kind of Quran reading experience — a free Quran app, with no ads, and no extra steps standing between me and actually reading.

It Started With Something Simple

I only had two Quran apps on my phone. Both are among the most popular on the Play Store, and honestly, they deserve to be.

They're packed with features. Prayer times, qibla direction, daily duas, dzikir, tafsir, translations, recitations from dozens of qaris, worship reminders, and a long list of other supporting tools.

I never saw that as a flaw.

The problem was on my end.

I realized that almost every time I opened one of those apps, I was only trying to do one thing.

I wanted to keep reading the Quran. Nothing more.

I never opened the qibla compass. I rarely checked prayer times. I almost never touched the extra features — features that were, honestly, very well made.

All I wanted was one simple experience.

Open the app. Return to the last verse. Read. Done.

Over time, it started to feel like Quran apps were quietly turning into Islamic super apps — while all I wanted was a quiet, digital mushaf.

I Wasn't Looking for More Features

So I started asking myself a question. If my needs were this simple, why did the apps I used keep getting more complex?

More menus. More screens. More things to click through before I could actually start reading.

Even the app size kept growing, carrying capabilities that might be useful to someone, somewhere — but that I almost never used.

I began to think that maybe I didn't need a more complete app.

What I actually needed was an app that was more honest about its one real purpose: helping someone read the Quran.

About Gamification

There's one more thing I kept coming back to.

Lately, more and more apps lean on gamification. Reading streaks. Badges. Stats. Daily targets. Notifications reminding you not to lose your progress.

I understand the reasoning. As someone who builds apps myself, I know these mechanics genuinely increase engagement.

But the more I sat with it, the more I felt that the Quran occupies a different kind of place in someone's life.

A person's relationship with the Quran isn't a relationship between a user and an app. It's a relationship between a servant and the word of their Lord.

I personally don't think that relationship needs to be propped up by numbers. It doesn't need to be protected by the fear of breaking a streak. It doesn't need to feel like a game you're supposed to win.

If today I read one page with real presence of heart, that's already enough. If tomorrow I read less, my relationship with the Quran still isn't something a graph can measure.

Plenty of people genuinely like gamification, and there's nothing wrong with that. I just know I'm not one of them.

So I Decided to Build It Myself

That's where Quran Today was born.

Not out of a desire to build something more impressive. Not because I thought I could build the "best" Quran app out there.

I just wanted to build the app I myself would want to open every day.

The principle was simple:

When you open the app, it takes you straight back to your last read verse.
No friction before you start reading.
No feature that exists just because "every other app has it."
No ads.
No tracking of reading habits.
No streaks.
No virtual rewards.

I wanted an app that, once opened, barely feels like it's there at all. Because the focus was never meant to be the app.

It was always meant to be the Quran.

Building It Turned Out to Be Harder Than It Sounded

The first version of Quran Today was built in Flutter. It shipped. It launched successfully.

But the results were unremarkable. About five hundred people installed it.

At first, I was disappointed. I wondered if I'd just built yet another version of something that already existed hundreds of times over.

After sitting with that for a while, though, I realized the idea wasn't the problem. How I built it was.

The user experience wasn't mature enough. A lot of the design decisions hadn't actually solved the problem I originally set out to solve.

That's when I made a fairly drastic call. I rebuilt everything from scratch.

Not just a new tech stack — I restructured almost the entire foundation of the app. The codebase was simplified to be easier to maintain and extend. The interface was redesigned over and over until it finally felt natural to use.

I spent a surprising amount of time on questions that seemed small.

What's the most comfortable way to switch between surahs? Does the app even need a home screen? Should the surah list fill the whole screen, appear as a panel, or just be a simple dialog? How should verses be displayed — as cards, like modern apps do, or flowing continuously, like a mushaf?

Questions like these ended up taking far more time than writing the code itself.

There Were Moments I Wanted to Quit

Not every day felt good.

Some nights I closed my laptop not because the work was done, but because my head was simply too full.

Sometimes I'd think, "Is any of this actually worth it?"

I think almost anyone who's ever built something alone has had that moment.

But every time that question came up, I kept coming back to the same answer.

If an app like this didn't exist yet, then I'd build it. And if it turned out that I was the only one who ever used it, that would be fine too — because I built it for myself in the first place.

I've Made Peace With That Possibility

Quran Today may never become the number one Quran app.

It may never have millions of users. It may never go viral.

And I'm genuinely at peace with that.

I'd rather have an app I actually open every single day than one that's wildly popular but has lost the reason it was built in the first place.

If it turns out other people are also looking for a calm, simple, distraction-free way to read the Quran, I'll be genuinely grateful. It would mean I'm not alone in wanting this.

Why the Name Changed

The app was originally called FastiQuran.

That name came from an idea about speed. Fast to open. Fast to use. Fast to get back to reading.

But the longer I worked on it, the more I realized that name only explained how the app worked. Not why it existed.

Eventually I landed on two words that felt much closer to the real purpose.

Quran Today.

Because in the end, this app was never really about speed. Never about technology. Never about how many features it had.

It just wants to be ready, whenever someone wants to come back to the Quran — today.

Today. At the exact verse they left off. Without friction. Without pressure. Without needing to be anything more than someone who reads the Quran.

I don't know if Quran Today will ever become a big app.

But I know one thing.

Tomorrow morning, when I want to read the Quran again, this is the app I'll open.

And maybe that's the best reason Quran Today exists at all.

If you're also looking for a calm Quran app — no ads, no account, no streaks making you feel guilty for missing a day — Quran Today is free to download on Google Play. No hidden costs, no premium tier. Install it once, and every time you open it, you're right back at the last verse you read.

About the Author

Cahyanudien Aziz Saputra — Founder of FlagoDNA, building software for Muslim life with a focus on privacy, simplicity, and long-term digital independence. Developer. Writer. Independent.

Personal Website · LinkedIn · Get Quran Today on Google Play

Quran Today: Ketika Saya Memutuskan Menghapus Semua yang Tidak Penting

Cahyanudien Aziz Saputra — Thu, 16 Jul 2026 18:41:53 +0000

Bagaimana jika aplikasi Al-Qur'an tidak mencoba melakukan segalanya?

Bagaimana jika ia hanya membantu kita membaca?

Selama bertahun-tahun saya menggunakan dan mencoba banyak aplikasi Al-Qur'an.

Sebagian memiliki fitur yang sangat lengkap. Ada dashboard, statistik, tantangan membaca, gamifikasi, akun, sinkronisasi cloud, hingga berbagai menu yang terus bertambah.

Semuanya bagus.

Namun suatu hari saya bertanya pada diri sendiri.

Apakah saya benar-benar membutuhkan semua itu ketika ingin membaca Al-Qur'an?

Jawaban saya ternyata sederhana.

Tidak.

Saya hanya ingin membuka aplikasi, lalu langsung membaca.

Berawal dari FastiQuran

Sebelum bernama Quran Today, aplikasi ini dikenal sebagai FastiQuran.

Awalnya proyek ini hanyalah eksperimen pribadi.

Saya mencoba membuat pengalaman membaca yang lebih sederhana dibanding aplikasi Al-Qur'an pada umumnya.

Seiring waktu, saya mulai menyadari bahwa arah aplikasinya semakin jelas.

Bukan menjadi aplikasi dengan fitur paling banyak.

Melainkan menjadi aplikasi yang paling nyaman digunakan untuk membaca.

Karena itu saya memutuskan mengganti namanya menjadi Quran Today.

Nama baru ini lebih mencerminkan tujuan utamanya.

Membaca Al-Qur'an hari ini.

Dan melanjutkannya lagi besok.

Saya Menghapus Banyak Hal

Saat mengembangkan Quran Today, saya justru lebih sering menghapus daripada menambahkan fitur.

Saya menghapus hal-hal yang menurut saya mengganggu proses membaca.

Saya bertanya berulang kali.

Apakah fitur ini benar-benar membantu seseorang membaca Al-Qur'an?

Jika jawabannya tidak jelas, saya memilih untuk tidak menambahkannya.

Semakin sedikit langkah yang harus dilakukan pengguna sebelum mulai membaca, semakin baik.

Tidak Ada Dashboard

Ketika membuka Quran Today, Anda tidak akan menemukan halaman beranda.

Tidak ada kartu informasi.

Tidak ada statistik.

Tidak ada menu yang harus dilewati.

Aplikasi langsung membawa Anda kembali ke ayat terakhir yang dibaca.

Bagi saya, layar terbaik adalah layar yang membuat pengguna segera membaca.

Privasi Bukan Fitur Tambahan

Saya percaya membaca Al-Qur'an adalah aktivitas yang bersifat pribadi.

Karena itu Quran Today dibuat dengan prinsip yang sederhana.

Tidak perlu akun.
Tidak perlu login.
Tidak ada analytics.
Tidak ada pelacakan.
Tidak ada iklan.

Seluruh progres membaca, bookmark, daftar hafalan, dan pengaturan tetap berada di perangkat pengguna.

Saya tidak ingin mengetahui kapan seseorang membaca Al-Qur'an.

Saya juga tidak ingin mengumpulkan data yang sebenarnya tidak saya perlukan.

Gratis Selamanya

Quran Today tidak memiliki langganan.

Tidak ada fitur premium.

Tidak ada iklan.

Semua fitur tersedia sejak pertama kali aplikasi dipasang.

Saya ingin setiap orang dapat menikmati pengalaman membaca yang sama, tanpa harus membayar untuk membuka fitur tertentu.

Dibangun Ulang dari Flutter ke Kotlin

Salah satu keputusan terbesar selama pengembangan adalah memindahkan proyek ini dari Flutter ke Kotlin Native menggunakan Jetpack Compose.

Keputusan ini tidak mudah.

Artinya saya harus menulis ulang hampir seluruh aplikasi.

Namun hasilnya sepadan.

Rendering teks Arab menjadi lebih baik.

Scrolling terasa lebih halus.

Integrasi Android menjadi lebih alami.

Dan saya memiliki kontrol yang lebih besar terhadap performa aplikasi.

Dibuat oleh Satu Orang

Quran Today tidak dibuat oleh sebuah tim besar.

Tidak ada desainer.

Tidak ada product manager.

Tidak ada investor.

Saya mengerjakan semuanya sendiri.

Mulai dari desain antarmuka, pemrograman, optimasi database, terjemahan, hingga halaman website dan dokumentasi.

Perjalanannya memang lebih lambat.

Tetapi saya menikmati setiap prosesnya.

Saya Berharap...

Saya tidak berharap Quran Today menjadi aplikasi Al-Qur'an terbesar.

Saya hanya berharap ketika seseorang ingin membaca Al-Qur'an, aplikasi ini tidak menghalangi niat baiknya.

Ia cukup membuka aplikasi.

Dan langsung membaca.

Kalau suatu hari ada seseorang yang berkata,

"Saya jadi lebih sering membaca Al-Qur'an karena aplikasi ini."

Mungkin itu sudah menjadi pencapaian terbesar bagi saya.

Ingin Mencobanya?

Quran Today adalah proyek independen yang saya bangun seorang diri dengan satu tujuan sederhana: membuat pengalaman membaca Al-Qur'an menjadi lebih nyaman, lebih tenang, dan tanpa gangguan.

Jika menurut Anda filosofi tersebut menarik, silakan mencobanya.

🌐 Website
https://flagodna.com/quran-today/

📱 Google Play
https://play.google.com/store/apps/details?id=com.flagodna.fastiquran

Masukan, kritik, maupun saran akan sangat berarti untuk membantu Quran Today menjadi aplikasi yang lebih baik.

Terima kasih telah menggunakan Quran Today.

Semoga aplikasi kecil ini bisa menjadi teman dalam perjalanan membaca Al-Qur'an, satu ayat demi satu ayat.