Permulaan
Salah satu masalah awal yang harus kita hadapi ketika hendak membuat aplikasi mobile adalah: platform apa saja yang akan di-support? Kebanyakan aplikasi hanya akan mendukung Android saja atau iOS saja atau kedua-duanya.
Dan jika kita memilih akan mendukung 2 platform tersebut, kita akan dihadapkan dengan permasalahan yang kedua, yaitu: tentang pendekatan pengembangan aplikasi.
- Apakah kita akan menyediakan 2 tim berbeda untuk tiap platform?
- Atau kita hanya menyediakan 1 tim saja dan menulis satu set codebase untuk 2 platform sekaligus?
Dalam tulisan kali ini, kami akan menjelaskan perbedaan terhadap 3 buah pendekatan pokok ketika kita hendak mengembangkan aplikasi mobile. Dengan memahami perbedaan 3 konsep tersebut, diharapkan kita bisa memilih konsep yang benar dan sesuai dengan kebutuhan.
Pendekatan Full Native
Pendekatan yang paling klasik dan paling dasar adalah pendekatan native platform. Yaitu anda membuat menulis kode program yang spesifik terhadap satu platform tertentu, misalkan satu program khusus untuk iOS, dan satu program khusus untuk Android. Dengan pendekatan ini, aplikasi anda akan berjalan pada satu platform tertentu secara spesifik, dan akan di-render dengan satu engine widget yang spesifik dan seterusnya.
Kelemahannya adalah anda harus menduplikat step kerja anda sebanyak platform yang anda ingin dukung. Begitu juga dengan sumber daya manusia, anda akan kesulitan jika tidak membuat tim khusus untuk setiap platform.
Pendekatan Embedded WebApp / Hybird
Pendekatan yang kedua adalah cara yang pertama kali ditemukan sebagai solusi yang memungkinkan kita sebagai pengembang untuk hanya menulis satu basecode saja yang kemudian akan berjalan di berbagai platform. Akan tetapi kode program yang kita tulis tersebut hanyalah berupa HTML, CSS dan Javascript yang kemudian akan dirender oleh native WebView pada tiap platform.
Dengan pendekatan seperti ini, pengembang akan mendapatkan batasan ketika hendak berhubungan dengan hardware atau service-service tertentu pada tiap platform, karena WebView hanyalah sebatas teknologi Web yang tidak bisa mengakses hal-hal tersebut. Oleh karena itu, ketika aplikasi kita ingin berhubungan dengan hardware mau pun platform-specific service, komunikasi tersebut akan selalu melewati suatu jembatan atau bridge.
Bridge
Adalah suatu komponen yang menjembatani antar 2 atau lebih komponen yang lain. Dan komponen-komponen tersebut bisa dibangun dengan bahasa pemrograman yang berbeda.
Pendekatan Native Cross Platform
Pendekatan yang ketiga adalah pendekatan yang paling modern. Memungkinkan kita untuk menulis aplikasi dengan bahasa yang independen, tidak terpengaruh dengan platform tertentu. Akan tetapi dengan demikian, kita tetap bisa mendapatkan performa seperti performa aplikasi native yang asli, dan juga kita bisa lebih leluasa untuk berkomunikasi dengan hardware maupun dengan platform-specific service.
Pendekatan Reactive View
Dalam pendekatan ini sebagian besar kode aplikasi murni ditulis dengan bahasa pemrograman yang bersifat independen atau tidak terpengaruh terhadap platform semisal bahasa Javascript. Kode program javascript tersebut akan memerintahkan Native UI Components untuk merender aplikasi. Sehingga UI yang dihasilkan adalah UI native, bukan sebuah kode HTML yang ditampilkan melalui WebView. Sehingga dengan pendekatan ini kita bisa mendapatkan tampilan yang lebih mulus dan performa yang cenderung lebih bagus dari WebView.
Akan tetapi masalahnya adalah: semua komunikasinya tetap melalui Bridge. Seolah-olah aplikasi kita adalah satu set komponen Native yang dikontrol penuh oleh Javascript. Dan komunikasi yang tersentralisasi melalui bridge tersebut bisa menjadi sebuah bottleneck yang berpotensi menimbulkan permasalahan performa aplikasi.
Di antara framework yang menerapkan konsep ini adalah React Native.
Pendekatan Flutter
Dalam pendekatan ini, flutter memindahkan semua proses renderisasi komponen dari bagian platform ke bagian aplikasi Flutter itu sendiri. Sehingga Flutter merender semua UI menggunakan Widget dan Komponennya sendiri, dan tidak lagi bergantung pada platform sedikitpun kecuali hanya canvas yang digunakan untuk menampilkan komponen yang telah diproses oleh Flutter.
Lalu setiap event atau user input yang diterima oleh Canvas, akan langsung diteruskan ke Flutter dan akan diproses secara internal oleh Flutter. Sehingga dengan pendekatan ini bottleneck yang ada pada pendekatan Reactive View tidak lagi berpotensi menjadi masalah.
Salah satu kelemahan dari pendekatan ini adalah: karena proses rendering tidak melibatkan Native UI Widget maupun Native UI Components dan justru menggunakan UI dan Components miliki Flutter, ini akan membuat ukuran APK menjadi lebih besar. Ya, itu benar. Akan tetapi per 2019, Flutter telah melakukan perbaikan sehingga ukuran keseluruhan framework hanyalah sebesar 4.3MB saja.
Kesimpulan
Ada 3 pendekatan inti dalam memulai mengembangkan aplikasi mobile Android mau pun iOS. Ketiga-tiganya datang dengan kelebihan dan kekurangannya masing-masing. Jika aplikasi yang anda bangun hanyalah aplikasi kecil dan hanya berjalan di satu platform saja, maka bisa jadi pendekatan yang pertama lebih sesuai dengan anda. Dan apabila aplikasi anda adalah aplikasi yang butuh berjalan di 2 platform android dan iOS akan tetapi tidak terlalu bergantung pada hardware, bisa jadi cara kedua adalah yang paling tepat. Dan seterusnya untuk pendekatan yang ke-3.
Intinya yang anda harus lakukan adalah menganalisa inti permasalahan dan juga inti kebutuhan. Sehingga keputusan apa pun yang ada ambil, maka itu adalah keputusan yang paling efisien dan efektif.
Sekian. Semoga bermanfaat. Terima kasih banyak.
Referensi
[1] https://github.com/devonfw-forge/devonfw4flutter/wiki/110-Under-the-Hood#reactive-view-approach
[2] https://medium.com/gradeup/mobile-development-approaches-and-flutter-architecture-flutter-part-i-a7e08838c97a
