Kamu biasanya sudah siap untuk klien pengembangan Expo ketika saat itu Expo Go mulai berbohong.
Aplikasi berjalan di sandbox. Refresh cepat terasa hebat. Kemudian kamu menambahkan ketergantungan native, menghubungkan notifikasi push, menguji aliran OAuth, atau mencoba meniru cara aplikasi produksi kamu diluncurkan. Tiba-tiba kesenjangan menjadi jelas. Kamu tidak lagi menguji aplikasi kamu. Kamu 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 kamu kirimkan nanti. Untuk pengembang solo, itu berarti ada sedikit kejutan di akhir siklus. Untuk tim, itu berarti proses pengembangan yang dapat mendukung bangun bersama, QA, lingkungan pratinjau, dan validasi update tanpa berpura-pura Expo Go dapat menutupi segalanya.
Tabel Konten
- Mengapa Kamu Perlu Melangkah Lebih Jauh dari Expo Go
- Prasyarat dan Konfigurasi Proyek
- Membangun Klien Pribadi Anda dengan EAS
- Menggunakan dan Membuat Debug dengan Klien Baru Anda
- Integrasi dengan CI/CD dan Live Updates
- Mengatasi Kesulitan Umum dan Solusi
Mengapa Anda Perlu Melampaui Expo Go
Expo Go berguna pada awalnya. Ini menghilangkan gesekan pengaturan, 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 prototipe. Expo mendokumentasikan Expo Go sebagai laboratorium dan mencatat bahwa tidak dapat menyimulasikan dengan akurat beberapa kemampuan native seperti pemberitahuan atau autentikasi OAuth, sementara model pembangunan pengembangan dibangun sekitar expo-dev-client dan ditempatkan sebagai “Debug” build untuk aplikasi berkelas produksi dalam Pengenalan pembangunan Expo:.
Apa yang patah dahulu
Dalam prakteknya, patah dahulu biasanya salah satu dari ini:
- Ketergantungan native: Sebuah paket memerlukan native code yang tidak termasuk dalam Expo Go.
- Autentikasi: Aliran OAuth berperilaku berbeda ketika aplikasi menggunakan konfigurasi native yang sebenarnya.
- Pemberitahuan dan fitur perangkat: The sandbox tidak menampilkan bagaimana aplikasi produksi akan meminta izin atau menerima event.
- Tim QA: Seorang tester membutuhkan file biner stabil yang merepresentasikan pengaturan native asli aplikasi.
Itu bukan kasus sampingan. Mereka adalah tahap normal dalam proyek mobile nyata.
Expo Go sangat baik untuk membuktikan antarmuka. Namun, itu adalah tempat yang lemah untuk memvalidasi perilaku produksi.
Mengapa klien pengembang adalah langkah selanjutnya yang tepat
Klien pengembang Expo memberikan Anda aplikasi biner kustom dengan alat pengembang Expo yang dibangun di dalamnya. Artinya Anda tetap memiliki pengalaman pengembang yang kuat, tetapi layer native sekarang milik Anda. Klien yang terinstal menjadi hal yang tim Anda uji terhadapnya, bukan bergantung pada kontainer umum.
Pergeseran itu lebih penting daripada yang terdengar. Setelah Anda beralih ke klien kustom, pertanyaan berubah dari “apakah ini berjalan di Expo Go?” menjadi “apakah ini berfungsi di aplikasi yang kami bangun?” Itu adalah pertanyaan yang tepat.
Jika Anda juga membandingkan model pengiriman aplikasi yang lebih luas, tulisan Capgo tentang alternatif Expo bisa memberikan konteks yang berguna karena menyoroti di mana tim mulai mencari ke luar dari alur kerja sandbox. Pergeseran pikiran
Perubahan mindset
Menganggap pengaturan klien pengembang Expo seperti tugas pengaturan satu kali adalah kesalahan terbesar yang saya lihat. Ini bukanlah tugas pengaturan. Ini adalah pilihan alur kerja.
Anda menerima satu pertukaran untuk mendapatkan kendali:
| Alur Kerja | Apa yang tetap cepat | Apa yang memerlukan lebih banyak upacara |
|---|---|---|
| Expo Go | Iterasi JavaScript dasar | Apa saja yang bergantung pada kenyataan native |
| Klien pengembang Expo | Perubahan JavaScript di dalam aplikasi kustom | Perubahan ketergantungan native dan perubahan konfigurasi native |
Itu adalah pertukaran yang baik dalam pengembangan aplikasi profesional. Anda berhenti mengoptimalkan untuk demo yang paling mudah dan mulai mengoptimalkan untuk pengiriman yang dapat diandalkan.
Persyaratan dan Konfigurasi Proyek
Sebelum Anda membangun apa pun, pastikan proyek Anda dalam keadaan yang dapat bertahan dari build yang dapat diulang. Banyak percobaan pertama yang gagal berasal dari mengabaikan konfigurasi dasar, bukan dari Expo itu sendiri.
Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai “lingkungan pengembangan yang lengkap” yang mewakili lingkungan produksi nyata ketika aplikasi bergantung pada code native yang disesuaikan atau QA produksi tingkat, seperti yang dibahas dalam ringkasan Draftbit tentang Alat Pengembangan Expo dan Build Pengembangan.
Mulai dengan akun dan layer CLI
Anda memerlukan dua hal yang berfungsi sebelum layer aplikasi menjadi penting:
- Akses Expo CLI
- Akses EAS CLI
Anda juga ingin masuk ke akun Expo Anda dari terminal. Banyak tim sering mengabaikan hal ini karena perintah lokal dapat terlihat baik sampai build jarak jauh pertama atau prompt kredential muncul.
Konfigurasi yang bersih biasanya mencakup:
- Akun Expo Anda: Menghubungkan pekerjaan lokal dengan layanan pembangunan jarak jauh 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: Jangan memperkenalkan kompleksitas pembangunan sebelum aplikasi startup dasar berfungsi.
Instal paket yang membuat alur kerja ini mungkin
Pusat dari setup 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.
Instalnya 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.”
Aturan praktis: Bangun klien pengembangan sekali ketergantungan native daftar 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. Tidaklah. 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 build native dan tanda tangan nanti.
- Tujuan lingkungan yang jelas: Jika tim menggunakan identitas staging dan produksi yang terpisah, refleksikan itu secara sengaja.
Jika lingkungan lokal Anda berantakan, sebaiknya disederhanakan sebelum build pertama. Capgo's guide to Mengatur Capacitor lingkungan lokal Jangan lupa 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:
| Periksa | Mengapa hal ini penting |
|---|---|
expo-dev-client Terinstal | Mengaktifkan perilaku klien pengembangan kustom |
| Akun Expo terhubung | Diperlukan untuk penggunaan EAS yang lancar |
| Identifikasi aplikasi unik | Mencegah konflik pembangunan dan instalasi native |
| Project dimulai secara lokal | Menghindari masalah runtime dengan masalah build |
| Tim tahu kapan harus membangun ulang | Mengurangi kebingungan setelah perubahan native |
Tujuan bukanlah kesempurnaan. Tujuan adalah membuat build 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 build pengembangan untuk aplikasi dengan klien native code: install expo-dev-client, menghasilkan aplikasi native dengan EAS Build atau secara lokal, kemudian jalankan npx expo start --dev-clientExpo juga mencatat dalam ringkasan alur kerja 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:
- Instal dan autentikasi dengan EAS CLI
- Mulai atau konfirmasikan konfigurasi pembangunan
- Buat profil pembangunan
- Aktifkan pembangunan untuk iOS atau Android
- Instal hasil biner pada perangkat atau simulator
EAS memberikan konsistensi. Sebaliknya, setiap pengembang tidak perlu mengimprovisasi keadaan pembangunan native lokal, tim dapat menghasilkan biner dari definisi pembangunan bersama.
Apa yang profil pembangunan Anda lakukan sebenarnya
A development Profil bukan hanya label. Ia memberitahu sistem pembangunan bahwa biner ini dimaksudkan untuk pengembangan aktif, bukan distribusi toko.
Biasanya berarti aplikasi yang diinstal harus:
- termasuk perilaku klien pengembangan
- mudah untuk developer dan tester untuk meluncurkan
- terhubung ke server Metro selama pekerjaan sehari-hari
- tetap dapat digunakan kembali hingga ketergantungan native berubah
Hal ini juga merupakan tempat dimana CI menjadi lebih praktis. Setelah profil build 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-tim mengirimkan perubahan produk yang lebih sering di permukaan mobile.
Langkah-langkah singkat dapat membantu jika Anda ingin melihat aliran dalam aksi:
Menginstal hasilnya
Setelah build selesai, tatal output seperti aplikasi biner nyata karena itu apa yang dia adalah.
- Di Android: Kamu biasanya menginstal sebuah
.apkpada perangkat fisik atau emulator. - Di iOS: Kamu bekerja dengan sebuah
.ipaatau simulator yang kompatibel tergantung pada target. - Untuk rekan kerja: Bagikan build melalui mekanisme EAS normal bukan meminta setiap orang untuk membuat sendiri dari awal kecuali perlu.
Build pengembangan paling mudah diatur ketika tim setuju pada satu aturan: bangun ulang untuk perubahan native, bukan untuk setiap code perubahan.
Apa yang tidak harus diharapkan
Jangan harap build pertama menghilangkan kompleksitas native. Ini memindahkan kompleksitas ke tempat yang tepat.
Jika kamu menambahkan sebuah modul native baru, mengubah izin, memperbarui SDK-level dependensi native, atau memodifikasi konfigurasi native yang dikendalikan plugin, kamu memerlukan build pengembangan segar. Itu normal. Hadiahnya adalah bahwa pekerjaan JavaScript sehari-hari kamu masih bergerak cepat di dalam klien yang mencerminkan aplikasi kamu.
Berjalan dan Membaca Log dengan Klien Baru Anda
Pertama kali Anda membuka klien yang telah diinstal dan menghubungkannya ke Metro, perbedaan yang jelas. Ini terasa seperti Expo, tetapi tidak lagi dalam arti mainan.
Mulai server dengan npx expo start --dev-client Kemudian buka klien pengembangan di simulator, emulator, atau perangkat fisik Anda dan hubungkan melalui antarmuka pengguna peluncur. Peluncur itu adalah salah satu perubahan penting yang diperkenalkan oleh expo-dev-client, di samping dukungan debugging seperti inspeksi permintaan jaringan, seperti yang terdokumentasi di halaman Expo SDK page for dev client.
Sebuah Sesi Pengembangan Normal
Sesi pengembangan biasanya seperti ini:
Anda pull branch terbaru. Klien pengembangan yang telah diinstal sudah ada di perangkat Anda. Anda mulai Metro, meluncurkan aplikasi, dan menghubungkan 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 keluar dari lingkaran reguler Anda.
Alat debugging yang penting
Tidak ada alat tambahan yang hanya untuk tampilan. Alat ini menyelesaikan masalah sehari-hari.
- Antarmuka Launcher: Bermanfaat ketika Anda beralih antara lingkungan atau server yang dihosting oleh tim.
- Menu pengembang: Memberikan aksi yang Anda harapkan selama iterasi aktif.
- Pengintai jaringan: Membantu ketika antarmuka UI terlihat rusak tetapi masalah sebenarnya adalah gagal permintaan, status autentikasi, atau pengaturan lingkungan yang salah.
Jika API gagal ketika klien pengembang berjalan, inspect jalur permintaan dan asumsi lingkungan sebelum menyentuh UI code. Masalah seringkali berada di luar komponen yang Anda lihat.
Keuntungan praktisnya adalah: satu file biner yang terinstal dapat memvalidasi lingkungan yang berbeda tanpa harus merekompilasi setiap kali. Hal ini sangat membantu ketika seorang reviewer ingin menguji PR preview, seorang insinyur QA ingin menguji staging, dan seorang pengembang ingin menguji branch lokal.
Jika tim Anda juga mengirimkan shell mobile berbasis web, Capgo’s guide debugging ultimate untuk Capacitor apps bernilai membaca untuk disiplin debugging yang lebih luas. Alatnya berbeda, tetapi disiplinnya sama: inspect transport, lingkungan, dan perilaku waktu eksekusi sebelum menebak.
Apa yang berfungsi dengan baik dan apa yang tidak
Apa yang berfungsi dengan baik:
| Situasi | Mengapa klien pengembangan membantu |
|---|---|
| Menguji redirect autentikasi | Tindakan aplikasi asli lebih dekat dengan produksi |
| Mengverifikasi API integrasi | Inspeksi jaringan memperpendek siklus umpan balik |
| Mengganti lingkungan | Antarmuka UI peluncur menghindari rekonstruksi yang tidak perlu |
| QA tim di satu biner | Semua orang menguji setup asli yang sama |
What tidak berfungsi dengan baik:
- Menganggap klien sebagai barang yang dapat dibuang: Jika tim tidak memelihara, kebingungan akan muncul dengan cepat.
- Mengabaikan batasan pembaruan asli: Setelah ketergantungan asli berubah, klien kuno menghabiskan waktu.
- Menganggap semua gagal koneksi sebagai bug aplikasi: Banyak hanya masalah lingkungan lokal.
Integrasi dengan CI/CD dan Live Updates
Klien pengembangan Expo menjadi lebih berharga ketika berhenti menjadi pengaturan pribadi dan menjadi bagian dari operasi tim.
Alur kerja yang matang biasanya memisahkan kekhawatiran. Perubahan asli menghasilkan bangunan pengembangan baru. Perubahan JavaScript dan aset bergerak melalui jalur pembaruan yang lebih cepat. Peninjau dan QA tidak perlu bertanya apakah mereka sedang menguji hal yang tepat karena tim telah setuju pada saluran, profil bangunan, dan tujuan pembaruan.
Dimana CI/CD berada
The client pengembangan bekerja dengan baik dengan CI karena memberikan otomatisasi target yang stabil.
A pola umum tampak seperti ini:
- Perubahan pull request: CI membuat atau memvalidasi bangun pengembangan ketika dependensi native telah berubah.
- Environment berdasarkan cabang: Cabang yang berbeda menerjemahkan ke saluran pembaruan atau target server yang berbeda.
- Alur tester 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 memerlukan pembangunan ulang. Tester tahu apakah mereka memvalidasi perubahan native atau pembaruan yang disampaikan di atas biner yang sudah ada.
Peran pembaruan hidup
Klien pengembangan sering kali memungkinkan tim untuk menghemat operasi waktu yang paling banyak. Klien pengembangan adalah tempat yang kuat untuk memvalidasi perilaku pembaruan sebelum rilis karena dapat beralih antara server pengembangan dan pembaruan yang dipublikasikan dalam shell aplikasi yang mirip produksi, seperti yang dijelaskan sebelumnya dalam dokumentasi Expo.
Hal tersebut membuka pemisahan yang berguna:
| Ubah jenis | Rute pengiriman |
|---|---|
| Perubahan modul native baru atau izin | Buat build pengembangan baru |
| Perbaikan perilaku JavaScript | Publikasikan update |
| Perubahan salinan atau aset | Publikasikan update |
| Validasi lingkungan | Ganti saluran atau server di klien yang terpasang |
Untuk tim di luar stack Expo update, Capgo’s Panduan Integrasi CI/CD untuk update OTA secara daring menampilkan model operasional yang dapat dibandingkan di sisi Capacitor. Ini adalah salah satu pilihan untuk tim yang ingin memiliki saluran peluncuran yang dikendalikan dan otomatisasi seputar pengiriman update.
Polanya yang dapat diandalkan adalah sederhana. Bangun ketika ada perubahan native code. Publikasikan ketika binary yang diinstal sudah mengandung semua yang perubahan tersebut butuhkan.
Habits tim yang mencegah kekacauan
Pengaturan teknis yang penting, tetapi aturan operasional yang lebih penting:
- Berikan nama saluran dengan jelas:
staging,production, dan nama preview harus jelas. - Dokumentasikan trigger rebuild: Perubahan plugin, perubahan izin, atau perubahan native SDK tidak boleh menjadi keputusan subjektif.
- Tetapkan strategi satu klien yang dapat diinstal per lingkungan: Terlalu banyak variasi menciptakan kebisingan dukungan.
- Tetapkan validasi update secara eksplisit: Seseorang harus memastikan bahwa update dapat diterapkan dan meluncur di dalam binary yang sama yang tim harapkan.
At ini, klien pengembangan Expo berhenti menjadi kemudahan pengembang dan menjadi infrastruktur rilis.
Troubleshooting Kesalahan Umum dan Perbaikan
Banyak masalah klien pengembangan Expo yang biasa-biasa saja 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.
Masalah yang paling umum dan kurang dibahas 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 Expo Dev Client troubleshooting video.
Ketika klien tidak terhubung ke Metro
Masalah ini adalah yang paling memakan waktu karena terlihat seperti aplikasi yang rusak ketika aplikasi sering kali baik-baik saja.
Periksa hal-hal ini terlebih dahulu:
- Anggapan jaringan yang sama: Perangkat dan laptop mungkin terlihat terhubung sambil duduk di segmen yang terisolasi.
- Interferensi VPN: VPN korporasi atau pribadi dapat mengarahkan lalu lintas dalam cara yang tidak ditolerir Metro.
- Aturan firewall: Alat keamanan mungkin menghalangi lalu lintas pengembangan lokal tanpa membuatnya jelas.
- Aturan perangkat perusahaan: Perangkat yang diatur kadang-kadang mengganggu pola lalu lintas yang digunakan oleh alat pengembangan.
Jika proyek berjalan di simulator tetapi tidak di perangkat fisik, curigakan jaringan sebelum curigakan React code.
Tidak 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:
| Gejala | Penyebab yang mungkin | Pembetulan |
|---|---|---|
| JavaScript updates diterapkan secara normal | Sikap yang diharapkan | Terus bekerja di klien yang ada |
| Ketergantungan native baru tidak muncul | Layer native berubah | Buatlah bangun baru pengembangan |
| Sikap yang terkait izin tidak konsisten | Konfigurasi native berubah | Rebuild dan reinstall |
| Seorang rekan tim melihat perilaku yang berbeda | Biner klien yang berbeda terinstal | Sesuaikan pada bangun yang sama |
Ini bukan kelemahan dalam alur kerja. Ini adalah alur kerja yang melakukan apa yang harus dilakukan.
Kegagalan bangun dan perubahan tim
Ketika bangun gagal, penyebab utama seringkali salah satu dari ini:
- Tidak sesuai versi ketergantungan: Versi paket tidak sesuai dengan proyek lainnya.
- Asumsi plugin native: Konfigurasi plugin mengharapkan setup proyek tidak memiliki.
- Kemusnahan kredensial: Tanda tangan atau akses akun tidak konsisten di tim.
- Harapan lokal yang ketinggalan: Seseorang menganggap bangun segar tidak diperlukan ketika sebenarnya perlu.
Capgo's artikel pada masalah dan solusi pembaruan hidup untuk pengembang bermanfaat sebagai bacaan tambahan untuk sisi rilis masalah ini. Berbeda stack, pelajaran yang sama: banyak “masalah aplikasi” sebenarnya adalah masalah pengiriman, lingkungan, atau versi-alignment.
Klien pengembangan Expo bekerja dengan baik ketika tim menganggap keandalan lingkungan sebagai bagian dari teknik. Bukan sebagai hal yang dianggap terakhir. Setelah Anda melakukan itu, pengaturan menjadi prediktif, dan prediktif adalah apa yang Anda inginkan dari alat mobile.
Jika tim Anda juga mengirimkan aplikasi Capacitor dan membutuhkan cara yang terkendali untuk mengirimkan pembaruan JavaScript, aset, dan konfigurasi tanpa menunggu ulasan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan hidup, kontrol perluasan, dan integrasi CI/CD untuk Capacitor dan Electron.
