Direktur Teknis Boris Goryachev berbicara tentang bagaimana Medusa mengerjakannya selama setahun dan mengapa itu ditulis dalam Flutter
Pada 12 Mei, rilis aplikasi seluler Medusa baru ( iOS , Android ) berlangsung - hampir dua tahun setelah kami memutuskan untuk menulis ulang. Mengapa lama sekali? Mengapa bukan aplikasi asli? Mengapa bergetar? Semua ini diceritakan oleh direktur teknis Medusa Boris Goryachev.
Tidak seperti aplikasi lama kami, kami memutuskan untuk tidak membuat yang baru asli. Pertama, menulis kode yang sama dua kali membosankan. Kedua, tidak akan pernah berhasil sehingga dalam dua proyek berbeda yang ditulis oleh orang yang berbeda, semuanya sinkron dan sama. Biasanya seseorang bekerja lebih lambat, seseorang pergi berlibur, seseorang memiliki hutang teknis yang perlu ditutup. Semua pengalaman kami dalam membuat dan mendukung aplikasi asli telah mendorong kami - baik kami melakukan sesuatu yang salah, atau ini bukan cara kami. Dan kami mulai mencari milik kami. Kami mencoba React Native and Ionic, memikirkan pendekatan Basecamp - semua yang ada di web + lapisan asli yang tipis, bahkan mencoba untuk menuju Aplikasi Web Progresif dan tetap online.Sekitar waktu yang sama, saya menghadiri konferensi Google I / O dan bertemu orang-orang yang membuat Flutter di sana. Saya segera mencoba Dart dan bekerja sedikit pada Flutter, tetapi pada saat itu teknologinya belum siap untuk Medusa: tidak mungkin untuk menanamkan berbagai bahan interaktif dan menanamkan di dalam bahan kami, tetapi ini sangat penting bagi media. Jadi saya memutuskan untuk menunggu sampai Flutter tumbuh dewasa.Selama menunggu, kami melakukan banyak hal di sisi web: menulis ulang situs, menulis versi baru AMP. Kami menulis dan memindahkan semua proyek Medusa ke ui-kit - satu perpustakaan komponen yang digunakan situs ini dan terima kasih yang memungkinkan sejumlah besar mekanisme permainan kami. Kami membagi versi desktop dan seluler situs, sehingga halaman distribusi (halaman utama dan bagian) mulai dibentuk di dua tempat berbeda sesuai dengan aturan mereka sendiri.Sejalan dengan pekerjaan di situs, kami berpikir tentang aplikasi baru - kami datang dengan navigasi, makna, layar, fitur, dan sebagainya.
Secara paralel, perubahan penting terjadi dalam struktur departemen teknis. Kami mulai aktif menggunakan kalender Google dan alat perencanaan rapat lainnya, dan kami beralih dari Trello ke Basecamp. Sangat jelas bahwa bahkan aneh untuk membicarakannya. Tetapi butuh banyak waktu dan upaya untuk merampingkan kekacauan. Agenda rapat yang jelas, tindak lanjut cepat, file yang tidak hilang, dan cakupan bagan bukit memungkinkan untuk mengatasi sejumlah besar tugas dan tidak mati.Kenapa masih bergetar. Dan sedikit tentang Dart
Ketika orang belajar tentang Flutter, mau tidak mau mereka belajar tentang Dart. Tampaknya itu dianggap sebagai kelemahan terbesar Flutter, tetapi tepat sampai Anda mencoba untuk menulisnya. Dia sangat keren. Mengikuti JavaScript sangat spesial.Dart adalah bahasa pemrograman yang dikembangkan oleh Google. Diumumkan pada tahun 2011, yaitu, masih merupakan bahasa yang masih muda. Ini belum menjadi bahasa pemrograman utama (setidaknya untuk saat ini), tetapi pada saat yang sama sangat aktif digunakan di perusahaan itu sendiri. Selain Google, ada perusahaan besar lainnya, misalnya, Wrike, yang menggunakan Dart dan menulis tumpukan penuh di atasnya.Karena baik Dart maupun Flutter didukung oleh perusahaan yang sama, ini memungkinkan untuk mengubah bahasa sesuai kebutuhan Flutter. Sejauh yang saya tahu, kedua tim aktif berinteraksi satu sama lain, sehingga chip terus muncul dalam bahasa, memungkinkan Anda untuk menulis kode yang lebih menyenangkan di Flutter.Saya tidak akan mencoba menjelaskan apa yang terdiri dari Flutter - Wikipedia akan mengatasi tugas ini dengan lebih baik, tetapi saya hanya akan mengatakan bahwa di antara penulis ada orang-orang yang telah merender dalam Chromium.Pada bulan Desember 2018, tim Flutter merilis perpustakaan embed Webview di Flutter. Itu mentah dan, omong-omong, masih belum meninggalkan Status Pratinjau Pengembang, tetapi fakta ini tidak berhenti untuk mulai memperkirakan struktur aplikasi masa depan. Selama beberapa bulan saya bereksperimen di waktu luang, dan kemudian keputusan akhir dibuat.Pada awalnya saya duduk untuk menulis versi baru API khusus untuk aplikasi. Ideologi API ini dapat dirumuskan sebagai berikut: jika sesuatu dapat dilakukan di backend, maka Anda perlu melakukannya di backend. Dan bukan karena sulit untuk melakukan sesuatu pada klien. Faktanya adalah bahwa rilis di App Store dan Google Play adalah proses yang melelahkan dan panjang. Anda perlu beradaptasi dengan jadwal kerja mereka dan ingat bahwa tidak semua pengguna akan segera memperbarui aplikasi. Ini dapat dihindari ketika logika utama terjadi di server Anda. Perlu untuk memindahkan judul 10 piksel ke bawah? Sama sama. Hapus atau tambahkan komponen dengan cepat? Tidak ada masalah!
Untuk alasan yang sama, API untuk aplikasi seluler berisi komponen sesederhana mungkin, dari mana hampir semua materi dikumpulkan secara rekursif. Saya katakan "hampir" karena kami menampilkan game melalui WebView. Aplikasi tidak peduli apa yang ditampilkan - kartu, podcast, berita, atau "Big Top". Semuanya diproses oleh satu kode, dan tugas aplikasi adalah untuk mengambil komponen dan membuatnya (atau pergi ke daftar anak-anaknya dan menyebutnya secara rekursif).Argumen penting lain yang mendukung Flutter: pengembang "mengontrol semua piksel." Ketika Anda perlu memastikan bahwa ada bayangan yang benar di mana-mana, seperti dalam tata letak di Sketch, atau Anda ingin transparansi berubah sepanjang kurva, atau Anda ingin ukuran font dan semua tipografi dapat disesuaikan, semuanya sederhana dan realistis di Flutter.Fitur pembunuh lain dari Flutter adalah kenyamanan pengembangan. Hot-reload, yang biasa saya gunakan dalam pengembangan web, dan kecepatan reload aplikasi yang cepat tanpa kehilangan status membuat pekerjaan semudah mungkin. Anda tidak perlu duduk dan menunggu hingga aplikasi dibangun kembali, lalu tunggu hingga kode baru berfungsi, dan ulangi keadaan di mana Anda bekerja. Semuanya terjadi sangat cepat dan keren.Ekosistem
Meskipun Flutter dan Dart belum merupakan teknologi yang sangat populer, kami tidak memiliki masalah dalam menemukan perpustakaan. Sebagian besar dari apa yang dibutuhkan dalam aplikasi adalah dalam kerangka itu sendiri atau di pub.dev. Komunitasnya sangat menyenangkan dan siap membantu. Komunikasi ini adalah menghirup udara segar yang nyata, sangat mendukung.Selain itu, Google sendiri mendukung Flutter dengan baik. Kami menggunakan Firebase untuk mendorong, menganalisis, profil, dan menyimpan data pengguna (riwayat bacaan, posisi episode, bookmark), dan semua yang “hanya berfungsi” di sana. Tentu saja, sebagai orang yang belum pernah menulis aplikasi asli sebelumnya, terkadang liar untuk naik ke file gradle atau memasukkan properti ke info.plist. Tapi biasanya semuanya sudah googled, dan tidak ada yang sangat rumit.Perbedaan platform
Anda dapat berbicara tanpa henti tentang perbedaan antara iOS dan Android. Sebagai aturan, mereka segera ingat bahwa pola harus akrab bagi pengguna dan pedoman desain harus dipatuhi. Kami setuju dengan ini, tetapi tidak cukup. Penting untuk mengingat tentang identitas perusahaan Anda, dan tentang akal sehat, dan tentang logika perilaku pengguna yang sudah Anda kenal.Jika Anda melihat sejarah platform itu sendiri, kami melihat bahwa beberapa pola berubah dengan perangkat, sementara yang lain mengalir dari sistem ke sistem. Ini bukan tablet, tidak ada yang diam. Ada banyak contoh keren di mana perusahaan menyimpang dari rekomendasi Google dan Apple dan melakukan apa yang mereka anggap benar.
Contoh paling sederhana dan paling jelas adalah menggesek kembali di iOS. Area layar yang menerima gesekan adalah super kecil secara default, sekitar 20 piksel. Ini adalah cara kerja aplikasi Mail di iPhone, dan itu sangat merepotkan. Di Twitter, area ini sedikit diperluas, sementara di Telegram, area ini sangat besar! Telegram di Android memiliki jenis navigasi tersendiri dari daftar obrolan ke obrolan, ini adalah persilangan antara iOS dan Android. Ya, pedomannya keren, tetapi pada iPhone XR, menjangkau jari Anda ke tepi kiri atas perangkat sangat tidak nyaman. Jadi kami memutuskan (tentu saja, mengandalkan data) bahwa dalam aplikasi "Medusa", tombol "Kembali" di iOS akan berada di bawah. Tetapi di Android itu tidak akan sama sekali. Untuk melakukan ini, ada svaypas (kami sendiri dan svaypas Android baru) dan tombol sistem "Kembali".Kata kolega saya, direktur seni Medusa Nastya Yarovaya:Saya punya tangan kecil dan telepon besar. Tampaknya konyol, tetapi memengaruhi dua keputusan penting dalam proses pengembangan. Pertama, saya mengusulkan untuk secara signifikan meningkatkan kembali zona swipe (meningkat menjadi 50%) - penyimpangan pertama dari pedoman. Lalu, ketika kami bekerja pada tombol navigasi dan fungsi di dalam materi, saya menyarankan untuk meletakkan tombol kembali di menu umum di bawah ini - ini adalah penyimpangan lain dari pola yang biasa di antarmuka. Sekarang Anda dapat mencapainya dengan ibu jari Anda, karena mereka sebagian besar digulir olehnya.
Kami tahu bahwa kami pasti akan terbang karena kami telah melanggar sejumlah rekomendasi dari Apple dan Google. Tetapi, jika ada, kami juga menggunakan telepon dan memahami bahwa banyak pola sudah ketinggalan zaman, karena mereka diciptakan untuk perangkat hingga setengahnya.Sedikit latihan: cara kerjanya di Flutter
Setelah Bereaksi dan kerangka kerja reaktif lainnya, Anda dapat membuat prototipe di Flutter dalam beberapa hari. Gagasan umum Flutter - semuanya adalah widget. Flutter memberikan dua (sebenarnya tiga) paradigma: Anda dapat menggunakan widget material yang mengikuti konsep desain material. Anda dapat menggunakan widget Cupertino - widget yang terlihat dan berperilaku seperti di iOS. Dan Anda dapat menulis semuanya sendiri.Secara kasar, ada dua jenis widget yang berinteraksi dengan pengembang: stateless dan stateful.Widget stateless adalah widget plus atau minus yang tidak mengandung logika di dalamnya yang harus mengubah keadaan widget.Widget stateful memiliki fungsi setState (halo, bereaksi!). Anda mengubah status, dan widget digambar ulang.Tapi tentu saja, aplikasi besar pada setState sederhana tidak akan berjalan jauh, sehingga diperlukan solusi manajemen negara.Ada beberapa solusi untuk Flutter. Misalnya, ada pola BloC di mana aliran dan peristiwa dari sumber data digunakan, mereka mengandung logika bisnis yang memicu lahirnya peristiwa baru. Peristiwa ini didengar oleh widget, dan widget merespons perubahan.Mereka yang datang setelah Bereaksi mungkin ingin mencoba Redux. Secara teori, seharusnya tidak ada masalah jika Anda menulis dalam Bereaksi menggunakan pendekatan ini.Saya mencoba kedua pendekatan dan akhirnya memilih yang ketiga. Aplikasi Jellyfish menggunakan Penyedia. Ini adalah perpustakaan yang tidak ditulis oleh Google, tetapi menarik bahwa Google, setelah mencoba Provider di rumah, mulai meninggalkan BloC-nya dan bahkan memutuskan untuk mengulangi Provider sebagai perpustakaan yang terpisah. Tetapi pada akhirnya, dia meninggalkan ide untuk mengulang kode orang lain dan mulai menggunakan dan memelihara apa yang dilahirkan sebagai sumber terbuka.Perangkat Penyedia cukup sederhana. Ini adalah widget di mana ada keadaan. Status ini diubah oleh fungsi yang secara internal memanggil notifyListeners (). Widget yang harus merespons perubahan ada di pohon widget - mereka adalah anak-anak langsung dari penyedia widget atau anak-anak dari anak-anaknya. Ketika notifyListeners () dipanggil, anak-anak mendapatkan nilai baru melalui konteks dan membangun kembali terjadi.Biasanya, penyedia diiklankan di bagian paling atas aplikasi, dan Anda dapat menggunakan banyak penyedia sekaligus - masing-masing bertanggung jawab atas logika bisnisnya sendiri.Sekarang kami menggunakan delapan penyedia yang "mendengarkan" di berbagai tempat aplikasi. Misalnya, inilah cara kerja penyedia bookmark, berkat pembaca mana yang dapat menyimpan materi favorit mereka, membacanya secara offline dan dari tempat yang sama di perangkat yang berbeda.Reaksi ditambahkan ke instance ke perubahan pada dokumen dari Firebase, yang berisi kunci untuk bahan yang ditandai oleh pembaca. Untuk setiap onChange dokumen ini, variabel terkait dalam penyedia diperbarui dan notifyListeners dipanggil. Akibatnya, semua widget yang mendengarkan penyedia ini menunjukkan ikon yang benar.Melalui penyedia, tema aplikasi juga telah diaktifkan. Aplikasi ini memiliki ThemeProvider, yang di dalamnya sendiri berisi dua contoh tema - dan, pada kenyataannya, itu hanya Peta dengan penamaan warna dan warna itu sendiri.Hasilnya, warna yang benar muncul di widget seperti ini:TextSpan(
text: block['data']['first'],
style: TextStyle(
color: Provider.of<ThemeProvider>(context)
.current
.bodyFontColor,
fontFamily: 'Proxima Nova',
));
Kode penyedia, jika disederhanakan, akan menjadi:class ThemeProvider extends ChangeNotifier {
CustomThemeData current;
CustomThemeData blackTheme = CustomThemeData(
name: 'black',
bodyFontColor: Color.fromRGBO(184, 184, 184, 1),
...
);
CustomThemeData lightTheme = CustomThemeData(
name: 'black',
bodyFontColor: Color.fromRGBO(184, 184, 184, 1),
...
);
ThemeProvider(withTheme, withFontMultiplier, withAutoTheme) {
theme = withTheme;
autoTheme = withAutoTheme;
current = withTheme == 'light' ? lightTheme : blackTheme;
}
}
Dengan demikian, ketika Anda mengubah variabel saat ini, semua widget yang mengambil warna dari tema akan ditampilkan dengan benar tanpa kecuali.Apa berikutnya
Dalam beberapa minggu terakhir, kami telah secara aktif menguji aplikasi baru pada sekelompok ratusan pembaca Medusa. Kami akan memberi tahu Anda bagaimana pengujian dilakukan dalam artikel terpisah, tetapi saya hanya akan mencatat bahwa Flutter memenuhi semua harapan saya. Ya, ia memiliki cara untuk mengembangkan, ya, tidak semua perpustakaan kaya fitur, tetapi, mengamati kecepatan bergeraknya semua itu, saya, setidaknya untuk diri saya sendiri, menyimpulkan bahwa Flutter dengan Medusa akan berlangsung lama.