Anda biasanya sudah siap untuk klien pengembangan Expo ketika poin ini dimulai. Expo Go mulai berbohong kepada Anda.
Aplikasi ini berjalan di sandbox. Refresh cepat terasa hebat. Kemudian Anda menambahkan ketergantungan native, menghubungkan push notifications, menguji aliran OAuth, atau mencoba meniru cara aplikasi produksi Anda diluncurkan. Tiba-tiba kesenjangan menjadi jelas. Anda tidak lagi menguji aplikasi Anda. Anda menguji lingkungan yang disederhanakan.
Itu adalah saat klien pengembangan Expo mengubah alur kerja. Ini mempertahankan loop JavaScript cepat yang orang sukai tentang Expo, tetapi memindahkan pengujian ke biner native yang disesuaikan yang berperilaku lebih seperti aplikasi yang akan Anda kirimkan. 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 bahwa Expo Go dapat menutupi segalanya.
Daftar Isi
- Mengapa Anda Perlu Melangkah Lebih Jauh dari Expo Go
- Prasyarat dan Konfigurasi Proyek
- Membangun Klien Custom Anda dengan EAS
- Menggunakan dan Mengdebug dengan Klien Baru Anda
- Mengintegrasikan dengan CI/CD dan Live Updates
- Mengatasi Kesulitan Umum dan Solusi
Mengapa Anda Perlu Bergerak Lebih Jauh dari Expo Go
Expo Go berguna di awal. Ini menghilangkan gesekan setup, membuat proyek React Native berjalan cepat, dan memberikan Anda loop feedback cepat. Itu tepatnya mengapa banyak tim memulai dari sana.
Masalah dimulai ketika aplikasi tidak lagi prototipe. Dokumen Expo menyebutkan Expo Go sebagai sand box dan mencatat bahwa itu tidak dapat menghasilkan simulasi yang akurat beberapa kemampuan native seperti pemberitahuan atau autentikasi OAuth, sementara model pembangunan pengembang dibangun di sekitar expo-dev-client dan diposisikan sebagai “Debug” build untuk aplikasi berkelas produksi di pengenalan pembangunan Expo.
Apa yang patah dahulu
Dalam prakteknya, kerusakan pertama biasanya salah satu dari hal-hal berikut:
- Ketergantungan native: Sebuah paket memerlukan code native yang tidak ada di Expo Go.
- Autentikasi: Alur OAuth berperilaku berbeda ketika aplikasi menggunakan konfigurasi native yang sebenarnya.
- Pemberitahuan dan fitur perangkat: Sand box tidak mencerminkan bagaimana aplikasi produksi akan meminta izin atau menerima event.
- QA Tim: Seorang tester memerlukan file biner stabil yang mewakili pengaturan native aplikasi yang sebenarnya.
Kerusakan-kerusakan itu bukanlah kasus sampingan. Mereka adalah tahap normal dalam proyek mobile yang nyata.
Expo Go sangat baik untuk membuktikan antarmuka. Namun, itu merupakan tempat yang lemah untuk memvalidasi perilaku produksi.
Mengapa klien pengembangan adalah langkah selanjutnya yang tepat
Klien pengembangan Expo memberikan Anda aplikasi biner kustom dengan alat pengembangan 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 uji, bukan bergantung pada kontainer generic.
Perubahan 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?” Pertanyaan itu yang tepat.
Jika Anda juga membandingkan model pengiriman aplikasi yang lebih luas, tulisan Capgo tentang alternatif Expo adalah konteks yang berguna karena menyoroti di mana tim mulai mencari ke luar dari alur kerja sandbox. Pergeseran mindset
Kesalahan terbesar yang saya lihat adalah menganggap klien pengembangan Expo sebagai tugas pengaturan satu kali. Tidak, itu merupakan pilihan alur kerja.
Anda menerima satu kekurangan untuk mendapatkan kontrol:
Alur Kerja
| Apa yang tetap cepat | Mengapa klien pengembangan adalah langkah selanjutnya yang tepat | Apa yang memerlukan lebih banyak upacara |
|---|---|---|
| Expo Go | Iterasi JavaScript dasar | Apa saja yang bergantung pada kenyataan asli native |
| Klien pengembang Expo | Perubahan JavaScript di dalam aplikasi khusus | Perubahan ketergantungan native dan perubahan konfigurasi native |
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 sendiri.
Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai “lingkungan pengembangan yang lengkap dan terkenal” itu merupakan representasi lingkungan produksi nyata ketika aplikasi bergantung pada kode native code atau pengujian kualitas produksi, seperti yang dibahas dalam ringkasan Draftbit tentang Alat dev Expo dan pembangunan aplikasi.
Mulai dengan lapisan akun dan CLI
Anda memerlukan dua hal yang berfungsi sebelum lapisan aplikasi menjadi penting:
- Akses Expo CLI
- Akses EAS CLI
Anda juga ingin terus masuk ke akun Expo Anda dari terminal. Banyak tim seringkali melupakan hal ini karena perintah lokal dapat terlihat baik sampai build remote pertama atau prompt kredit muncul.
Konfigurasi yang bersih biasanya mencakup:
- Sesi 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 yang dapat dibagikan iOS atau Android.
- A project yang sudah berjalan di lokal: Tidak perkenalkan kompleksitas pembangunan sebelum aplikasi startup dasar berfungsi.
Install paket yang membuat alur kerja 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.
Install di proyek aplikasi, kemudian 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 kita sendiri."
Aturan praktis: Bangun klien pengembangan sekali ketergantungan native sudah stabil cukup untuk rekan tim menginstal dan menggunakan binary yang sama.
Periksa konfigurasi aplikasi Anda awalnya
Banyak kebingungan datang dari menganggap app.json atau app.config.js atau metadata saja. Tidak. File-file ini mendefinisikan identitas.
Pastikan proyek memiliki:
- Nama aplikasi unik: Terutama berguna ketika pengembang menginstal variasi yang berbeda pada satu perangkat.
- Identifikasi paket atau bundle unik: Kritis untuk pembangunan asli dan tanda tangan nanti.
- Intensi lingkungan yang jelas: Jika tim menggunakan identitas staging dan produksi yang terpisah, refleksikan itu dengan sengaja.
Jika lingkungan lokal Anda berantakan, sebaiknya memperbaiki sebelum pembangunan pertama. Panduan Capgo untuk mengatur lingkungan lokal Capacitor Tidak khusus Expo, tetapi itu adalah pengingat yang baik bahwa kerja mobile yang dapat direproduksi dimulai dengan perangkat lunak lokal yang stabil dan konfigurasi eksplisit.
Apa konfigurasi yang baik pertama kali seperti itu
Pakai daftar periksa ini sebelum memulai EAS:
| Periksa | Mengapa hal ini penting |
|---|---|
expo-dev-client terpasang |
Mengaktifkan perilaku klien pengembangan kustom |
| Akun Expo terhubung | Diperlukan untuk penggunaan EAS yang lancar |
| Identifikasi aplikasi unik | Mencegah konflik pembangunan native dan instalasi |
| Projek dimulai secara lokal | Menghindari campuran masalah runtime dengan masalah pembangunan |
| Tim tahu kapan harus membangun ulang | Mengurangi kebingungan setelah perubahan native |
Tujuan bukanlah sempurna. Tujuan adalah membuat build pertama menjadi menarik. Itu adalah kemenangan.
Membangun Klien Kustom Anda dengan EAS
Titik ini adalah di mana alur kerja menjadi nyata. Anda berhenti berbicara tentang klien kustom dan menghasilkannya.
Expo merekomendasikan alur kerja build pengembangan untuk aplikasi dengan klien native kustom code: instal expo-dev-clientgenerate aplikasi native dengan EAS Build atau secara lokal, lalu jalankan npx expo start --dev-client. Expo juga mencatat dalam ringkasan alur kerja bahwa perubahan JavaScript hanya saja 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
- Menginisialisasi atau memastikan konfigurasi pembangunan
- Membuat profil pembangunan untuk pengembang
- Mengaktifkan pembangunan untuk iOS atau Android
- Menginstal hasil biner pada perangkat atau simulator
Yang diberikan oleh EAS adalah konsistensi. Sebaliknya dari setiap pengembang yang mengimprovisasi keadaan pembangunan native lokal, tim dapat menghasilkan biner dari definisi pembangunan bersama.
Mengapa profil pembangunan Anda melakukan hal ini
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:
- mengandung perilaku klien pengembang
- mudah untuk pengembang dan tester untuk meluncurkan
- terhubung ke server Metro selama pekerjaan sehari-hari
- tetap dapat digunakan ulang sampai ketergantungan native berubah
Ini juga di mana CI mulai menjadi lebih praktis. Saat profil build ada dan berperilaku secara prediktif, Anda bisa mengotomatisasinya.
Jika tim Anda berpikir lebih luas tentang bagaimana React Native masuk ke dalam kerja 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 di berbagai permukaan mobile.
Walkthrough singkat bisa membantu jika Anda ingin melihat aliran dalam aksi:
Menginstal hasilnya
Saat build selesai, tatal hasilnya seperti aplikasi binary nyata, karena itu apa yang dia lakukan.
- Pada Android: Kamu biasanya menginstal
.apkdi perangkat fisik atau emulator. - Pada iOS: Anda akan bekerja dengan
.ipaatau hasil output yang kompatibel dengan simulator tergantung pada target. - Untuk rekan tim: Bagikan bangun melalui mekanisme EAS normal daripada meminta semua orang untuk membuat sendiri dari awal kecuali perlu.
Bangun 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 bangun pertama kali menghilangkan kompleksitas native. Ini memindahkan kompleksitas ke tempat yang tepat.
Jika Anda menambahkan modul native baru, mengubah izin, memperbarui SDK-level dependensi native, atau memodifikasi konfigurasi native yang dikemudikan plugin, Anda akan memerlukan bangun ulang pengembangan yang segar. Itu normal. Hadiahnya adalah bahwa pekerjaan JavaScript sehari-hari Anda masih bergerak cepat di dalam klien yang mencerminkan aplikasi Anda.
Menggunakan dan Membuat Debug dengan Klien Baru Anda
Kali pertama Anda membuka klien yang diinstal dan menghubungkannya ke Metro, perbedaanannya jelas. Ini terasa seperti Expo, tapi tidak lagi dalam arti mainan.
Mulai server dengan npx expo start --dev-clientLalu buka klien pengembangan di simulator, emulator, atau perangkat fisik Anda dan hubungkan melalui antarmuka pengguna peluncur. Peluncur itu salah satu perubahan penting yang diperkenalkan oleh expo-dev-clientbersama dengan dukungan debugging seperti inspeksi permintaan jaringan, seperti yang terdokumentasi di halaman __CAPGO_KEEP_0__ Expo untuk klien dev Seorang pengembang perangkat lunak pria menulis SDK di komputer laptop di lingkungan kerja profesional..
Sebuah sesi biasa terlihat seperti ini:
Kamu pull branch terbaru. Klien pengembangan yang terinstal sudah ada di perangkatmu. Kamu menjalankan Metro, meluncurkan aplikasi, dan terhubung ke server saat ini. Kemudian kamu bekerja sebagaimana biasa, mengubah JavaScript dan melihat update dengan cepat.
Perbedaan besar muncul ketika kamu membutuhkan untuk memeriksa perilaku yang bergantung pada lingkungan native yang nyata. Klien khusus memungkinkan kamu untuk menguji aliran-aliran tersebut tanpa keluar dari lingkaran regulermu.
Alat debugging yang penting
Alat tambahan bukanlah hiasan. Alat tersebut menyelesaikan masalah-masalah sehari-hari.
Antarmuka Launcher:
- Terutama berguna ketika kamu beralih antara lingkungan atau server yang dihosting oleh rekan kerjamu. Menu pengembang:
- Menu pengembang: Memberikan aksi yang Anda harapkan selama iterasi aktif.
- Inspeksi jaringan: Membantu ketika UI terlihat rusak tetapi masalah sebenarnya adalah gagal permintaan, status autentikasi, atau pengaturan lingkungan yang salah.
Jika API gagal saat menjalankan klien pengembangan, inspect jalur permintaan dan asumsi lingkungan sebelum menyentuh UI code. Biasanya, bug ada di luar komponen yang Anda lihat.
Keuntungan praktisnya adalah sebagai berikut. Satu file biner yang diinstal dapat memvalidasi lingkungan yang berbeda-beda tanpa harus merekompilasi setiap kali. 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 ultimate debugging Capacitor adalah bacaan yang layak untuk disesuaikan dengan mindset debugging yang lebih luas. Alatnya berbeda, tetapi disiplinnya sama: inspect transport, lingkungan, dan perilaku waktu eksekusi sebelum menebak.
Apakah yang baik dan tidak baik:
Sitasi:
| Mengapa klien pengembangan membantu | Mengapa klien pengembangan membantu |
|---|---|
| Tes autentikasi redirect | Perilaku aplikasi native lebih dekat dengan produksi |
| Memastikan integrasi API | Pengintai jaringan memperpendek siklus umpan balik |
| Mengganti lingkungan | Antarmuka UI launcher menghindari pembangunan yang tidak perlu |
| QA tim dalam satu biner | Semua orang menguji setup native yang sama |
Apa yang tidak berfungsi dengan baik:
- Menganggap klien sebagai barang yang dapat dibuang: Jika tim tidak menjaganya, kebingungan akan datang dengan cepat.
- Mengabaikan batasan pembangunan native: Setelah ketergantungan native berubah, klien yang ketinggalan waktu menghabiskan waktu.
- Mengasumsikan semua gagal koneksi adalah bug aplikasi: Banyak yang hanya masalah lingkungan lokal.
Mengintegrasikan dengan CI/CD dan Live Updates
Klien pengembangan Expo menjadi lebih berharga ketika tidak lagi menjadi pengaturan pribadi dan menjadi bagian dari operasional tim.
Alur kerja yang matang biasanya memisahkan kekhawatiran. Perubahan native menghasilkan bangun pengembangan baru. Perubahan JavaScript dan aset bergerak 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 bangun, dan tujuan pembaruan.
Dimana CI/CD berada?
Klien pengembangan bekerja dengan baik dengan CI karena memberikan otomatisasi target yang stabil.
Gaya umum yang terlihat seperti ini:
- Perubahan pull request: CI membuat atau memvalidasi bangun pengembangan ketika ketergantungan native berubah.
- Struktur cabang berbasis: Berbagai cabang menerjemahkan ke berbagai saluran pembaruan atau target server.
- Alur kerja tester yang dibagikan: QA menginstal satu atau lebih klien dev yang diketahui dan beralih konteks melalui peluncur dan konfigurasi pembaruan.
Struktur tersebut mengurangi ketidakjelasan. Pengembang tahu kapan mereka memerlukan pembangunan ulang. Tester tahu apakah mereka memvalidasi perubahan asli atau pembaruan yang disampaikan di atas biner yang sudah ada.
Peran pembaruan hidup
Klien pengembang sering kali memungkinkan tim untuk menghemat operasi waktu yang paling banyak. Klien pengembang adalah tempat yang kuat untuk memvalidasi perilaku pembaruan sebelum rilis karena dapat beralih antara server pengembangan dan pembaruan yang dipublikasikan dalam shell aplikasi yang seperti produksi, seperti yang dijelaskan sebelumnya dalam dokumentasi Expo.
Memungkinkan pembagian yang berguna:
| Golongan perubahan | Rute pengiriman |
|---|---|
| Golongan perubahan modul asli baru atau perubahan izin | Golongan pembangunan baru |
| Perbaikan perilaku JavaScript | Publikasikan update |
| Penyesuaian salinan atau asset | Publikasikan update |
| Pengujian lingkungan | Switch channel atau server di klien yang terpasang |
Untuk tim di luar stack pembaruan Expo, Capgo's panduan integrasi CI/CD untuk pembaruan OTA menampilkan model operasional yang sama pada sisi Capgo. shows a comparable operational model on the Capacitor side. It’s one option for teams that want controlled rollout channels and automation around update delivery.
Polanya yang dapat diandalkan adalah sederhana. Bangun ketika perubahan native code terjadi. Publikasikan ketika binary yang terpasang sudah mengandung semua yang perubahan butuhkan.
Habitan tim yang mencegah kekacauan
Konfigurasi teknis yang penting, tetapi aturan operasional yang lebih penting:
- Berikan nama saluran dengan jelas:
staging,production, dan nama preview harus jelas. - Document rebuild triggers: Perubahan plugin baru, perubahan izin, atau pembaruan native SDK tidak boleh menjadi keputusan subjektif.
- Tetapkan strategi satu klien yang dapat diinstal per lingkungan: Terlalu banyak variasi menciptakan kebisingan dukungan.
- Pastikan validasi pembaruan eksplisit: Seseorang harus memastikan bahwa pembaruan berlaku dan meluncur di dalam binary yang sama yang diharapkan tim.
Pada titik ini, klien pengembang Expo tidak lagi menjadi kemudahan pengembang dan menjadi infrastruktur rilis.
Pitfall dan Solusi Umum yang Sering Terjadi
Masalah klien pengembang Expo biasanya biasa sekali Anda tahu di mana harus mencari. Mereka terasa misterius karena gagal sering terjadi di batasan: 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 troubleshooting Expo Dev Client.
Mengapa Klien Tidak Terhubung ke Metro
Masalah ini memakan waktu paling lama karena tampaknya seperti aplikasi rusak ketika aplikasi sering kali berfungsi dengan baik.
Periksa hal-hal berikut:
- Asumsi jaringan yang sama: Peralatan dan laptop mungkin terlihat terhubung sambil duduk di segmen terisolasi.
- Interferensi VPN: VPN korporat 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.
- Kebijakan perangkat korporat: Perangkat yang diatur mungkin menghalangi pola lalu lintas yang digunakan oleh alat pengembangan.
If project bekerja di simulator tapi tidak di perangkat fisik, curigai jaringan sebelum curigai React code.
Tidak debug gagal koneksi dari dalam aplikasi terlebih dahulu. Pastikan perangkat dapat benar-benar mencapai mesin yang menjalankan Metro.
Ketika rebuild tampak acak
Kesulitan lain yang umum adalah perasaan bahwa beberapa perubahan muncul secara instan dan lain-lain menolak untuk muncul.
Biasanya berarti tim belum memahami batas rebuild:
| Gejala | Pemicu yang mungkin | Pemecahan masalah |
|---|---|---|
| Pembaruan JavaScript berlaku secara normal | Behavior yang diharapkan | Terus bekerja di klien yang ada |
| Dependensi native baru tidak muncul | Layer native diubah | Buatlah build pengembangan baru |
| Perilaku terkait izin tidak konsisten | Konfigurasi native diubah | Rebuild dan reinstall |
| Satu rekan melihat perilaku yang berbeda | Binary klien yang berbeda terpasang | Menyesuaikan pada build yang sama |
Ini bukan kelemahan dalam alur kerja. Ini adalah alur kerja yang melakukan apa yang harus dilakukan.
Gagal build dan pergeseran tim
Ketika build gagal, penyebab utama sering kali salah satu dari ini:
- Kesalahan sinkronisasi dependensi: A versi paket tidak sesuai dengan proyek lainnya.
- Asumsi plugin native: A plugin konfigurasi mengharapkan pengaturan proyek yang tidak ada.
- Kesalahpahaman kredit: Tanda tangan atau akses akun tidak konsisten di tim.
- Harapan lokal yang ketinggalan: Seseorang menganggap bahwa bangunan segar tidak diperlukan ketika sebenarnya perlu.
Capgo’s artikel tentang masalah pembaruan hidup umum dan solusi untuk pengembang adalah bacaan tambahan yang berguna untuk sisi rilis masalah ini. Stack yang berbeda, pelajaran yang sama: banyak ‘bug aplikasi’ sebenarnya adalah bug pengiriman, lingkungan, atau bug 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 melakukannya, pengaturan menjadi prediktif, dan prediktif adalah apa yang Anda inginkan dari alat mobile.
Jika tim Anda juga mengirimkan aplikasi Capacitor dan membutuhkan cara yang dikendalikan untuk mengirimkan pembaruan JavaScript, aset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan live, kontrol peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron workflow.
