Petunjuk Lengkap untuk Klien Pengembang Expo

Biasanya Anda sudah siap untuk klien pengembangan Expo ketika poin akurat Expo Go mulai berbohong.

Aplikasi berjalan di sandbox. Refresh cepat terasa hebat. Kemudian Anda menambahkan ketergantungan native, menghubungkan notifikasi push, menguji aliran OAuth, atau mencoba meniru cara aplikasi produksi Anda diluncurkan. Tiba-tiba kesenjangan menjadi jelas. Anda tidak lagi menguji aplikasi Anda. Anda sedang menguji lingkungan yang disederhanakan.

Itu di mana klien pengembangan Expo mengubah alur kerja. Ini menjaga loop JavaScript cepat yang orang suka tentang Expo, tetapi memindahkan pengujian ke biner native yang disesuaikan yang berperilaku lebih seperti aplikasi yang akan Anda kirim nanti. Untuk pengembang solo, itu berarti ada sedikit kejutan di akhir siklus. Untuk tim, itu berarti proses pengembangan yang dapat mendukung bangunan bersama, QA, lingkungan pratinjau, dan validasi pembaruan tanpa berpura-pura Expo Go dapat menutupi segalanya.

Daftar Isi

• Mengapa Anda Perlu Melangkah Lebih Jauh dari Expo Go
  • Apa yang patah terlebih dahulu
  • Mengapa klien pengembangan adalah langkah selanjutnya yang tepat
  • Perubahan mindset
• Persyaratan dan Konfigurasi Proyek
  • Mulai dengan akun dan lapisan CLI
  • Pasang paket yang membuat alur kerja mungkin
  • Periksa konfigurasi aplikasi Anda sebelumnya
  • Apa yang terlihat seperti konfigurasi awal yang baik
• Membangun Klien Pribadi Anda dengan EAS
  • Alur dasar EAS
  • Apa yang sebenarnya dilakukan profil build Anda
  • Menginstal hasilnya
  • Apa yang tidak harus Anda harapkan
• Menggunakan dan Mengdebug dengan Klien Baru Anda
  • Sesi pengembangan normal
  • Alat debug yang penting
  • Apa yang berfungsi dengan baik dan apa yang tidak
• Mengintegrasikan dengan CI/CD dan Live Updates
  • Di mana CI/CD berada
  • Peran live updates
  • Kebiasaan tim yang mencegah kekacauan
• Mengatasi Kesulitan Umum dan Solusi
  • Ketika klien tidak terhubung ke Metro
  • Ketika rekonstruksi tampak acak
  • Gagal bangun dan pergeseran tim

Mengapa Anda Perlu Melampaui Expo Go

Expo Go berguna pada awalnya. Ini menghilangkan gesekan setup, membuat proyek React Native berjalan dengan cepat, dan memberikan Anda loop feedback cepat. Itu tepatnya mengapa banyak tim memulai dari sana.

Masalah dimulai ketika aplikasi tidak lagi sebagai prototipe. Dokumen Expo menyebutkan Expo Go sebagai "sandbox" dan mencatat bahwa ia tidak dapat mengakurasi beberapa kemampuan native seperti pemberitahuan atau autentikasi OAuth, sementara model pembangunan pengembang dibangun di sekitar dan diposisikan sebagai "Debug" build untuk aplikasi berkelas produksi, dalam "Pengenalan Pembangunan Expo". Tabel perbandingan yang menjelaskan perbedaan dan keterbatasan utama antara Expo Go dan Expo Development Client. Apa yang patah terlebih dahulu expo-dev-client Dalam prakteknya, patah terlebih dahulu biasanya salah satu dari ini: Ketergantungan native: Sebuah paket memerlukan __CAPGO_KEEP_0__ native yang tidak termasuk dalam Expo Go. Sebuah paket memerlukan __CAPGO_KEEP_0__ native yang tidak termasuk dalam Expo Go..

Sebuah paket memerlukan __CAPGO_KEEP_0__ native yang tidak termasuk dalam Expo Go.

Sebuah paket memerlukan __CAPGO_KEEP_0__ native yang tidak termasuk dalam Expo Go.

• Sebuah paket memerlukan __CAPGO_KEEP_0__ native yang tidak termasuk dalam Expo Go. Sebuah paket memerlukan code native yang tidak termasuk dalam Expo Go.
• Autentikasi: Alur OAuth berperilaku berbeda ketika aplikasi menggunakan konfigurasi native yang sebenarnya.
• Pemberitahuan dan fitur perangkat: Sandbox tidak mencerminkan bagaimana aplikasi produksi akan meminta izin atau menerima event.
• Tim QA: Seorang tester membutuhkan file biner yang stabil yang merepresentasikan pengaturan native aplikasi yang sebenarnya.

Itu bukan kasus sampingan. Itu adalah tahap normal dalam proyek mobile yang sebenarnya.

Expo Go adalah bagus untuk membuktikan antarmuka. Namun, itu adalah tempat yang lemah untuk memvalidasi perilaku produksi.

Mengapa klien pengembang adalah langkah yang tepat berikutnya

Klien pengembang Expo memberikan Anda file biner aplikasi yang disesuaikan dengan alat pengembang Expo yang dibangun di dalamnya. Artinya Anda tetap memiliki pengalaman pengembang yang kuat, tetapi lapisan native sekarang milik Anda. Klien yang terpasang menjadi hal yang tim Anda tes terhadap, bukan bergantung pada kontainer yang umum.

Perubahan itu lebih penting daripada yang terdengar. Setelah Anda beralih ke klien yang disesuaikan, pertanyaan berubah dari “apakah ini berjalan di Expo Go?” menjadi “apakah ini berfungsi di aplikasi yang kami bangun?” Pertanyaan itu yang tepat.

Jika Anda juga membandingkan model pengiriman aplikasi yang lebih luas, Capgo’s tulisan tentang alternatif dari Expo banyak berguna karena menyoroti tempat tim mulai mencari ke luar dari alur kerja sandbox.

Perubahan mindset

Sangat besar kesalahan yang saya lihat adalah menganggap klien pengembangan Expo seperti tugas pengaturan satu kali. Tidak. Ini adalah pilihan alur kerja.

Anda menerima satu perdagangan untuk mendapatkan kontrol:

Itu adalah perdagangan yang baik dalam pengembangan aplikasi profesional. Anda berhenti mengoptimalkan untuk demo yang paling mudah dan mulai mengoptimalkan untuk pengiriman yang dapat diandalkan.

Prasyarat dan Konfigurasi Proyek

Sebelum Anda membangun apa pun, pastikan proyek Anda dalam keadaan yang dapat bertahan dari build yang dapat diulang. Banyak usaha pertama yang gagal datang dari melupakan konfigurasi dasar, bukan dari Expo itu sendiri.

Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai “lingkungan pengembangan yang lengkap” yang mewakili lingkungan produksi yang nyata sekali aplikasi bergantung pada native code atau QA yang berkualitas tinggi, seperti yang dibahas dalam ringkasan Draftbit tentang Alat pengembangan Expo dan build pengembangan.

Mulai dengan akun dan layer CLI

Anda membutuhkan dua hal yang berfungsi sebelum layer aplikasi menjadi penting:

1. Akses Expo ke CLI
2. Akses CLI EAS

Anda juga ingin masuk ke akun Expo Anda dari terminal. Tim seringkali mengabaikan hal ini karena perintah lokal dapat terlihat baik sampai build remote pertama atau prompt kredential muncul.

Penataan yang bersih biasanya mencakup:

• Session akun Expo Anda: Hal ini menghubungkan kerja lokal dengan layanan build remote dan kepemilikan proyek.
• EAS CLI terinstal: EAS adalah yang mengubah proyek Anda menjadi binary iOS atau Android yang dapat dibagikan.
• Proyek yang sudah berjalan lokal: Tidak masukkan kompleksitas build sebelum aplikasi startup dasar berfungsi.

Instal paket yang membuat alur kerja ini mungkin

Pusat dari penataan ini adalah expo-dev-client. Tanpa itu, Anda tidak memiliki launcher kustom dan shell native yang berorientasi debug yang mendefinisikan alur kerja klien pengembangan Expo.

Instalasinya di proyek aplikasi, lalu verifikasi konfigurasi Expo Anda konsisten. Perintah yang tepat mungkin berbeda dengan manajer paket Anda, tetapi titik arsitektur tidak: paket ini yang mengubah aplikasi dari “berjalan di sandbox bersama” menjadi “berjalan di dalam binary pengembangan kami sendiri.”

Aturan praktis: Bangun klien pengembangan sekali daftar ketergantungan native stabil cukup untuk rekan tim menginstal dan menggunakan binary yang sama.

Periksa konfigurasi aplikasi Anda sejak awal

Banyak kebingungan datang dari menganggap app.json atau app.config.js sebagai metadata saja. Tidak. File-file ini menentukan identitas.

Pastikan proyek memiliki:

• Nama aplikasi unik: Bermanfaat ketika pengembang menginstal variasi yang berbeda pada satu perangkat.
• Identifikasi paket atau bundle unik: Kritis untuk pembangunan native dan tanda tangan nanti.
• Mengosongkan lingkungan tujuan: Jika tim menggunakan identitas staging dan produksi yang terpisah, refleksikan itu secara sengaja.

Jika lingkungan lokal Anda berantakan, sebaiknya menyempurnakannya sebelum build pertama. Capgo’s panduan untuk mengatur lingkungan lokal Capacitor tidak khusus Expo, tetapi itu adalah pengingat yang baik bahwa pekerjaan mobile yang dapat direproduksi dimulai dengan perangkat lunak lokal yang stabil dan konfigurasi eksplisit.

Apa yang terlihat seperti konfigurasi yang baik

Gunakan daftar periksa ini sebelum memulai EAS:

Tujuan bukanlah kesempurnaan. Tujuan adalah membuat pembangunan pertama menjadi menarik. Itu adalah kemenangan.

Membangun Klien Pribadi Anda dengan EAS

Ini adalah titik di mana alur kerja menjadi nyata. Anda berhenti berbicara tentang klien pribadi dan menghasilkan satu.

Expo merekomendasikan alur kerja pembangunan untuk aplikasi dengan klien native code: install expo-dev-clientgenerate aplikasi native dengan EAS Build atau secara lokal, kemudian jalankan npx expo start --dev-client. Expo juga mencatat dalam workflow overview bahwa perubahan JavaScript hanya saja tetap cepat, sementara perubahan native-code memerlukan build pengembangan baru.

Alur dasar EAS

Urutan ini sederhana meskipun langkah pertama terasa asing:

1. Pasang dan autentikasi dengan EAS CLI
2. Inisialisasi atau konfirmasi konfigurasi build
3. Buat profil build pengembangan
4. Aktifkan build untuk iOS atau Android
5. Pasang binary hasilnya pada perangkat atau simulator

Apa yang EAS berikan adalah konsistensi. Sebaliknya, setiap pengembang tidak perlu mengimprovisasi kondisi build native lokal, tim dapat menghasilkan binary dari definisi build bersama.

Apa yang profil pembangunan Anda sebenarnya lakukan

A development Profil bukan hanya label. Ini memberitahu sistem pembangunan bahwa biner ini dimaksudkan untuk pengembangan aktif, bukan distribusi toko.

Biasanya berarti aplikasi yang diinstal harus:

• menggunakan perilaku klien pengembangan
• mudah diluncurkan oleh pengembang dan tes
• terhubung ke server Metro selama pekerjaan sehari-hari
• tetap dapat digunakan kembali hingga ketergantungan native berubah

Hal ini juga merupakan tempat di mana CI menjadi lebih praktis. Setelah profil pembangunan ada dan berperilaku secara prediktif, Anda dapat mengotomatisasinya.

Jika tim Anda berpikir lebih luas tentang bagaimana React Native masuk ke dalam pekerjaan modernisasi yang lebih besar, Wonderment Apps memiliki perspektif yang berguna tentang React Native untuk modernisasi AI. Ini relevan karena klien pengembangan seringkali menjadi lapisan dasar operasional ketika tim mengirimkan perubahan produk yang lebih sering melalui permukaan mobile.

Akan membantu jika Anda ingin melihat aliran dalam aksi:

Menginstal hasilnya

Saat proses build selesai, terapkan output seperti aplikasi biner nyata, karena itu apa yang terjadi.

• Pada Android: Umumnya Anda akan menginstal sebuah .apk pada perangkat fisik atau emulator.
• Pada iOS: Kamu akan bekerja dengan sebuah .ipa atau output yang kompatibel dengan simulator tergantung pada target.
• Untuk rekan tim: Bagikan build melalui mekanisme EAS normal daripada meminta setiap orang untuk membuat sendiri dari awal kecuali perlu.

Build pengembangan paling mudah dikelola ketika tim setuju pada satu aturan: rebuild untuk perubahan asli, bukan untuk setiap code perubahan.

Apa yang tidak harus diharapkan

Jangan harap pembangunan pertama dapat menghilangkan kompleksitas asli. Pembangunan tersebut menempatkan kompleksitas tersebut di tempat yang tepat.

Jika Anda menambahkan modul asli baru, mengubah izin, memperbarui SDK-level dependensi asli, atau memodifikasi pengaturan konfigurasi asli yang dikendalikan oleh plugin, Anda akan memerlukan pembangunan klien baru. Hal tersebut normal. Hadiahnya adalah bahwa pekerjaan JavaScript sehari-hari Anda masih bergerak cepat di dalam klien yang mencerminkan aplikasi Anda.

Menggunakan dan Membangun dengan Klien Baru

Kali pertama Anda membuka klien yang telah diinstal dan menghubungkannya ke Metro, perbedaan tersebut jelas. Hal tersebut terasa seperti Expo, tetapi tidak lagi dalam arti mainan.

Mulai server dengan npx expo start --dev-clientLalu buka klien pengembangan di simulator, emulator, atau perangkat fisik dan hubungkan melalui antarmuka pengguna peluncur. Peluncur tersebut salah satu perubahan penting yang diperkenalkan oleh expo-dev-client, di samping dukungan pembangunan seperti inspeksi permintaan jaringan, seperti yang terdokumentasi di Halaman SDK Expo untuk klien pengembangan.

Sesi pengembangan normal

Sesi normal terlihat seperti ini:

Anda pull branch terbaru. Klien pengembangan yang terpasang sudah ada di perangkat Anda. Anda menjalankan Metro, meluncurkan aplikasi, dan terhubung ke server saat ini. Kemudian Anda bekerja sebagaimana biasa, mengubah JavaScript dan melihat perubahan dengan cepat.

Perbedaan besar muncul ketika Anda membutuhkan untuk memeriksa perilaku yang bergantung pada lingkungan native yang nyata. Klien khusus memungkinkan Anda untuk menguji aliran-aliran tersebut tanpa harus keluar dari lingkaran reguler Anda.

Alat-alat debugging yang penting

Alat tambahan bukanlah dekoratif. Alat ini menyelesaikan masalah-masalah sehari-hari.

• Antarmuka Launcher: Bermanfaat ketika Anda beralih antara lingkungan atau server yang dihosting oleh tim.
• Menu pengembang: Memberikan aksi-aksi yang Anda harapkan selama iterasi aktif.
• Penginspeksi jaringan: Membantu ketika UI terlihat rusak tetapi masalah sebenarnya adalah gagal permintaan, status autentikasi, atau pengaturan lingkungan yang salah.

Ketika API gagal dalam klien pengembangan, periksa jalur permintaan dan asumsi lingkungan sebelum menyentuh UI code. Masalah sering kali berada di luar komponen yang Anda lihat.

Keuntungan praktisnya adalah sebagai berikut. Satu file biner yang terpasang dapat memvalidasi lingkungan-lingkungan yang berbeda tanpa harus merekompilasi setiap kali. Hal ini sangat membantu ketika seorang reviewer ingin menguji pratinjau PR, seorang insinyur QA ingin menguji staging, dan seorang pengembang ingin menguji branch lokal.

Jika tim Anda juga mengirimkan shell mobile berbasis web, panduan akhir Capgo’s panduan debugging akhir Capacitor adalah patut dibaca untuk disiplin debugging yang lebih luas. Alat-alatnya berbeda, tetapi disiplinnya sama: inspeksi perilaku transportasi, lingkungan, dan runtime sebelum menebak.

Apa yang baik dan apa yang tidak baik

Apa yang baik:

Apa yang tidak berjalan dengan baik:

• Menganggap klien sebagai barang yang dapat dibuang: Jika tim tidak memelihara, kebingungan akan menyebar dengan cepat.
• Mengabaikan batasan pembangunan native: Saat ketergantungan native berubah, klien kuno menghabiskan waktu.
• Menganggap semua gagal koneksi sebagai bug aplikasi: Banyak yang hanya masalah lingkungan lokal.

Mengintegrasikan dengan CI/CD dan Live Updates

Klien pengembangan Expo menjadi lebih berharga ketika berhenti menjadi setup pribadi dan menjadi bagian dari operasi tim.

Suatu alur kerja yang matang biasanya memisahkan kekhawatiran. Perubahan asli menghasilkan sebuah build pengembangan baru. Perubahan JavaScript dan aset melalui jalur pembaruan yang lebih cepat. Reviewer dan QA tidak perlu bertanya apakah mereka sedang menguji hal yang tepat karena tim telah setuju pada saluran, profil build, dan tujuan pembaruan.

Di mana CI/CD berada

Klien pengembangan bekerja dengan baik dengan CI karena memberikan otomatisasi target yang stabil.

Polanya yang umum seperti ini:

• Perubahan pull request: CI membuat atau memvalidasi sebuah build pengembangan ketika dependensi asli telah berubah.
• Sistem lingkungan berdasarkan cabang: Cabang yang berbeda mewakili saluran pembaruan atau target server yang berbeda.
• Alur kerja tester yang bersama: QA menginstal satu atau lebih klien dev yang diketahui dan mengganti konteks melalui launcher dan konfigurasi pembaruan.

Struktur tersebut mengurangi ketidakjelasan. Pengembang tahu kapan mereka perlu melakukan rebuild. Tester tahu apakah mereka sedang menguji perubahan asli atau pembaruan yang disampaikan di atas sebuah binary yang sudah ada.

Peran live update

Klien pengembangan seringkali memungkinkan tim untuk menghemat waktu operasional terbanyak. Klien pengembangan adalah tempat yang kuat untuk memvalidasi perilaku update sebelum rilis karena dapat beralih antara server pengembangan dan update yang dipublikasikan dalam shell aplikasi yang mirip produksi, seperti yang dijelaskan sebelumnya dalam dokumentasi Expo.

Itu membuka pembagian yang berguna:

Untuk tim di luar stack Expo update, Capgo’s panduan integrasi CI/CD untuk pembaruan OTA menunjukkan model operasional yang sama pada sisi Capgo. Ini adalah salah satu pilihan untuk tim yang ingin memiliki saluran peluncuran yang dikendalikan dan otomatisasi seputar pengiriman pembaruan. Polanya yang dapat diandalkan adalah sederhana. Bangun ketika ada perubahan native Capacitor. Publikasikan ketika binary yang terpasang sudah mengandung semua yang dibutuhkan perubahan.

The reliable pattern is simple. Build when native code changes. Publish when the installed binary already contains everything the change needs.

Pengaturan teknis penting, tetapi aturan operasional lebih penting:

Berikan nama saluran dengan jelas:

• dan nama preview harus jelas. staging, productionDokumentasikan trigger rebuild:
• Pembaruan plugin, perubahan izin, atau pembaruan native __CAPGO_KEEP_0__ tidak boleh menjadi keputusan subjektif. New plugin, permission change, or native SDK update should never be a judgment call.
• Ubah saluran atau server di klien yang terpasang Terlalu banyak variasi menciptakan kebisingan dukungan.
• Buat validasi update menjadi eksplisit: Seseorang harus memastikan bahwa update diterapkan dan meluncur di dalam biner yang sama yang tim harapkan.

Pada titik ini, klien pengembangan Expo tidak lagi menjadi kemudahan pengembang dan menjadi infrastruktur rilis.

Mengatasi Kesulitan Umum dan Perbaikan

Masalah klien pengembangan Expo paling umum biasanya menjadi biasa jika Anda tahu di mana harus mencari. Mereka terasa misterius karena kegagalan sering terjadi di batas-batas: laptop ke perangkat, Metro ke aplikasi, konfigurasi native ke runtime JavaScript.

Salah satu masalah paling umum dan tidak dibahas secara luas adalah gagal terhubung ke Metro pada perangkat fisik karena segmentasi jaringan lokal, VPN, atau aturan firewall di lingkungan perusahaan dan tim yang terdistribusi, sebuah poin yang dibahas dalam video ini Mengatasi Masalah Klien Dev Expo.

Ketika klien tidak terhubung ke Metro

Masalah ini adalah yang paling memakan waktu karena terlihat seperti aplikasi yang rusak ketika aplikasi sering kali baik.

Periksa hal-hal ini terlebih dahulu:

• Asumsi jaringan yang sama: Perangkat dan laptop mungkin terlihat terhubung sambil duduk di segmen terisolasi.
• Interferensi VPN: VPN perusahaan atau pribadi dapat mengarahkan lalu lintas dalam cara yang Metro tidak tolerir dengan baik.
• Aturan firewall: Alat keamanan mungkin menghalangi lalu lintas pengembangan lokal tanpa membuatnya jelas.
• Kebijakan perangkat perusahaan: Perangkat yang dikelola kadang-kadang menghambat pola lalu lintas yang digunakan oleh alat pengembangan.

Jika proyek berjalan di simulator tetapi tidak di perangkat fisik, curigai jaringan sebelum curigai React code.

Jangan debug gagal koneksi dari dalam aplikasi terlebih dahulu. Konfirmasi perangkat dapat mencapai mesin yang menjalankan Metro.

Ketika rebuild tampak acak

Kesulitan lain yang umum adalah perasaan bahwa beberapa perubahan muncul secara instan dan lain-lain dengan berkeras tidak.

Biasanya berarti tim belum memahami batas rebuild:

Ini bukanlah kelemahan dalam alur kerja. Ini adalah alur kerja yang melakukan apa yang seharusnya dilakukan.

Kegagalan build dan pergeseran tim

Ketika build gagal, penyebab utamanya sering kali salah satu dari ini:

• Kesalahan dependensi: Versi paket tidak sejalan dengan proyek lainnya.
• Asumsi plugin native: Plugin konfigurasi mengharapkan setup proyek yang tidak ada.
• Kemusnahan kredensial: Tanda tangan atau akses akun tidak konsisten di seluruh tim.
• Harusnya diharapkan lokal: Seseorang menganggap bahwa pembangunan ulang tidak diperlukan ketika sebenarnya perlu.

Capgo’s artikel tentang masalah dan solusi pembaruan hidup yang umum untuk pengembang adalah bacaan tambahan yang berguna untuk sisi rilis dari masalah ini. Mengapa pelajaran yang sama tetap relevan: banyak ‘bug aplikasi’ sebenarnya adalah bug pengiriman, lingkungan, atau versi-alignment.

Klien pengembangan Expo bekerja dengan baik ketika tim menganggap keandalan lingkungan sebagai bagian dari keahlian. Bukan sebagai hal yang dianggap remeh. Setelah Anda melakukannya, pengaturan menjadi lebih terprediksi, dan terprediksi adalah apa yang Anda inginkan dari alat mobile.

Jika tim Anda juga mengirimkan aplikasi Capacitor dan membutuhkan cara yang terkendali untuk mengirimkan pembaruan JavaScript, asset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan hidup, kontrol peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron.