Anda biasanya sudah siap untuk klien pengembangan Expo pada saat yang tepat ketika Expo Go mulai berbohong kepada Anda.
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 menguji lingkungan yang disederhanakan.
Itu adalah saat 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 kirimkan nanti. Untuk pengembang solo, itu berarti ada sedikit kejutan pada siklus akhir. 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
- Persyaratan dan Konfigurasi Proyek
- Membangun Klien Custom Anda dengan EAS
- Menggunakan dan Membuat Debug dengan Klien Baru Anda
- Mengintegrasikan 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 setup, membuat proyek React Native berjalan cepat, dan memberikan Anda loop feedback cepat. Itu tepatnya mengapa banyak tim memulainya.
Masalah dimulai ketika aplikasi tidak lagi prototipe. Expo mendokumentasikan Expo Go sebagai laboratorium dan mencatat bahwa itu tidak dapat menyimulasikan dengan akurat beberapa kemampuan native seperti notifikasi atau autentikasi OAuth, sementara model pembangunan pengembang dibangun di sekitar expo-dev-client dan diposisikan sebagai “Debug” build untuk aplikasi produksi dalam Pengenalan Pembangunan Expo.
Apa yang patah dahulu
Dalam prakteknya, kerusakan pertama biasanya salah satu dari berikut:
- 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: Sandbox tidak mencerminkan bagaimana aplikasi produksi akan meminta izin atau menerima event.
- QA Tim: Seorang tester memerlukan binary stabil yang mewakili pengaturan native sebenarnya aplikasi.
Itu bukan kasus pinggir. Itu adalah tahap normal dalam proyek mobile nyata.
Expo Go sangat baik untuk membuktikan antarmuka. Ini adalah 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 diinstal menjadi hal yang tim Anda uji terhadap, bukan bergantung pada kontainer generic.
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?” Pertanyaan itu yang tepat.
Jika Anda juga membandingkan model pengiriman aplikasi yang lebih luas, Capgo’s tulisan tentang alternatif Expo bisa memberikan konteks yang berguna karena menyoroti di mana tim mulai mencari ke luar dari alur kerja sandbox. Pergeseran pikiran
Kesalahan terbesar yang saya lihat adalah menganggap klien pengembangan Expo seperti tugas pengaturan satu kali. Ini bukanlah.
Itu adalah pilihan alur kerja.
Anda menerima satu perdagangan untuk mendapatkan kontrol:
| Alur Kerja | Apa yang tetap cepat | Apa yang memerlukan lebih banyak upacara |
|---|---|---|
| Expo Go | Pengulangan JavaScript dasar | Apa saja yang bergantung pada kenyataan asli native |
| Klien pengembangan 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 dalam keadaan yang dapat bertahan dari build yang dapat diulang. Banyak usaha pertama yang gagal datang dari melompati konfigurasi dasar, bukan dari Expo sendiri.
Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai "lingkungan pengembangan yang lengkap" That’s representative of sebuah lingkungan produksi nyata ketika aplikasi bergantung pada native code atau QA produksi yang lebih baik, seperti yang dibahas dalam ringkasan Draftbit tentang Alat-alat pengembang Expo dan pembangunan aplikasi.
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 terus masuk ke akun Expo Anda dari terminal. Tim seringkali mengabaikan 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 iOS atau Android yang dapat dibagikan.
- A project yang sudah berjalan di lokal: Tidak perkenalkan kompleksitas pembangunan sebelum aplikasi startup dasar berfungsi.
Instal paket yang membuat alur kerja mungkin
Pusat dari setup ini adalah expo-dev-clientTidak ada, Anda tidak memiliki launcher kustom dan shell native yang berorientasi debug yang mendefinisikan alur kerja klien pengembangan Expo.
Instalnya 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 kami sendiri.”
Aturan praktis: Bangun klien pengembangan sekali ketergantungan native daftar stabil cukup untuk rekan tim untuk menginstal dan menggunakan binary yang sama.
Periksa konfigurasi aplikasi Anda sebelumnya
Banyak kebingungan datang dari menganggap app.json atau app.config.js sebagai metadata saja. Tidak. File-file ini mendefinisikan 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.
- Intensi lingkungan yang jelas: Jika tim menggunakan identitas staging dan produksi yang terpisah, refleksikan itu secara 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 diulang dimulai dengan perangkat lunak lokal yang stabil dan konfigurasi eksplisit.
Apa konfigurasi yang baik pertama kali
Pakailah 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 dan instalasi native |
| Projek dimulai secara lokal | Menghindari masalah runtime yang dicampur dengan masalah pembangunan |
| Tim tahu kapan harus membangun ulang | Mengurangi kebingungan setelah perubahan native |
The 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 menghasilkan satu.
Expo merekomendasikan alur kerja build pengembangan untuk aplikasi dengan 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 run pertama terasa asing:
- Pasang dan autentikasi dengan EAS CLI
- Konfigurasi atau konfirmasi pengaturan pembangunan
- Buat profil pembangunan untuk pengembangan
- Aktifkan pembangunan untuk iOS atau Android
- Pasang hasil biner pada perangkat atau simulator
Apa yang diberikan EAS adalah konsistensi. Sebaliknya dari setiap pengembang yang berimprovisasi 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 pengembang dan tes untuk diluncurkan
- terhubung ke server Metro selama pekerjaan sehari-hari
- __CAPGO_KEEP_0__ tetap dapat digunakan ulang sampai ketergantungan native berubah
Hal ini juga merupakan tempat di mana CI mulai 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 mengirimkan perubahan produk yang lebih sering di permukaan mobile.
Walkthrough singkat dapat membantu jika Anda ingin melihat aliran dalam aksi:
Menginstal hasilnya
Setelah build selesai, tatal hasilnya seperti aplikasi biner nyata, karena itu apa yang dia adalah.
- Di Android: Anda akan menginstal sebuah
.apkdi perangkat fisik atau emulator. - Di iOS: Anda akan bekerja dengan
.ipaatau output yang kompatibel dengan simulator tergantung pada target. - Untuk rekan kerja: Bagikan hasil build melalui mekanisme EAS normal bukan meminta setiap orang untuk membuat sendiri dari awal kecuali perlu.
Build pengembangan paling mudah dikelola ketika tim setuju pada satu aturan: rebuild untuk perubahan native, bukan untuk setiap code perubahan.
Apa yang tidak harus diharapkan
Jangan harap build pertama dapat 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 dikendalikan plugin, Anda akan memerlukan build pengembangan yang segar. Itu normal. Hadiahnya adalah bahwa pekerjaan JavaScript sehari-hari Anda masih bergerak cepat di dalam klien yang memantulkan aplikasi Anda.
Menggunakan dan Mengdebug dengan Klien Baru Anda
Kali pertama Anda membuka klien yang diinstal dan menghubungkannya ke Metro, perbedaannya 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:
Anda menarik cabang terbaru. Klien pengembangan yang diinstal 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 keluar dari lingkungan reguler Anda.
Alat debugging yang penting
Alat tambahan bukanlah dekoratif. Alat tersebut menyelesaikan masalah-masalah sehari-hari.
Antarmuka Launcher:
- Bermanfaat ketika Anda beralih antara lingkungan atau server yang dihosting oleh rekan kerja. Menu pengembang:
- __CAPGO_KEEP_0__ Memberikan aksi yang Anda harapkan selama iterasi aktif.
- Pengintai Jaringan: Membantu ketika UI terlihat rusak tetapi masalah sebenarnya adalah gagal permintaan, status autentikasi, atau pengaturan lingkungan yang salah.
Jika API gagal saat API di klien pengembangan, inspect jalur permintaan dan asumsi lingkungan sebelum menyentuh UI code. Masalah sering kali berada di luar komponen yang Anda lihat.
Keuntungan yang praktis. Satu biner yang diinstal dapat memvalidasi lingkungan yang berbeda-beda 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 cabang lokal.
Jika tim Anda juga mengirimkan shell mobile berbasis web, Capgo’s Buku Panduan Akhir untuk Mengatasi Masalah Capacitor Buku panduan ini sangat berguna untuk membantu Anda mengembangkan mindset debugging yang lebih luas. Meskipun tooling yang digunakan berbeda, namun disiplin yang diperlukan sama: inspect transport, lingkungan, dan perilaku waktu eksekusi sebelum menebak.
Apa yang baik dan apa yang tidak baik
Apa yang baik:
| Situasi | Mengapa klien pengembangan membantu |
|---|---|
| Menguji alih redirigi autentikasi | Siklus aplikasi native lebih dekat dengan produksi |
| Mengverifikasi API integrasi | Inspeksi jaringan memperpendek siklus umpan balik |
| Mengganti lingkungan | Antarmuka UI Launcher menghindari pembangunan ulang yang tidak perlu |
| QA tim dalam satu biner | Semua orang menguji setup native yang sama |
Apa yang tidak berfungsi dengan baik:
- Menganggap klien sebagai benda yang dapat dibuang: Jika tim tidak menjaganya, kebingungan akan menyebar dengan cepat.
- Melupakan batasan pembangunan ulang native: Setelah perubahan dependensi native, klien yang ketinggalan waktu menghabiskan waktu.
- Mengasumsikan semua gagal koneksi adalah bug aplikasi: Banyak yang hanya masalah lingkungan lokal.
Integrasi 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 build pengembangan baru. Perubahan JavaScript dan asset 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 build, dan tujuan pembaruan.
Dimana CI/CD berada
Klien pengembangan bekerja dengan baik dengan CI karena memberikan automasi target yang stabil.
Gaya umum seperti ini:
- Perubahan pull request: CI membuat atau memvalidasi build pengembangan ketika dependensi native telah berubah.
- Struktur berdasarkan cabang: Berbagai cabang menerjemahkan ke berbagai saluran pembaruan atau target server.
- Alur kerja tester bersama: Pengujian instalasi satu atau lebih klien pengembang yang diketahui dan mengganti konteks melalui peluncur dan konfigurasi pembaruan.
Struktur tersebut mengurangi ketidakjelasan. Pengembang tahu kapan mereka memerlukan pembangunan ulang. Tester tahu apakah mereka sedang memvalidasi perubahan asli atau pembaruan yang disampaikan di atas biner yang sudah ada.
Peran pembaruan hidup
Pengguna klien pengembang seringkali memungkinkan tim untuk menghemat operasi waktu yang paling banyak. Pengguna 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.
itu membuka pembagian yang berguna:
| Jenis perubahan | Rute pengiriman |
|---|---|
| Perubahan modul asli baru atau perubahan izin | Pembangunan ulang pengembangan baru |
| Pembetukan perilaku JavaScript | Publikasikan update |
| Penyesuaian salinan atau asset | Publikasikan update |
| Pengujian lingkungan | Switch saluran atau server di klien yang terpasang |
Untuk tim di luar stack Expo update Petunjuk integrasi CI/CD Capgo untuk update OTA Menggambarkan model operasional yang sama pada sisi Capacitor. Ini adalah salah satu pilihan untuk tim yang ingin memiliki saluran rollout yang dikendalikan dan otomatisasi seputar pengiriman update.
Polanya yang dapat diandalkan sederhana. Bangun ketika perubahan native code terjadi. Publikasikan ketika binary yang terpasang sudah mengandung semua yang perubahan 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-nama harus jelas. - Dokumentasikan trigger rebuild: Perubahan plugin, perubahan izin, atau pembaruan native SDK tidak boleh menjadi keputusan yang sulit.
- Strategi satu klien yang dapat diinstal per lingkungan: ,
- Banyak variasi menciptakan kebisingan dukungan. Validasi pembaruan harus eksplisit:
,
Pada titik ini, klien pengembangan Expo berhenti menjadi kemudahan pengembang dan menjadi infrastruktur rilis.
Pitfall dan Solusi Umum
Masalah klien pengembangan Expo biasanya biasa sekali 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. Video troubleshooting Expo Dev Client.
Ketika klien tidak terhubung ke Metro
Masalah ini yang paling memakan waktu karena tampaknya seperti aplikasi rusak ketika aplikasi sering kali baik.
Periksa hal-hal ini terlebih dahulu:
- Asumsi jaringan yang sama: Perangkat dan laptop mungkin terlihat terhubung sementara berada di segmen terisolasi.
- Pengganggu 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 mengganggu 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. Pastikan 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 enggan tidak.
Biasanya berarti tim belum memahami batas rebuild:
| Gejala | Penyebab yang mungkin | Pemecahan masalah |
|---|---|---|
| Pembaruan JavaScript berlaku secara normal | Penggunaan yang diharapkan | Lanjutkan bekerja di klien yang ada |
| Ketergantungan native baru tidak muncul | Layer native diubah | Buatlah build pengembangan baru |
| Sikap terkait izin tidak konsisten | Konfigurasi native diubah | Rebuild dan reinstall |
| Tim rekan satu melihat perilaku yang berbeda | Instalasi biner klien yang berbeda | Sesuaikan pada build yang sama |
Hal 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:
- Sesuai tidaknya dependensi: Versi paket tidak sesuai dengan proyek lainnya.
- Asumsi plugin native: Plugin konfigurasi mengharapkan pengaturan proyek yang tidak ada.
- Kesalahpahaman kredit: Tanda tangan atau akses akun tidak konsisten di tim.
- Harapan lokal yang ketinggalan zaman: Seseorang menganggap bahwa build yang segar tidak diperlukan ketika sebenarnya diperlukan.
Capgo’s artikel tentang masalah pembaruan hidup umum dan solusi untuk pengembang bermanfaat sebagai bacaan tambahan untuk sisi rilis masalah ini. Menghadapi masalah yang sama, tetapi dengan stack yang berbeda: 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 rekayasa. Bukan sebagai hal yang dilupakan. Setelah Anda melakukan itu, pengaturan menjadi prediktif, dan prediktif adalah apa yang Anda inginkan dari alat pengembangan mobile.
Jika tim Anda juga mengirimkan aplikasi Capacitor dan membutuhkan cara yang terkendali untuk mengirimkan pembaruan JavaScript, aset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan waktu nyata, pengendalian peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron workflow.
