Petunjuk Lengkap untuk Klien Pengembangan Expo

Kamu biasanya sudah siap untuk klien pengembangan Expo pada saat yang tepat Expo Go mulai berbohong kepadamu.

Applikasi berjalan di sandbox. Refresh cepat terasa sangat menyenangkan. Kemudian kamu menambahkan ketergantungan native, menghubungkan notifikasi push, menguji alur 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.

Di sinilah klien pengembangan Expo berubah alur kerja. Ini menjaga loop JavaScript cepat yang orang sukai tentang Expo, tetapi memindahkan pengujian ke biner native yang disesuaikan yang berperilaku lebih seperti aplikasi yang akan kamu kirimkan nanti. Bagi pengembang solo, itu berarti ada sedikit kejutan pada siklus akhir. Bagi 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
  • Mengapa yang Paling Pertama Rusak
  • Mengapa Klien Pengembangan Adalah Langkah Berikutnya yang Tepat
  • Pergeseran Pikiran
• Prasyarat dan Konfigurasi Proyek
  • Mulai dengan akun dan layer CLI
  • Instal paket yang membuat alur kerja ini mungkin
  • Periksa konfigurasi aplikasi kamu sebelumnya
  • Apa yang terlihat pada 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 perlu Anda harapkan
• Menggunakan dan Mengdebug dengan Klien Baru Anda
  • Sesi pengembangan normal
  • Alat debug yang paling penting
  • Apa yang berfungsi dengan baik dan apa yang tidak
• Mengintegrasikan dengan CI/CD dan Update Langsung
  • Di mana CI/CD berada
  • Peran pembaruan langsung
  • Kebiasaan tim yang mencegah kekacauan
• Pengaturan Umum Kesalahan dan Perbaikan
  • Ketika klien tidak terhubung ke Metro
  • Ketika pembaruan ulang tampak acak
  • Gagal membangun dan pergeseran tim

Mengapa Anda Perlu Melampaui Expo Go

Expo Go berguna di awal. Ini menghilangkan gesekan pengaturan, memulai proyek React Native dengan cepat, dan memberikan loop umpan balik cepat. Itu tepat mengapa banyak tim memulai dari sana.

Masalah dimulai ketika aplikasi tidak lagi prototipe. Dokumen Expo menggambarkan Expo Go sebagai laboratorium dan mencatat bahwa tidak dapat menyimulasikan dengan akurat kemampuan native seperti pemberitahuan atau autentikasi OAuth, sementara model pembangunan pengembang dibangun di sekitar expo-dev-client dan diposisikan sebagai “Debug” build untuk aplikasi produksi tingkat tinggi in di Pengenalan pembangunan Expo: 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 sebenarnya.
• Notifikasi dan fitur perangkat: Sandbox tidak mencerminkan 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 pengembangan adalah langkah selanjutnya yang tepat

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

Pergeseran 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, tulisan Capgo tentang alternatif Expo pengganti Expo Bermanfaat dalam konteks karena menyoroti di mana tim mulai mencari ke luar dari alur kerja sandbox.

Perubahan Sikap

Kesalahan terbesar yang saya lihat adalah menganggap Expo development client sebagai tugas pengaturan satu kali. Tidak, itu adalah pilihan alur kerja.

Kamu menerima satu kekurangan untuk mendapatkan kontrol:

Dalam pengembangan aplikasi profesional, itu adalah tukar yang baik. 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 iterasi build yang berulang. Banyak usaha pertama yang gagal berasal dari mengabaikan konfigurasi dasar, bukan dari Expo sendiri.

Documentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai “lingkungan pengembangan yang lengkap” yang mewakili lingkungan produksi nyata ketika aplikasi bergantung pada kode native code atau pengujian kualitas produksi tingkat tinggi, seperti yang dibahas dalam ringkasan Draftbit tentang alat-alat pengembangan Expo dan build pengembangan.

Mulai dengan layer akun dan CLI

Ada dua hal yang harus berfungsi sebelum layer aplikasi menjadi penting:

1. akses CLI Expo
2. akses CLI EAS

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

Konfigurasi yang bersih biasanya mencakup:

• sesi akun Expo Anda: ini menghubungkan pekerjaan lokal dengan layanan pembangunan jarak jauh dan kepemilikan proyek.
• EAS CLI terpasang: EAS adalah yang mengubah proyek Anda menjadi binary iOS atau Android yang dapat dibagikan.
• Sebuah proyek yang sudah berjalan lokal: Tidak perkenalkan 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, 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 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 awal

A lot of confusion comes from menganggap app.json atau app.config.js metadata hanya. 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 native dan tanda tangan yang lebih lanjut.
• Tujuan lingkungan yang jelas: Jika tim menggunakan identitas staging dan produksi yang terpisah, refleksikan itu dengan sengaja.

Jika lingkungan lokal Anda berantakan, sebaiknya disusun kembali sebelum melakukan build pertama kali. Panduan Capgo mengatur lingkungan lokal Capacitor Bukan khusus Expo, tapi ini adalah pengingat bahwa pekerjaan mobile yang dapat direproduksi dimulai dengan perangkat lokal yang stabil dan konfigurasi eksplisit.

Apakah konfigurasi awal yang baik

Pakai daftar periksa ini sebelum memulai EAS:

Tujuan bukanlah kesempurnaan. Tujuan adalah membuat proses build pertama menjadi menarik. Itu adalah kemenangan.

Membangun Klien Kustom Anda dengan EAS

Poin ini di mana alur kerja menjadi nyata. Anda berhenti berbicara tentang klien khusus dan menghasilkannya.

Expo merekomendasikan alur kerja build pengembangan untuk aplikasi dengan klien native kustom code: instal expo-dev-clientgenerate klien native dengan EAS Build atau secara lokal, kemudian jalankan npx expo start --dev-client. Expo 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:

1. Instal dan autentikasi dengan EAS CLI
2. Inisialisasi atau konfirmasi konfigurasi pembangunan
3. Buat profil pembangunan untuk pengembang
4. Aktifkan pembangunan untuk iOS atau Android
5. Instal hasil binary di perangkat atau simulator

What EAS gives you is consistency. Instead of each developer improvising local native build state, the team can produce binaries from a shared build definition.

Apa yang profil pembangunan Anda lakukan sebenarnya

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

Biasanya berarti aplikasi yang diinstal harus:

• termasuk perilaku klien pengembangan
• mudah bagi pengembang dan tes untuk meluncurkan
• terhubung ke server Metro selama pekerjaan sehari-hari
• tetap dapat digunakan ulang sampai ketergantungan native berubah

Hal ini juga merupakan tempat di mana 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 hasilnya seperti aplikasi biner nyata, karena itu apa yang dia adalah.

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

Sebuah build pengembangan paling mudah untuk dikelola ketika tim setuju pada satu aturan: bangun ulang untuk perubahan native, bukan untuk setiap perubahan code.

Apa yang tidak harus diharapkan

Tidak harapkan build pertama untuk menghilangkan kompleksitas native. Ini memindahkan kompleksitas ke tempat yang tepat.

Jika kamu menambahkan modul native baru, mengubah izin, memperbarui SDK-level dependensi native, atau memodifikasi konfigurasi native yang dikemudikan plugin, kamu akan membutuhkan build pengembangan yang segar. Itu normal. Hadiahnya adalah pekerjaan JavaScript sehari-hari kamu masih bergerak cepat di dalam klien yang mencerminkan aplikasi kamu.

Berjalan dan Membuat Debug dengan Klien Baru

Ketika Anda membuka klien yang terpasang untuk pertama kalinya dan menghubungkannya ke Metro, perbedaan itu jelas. Ini terasa seperti Expo, tapi tidak lagi dalam arti mainan.

Mulai server dengan npx expo start --dev-client. Kemudian buka klien pengembangan pada simulator, emulator, atau perangkat fisik Anda dan hubungkan melalui antarmuka pengguna peluncur. Peluncur itu salah satu perubahan penting yang diperkenalkan oleh expo-dev-client, bersama dukungan debugging seperti inspeksi permintaan jaringan, seperti yang terdokumentasi di halaman Expo SDK untuk klien pengembangan.

Sesi pengembangan normal

Sesi biasa terlihat seperti ini:

Anda pull branch terbaru. Klien pengembangan yang terpasang 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 update dengan cepat.

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

Alat debugging yang penting

Alat tambahan bukanlah hiasan. Ini menyelesaikan masalah sehari-hari.

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

Jika API gagal saat menjalankan pengembang, periksa jalur permintaan dan asumsi lingkungan sebelum menyentuh UI code. Biasanya, bug 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. 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: periksa perilaku transportasi, lingkungan, dan waktu eksekusi sebelum menebak.

Apakah yang baik dan apa yang tidak baik

Apa yang berfungsi dengan baik:

Apa yang tidak berfungsi dengan baik:

• Menangani klien sebagai barang yang tidak berharga: Mengapa tim tidak menjaga klien tersebut, kebingungan datang dengan cepat.
• Mengabaikan batasan pembaruan asli: Setelah ketergantungan asli 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 tidak lagi menjadi pengaturan pribadi dan menjadi bagian dari operasional tim.

Alur kerja yang matang biasanya memisahkan kekhawatiran. Perubahan asli menghasilkan bangun pengembangan baru. Perubahan JavaScript dan aset melalui jalur pembaruan yang lebih cepat. Pengevaluasi 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.

A pola umum terlihat seperti ini:

• Pengajuan perubahan pull: CI membuat atau memvalidasi bangun dev ketika dependensi native telah berubah.
• Pengaturan berdasarkan cabang: Cabang yang berbeda menerjemahkan ke saluran pembaruan atau target server yang berbeda.
• Alur tester yang dibagikan: QA menginstal satu atau lebih klien dev yang diketahui dan mengganti konteks melalui peluncur dan pengaturan pembaruan.

Struktur itu mengurangi ketidakjelasan. Pengembang tahu kapan mereka perlu merekonstruksi. Tester tahu apakah mereka memvalidasi perubahan native atau pembaruan yang disampaikan di atas biner yang sudah ada.

Peran pembaruan live

Klien dev sering kali memungkinkan tim untuk menghemat operasi waktu yang paling banyak. Klien dev adalah tempat yang kuat untuk memvalidasi perilaku pembaruan sebelum rilis karena dapat beralih antara server dev dan pembaruan yang dipublikasikan dalam shell aplikasi yang seperti produksi, seperti yang dijelaskan sebelumnya dalam dokumentasi Expo.

Terbuka itu adalah pemisahan yang berguna:

Untuk tim di luar stack pembaruan Expo, Guida integrasi CI/CD Capgo untuk pembaruan OTA menampilkan model operasional yang dapat dibandingkan di sisi Capacitor. Ini adalah salah satu pilihan untuk tim yang ingin memiliki saluran peluncuran yang terkontrol dan otomatisasi seputar pengiriman update.

Polanya yang dapat diandalkan adalah sederhana. Bangun ketika code asli berubah. Publikasikan ketika binary yang terpasang sudah mengandung semua yang perubahan butuhkan.

Kebiasaan tim yang mencegah kekacauan

Konfigurasi teknis penting, tetapi aturan operasional lebih penting:

• Berikan nama saluran dengan jelas: staging, productiondan nama preview harus jelas.
• Dokumentasikan trigger rebuild: Perubahan plugin, perubahan izin, atau pembaruan SDK asli tidak boleh menjadi keputusan subjektif.
• Tetapkan strategi satu klien yang dapat diinstal per lingkungan: Banyak variasi dapat menciptakan kebisingan dukungan.
• Pastikan validasi update eksplisit: Seseorang harus memastikan bahwa update berlaku dan meluncur di dalam binary yang sama yang tim harapkan.

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

Mengatasi Kesulitan Umum dan Solusi

Most Expo development client issues are ordinary once you know where to look. They feel mysterious because failures often happen across boundaries: laptop to device, Metro to app, native config to JavaScript runtime.

Masalah pengembang Expo client biasanya biasa jika Anda tahu di mana harus mencari. Mereka terlihat misterius karena gagal sering terjadi di batas-batas: laptop ke perangkat, Metro ke aplikasi, konfigurasi native ke runtime JavaScript. Video Pemecahan Masalah Expo Dev Client.

Video Pemecahan Masalah Expo Dev Client

Masalah ini yang memakan waktu paling lama karena tampaknya seperti aplikasi rusak ketika aplikasi sebenarnya sering berjalan dengan baik.

Periksa hal-hal berikut:

• Periksa hal-hal ini terlebih dahulu: Perangkat dan laptop mungkin terlihat terhubung sambil duduk di segmen terisolasi.
• Penggangguan VPN: Suatu VPN korporat 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 korporat: Perangkat yang diatur sering kali membatasi pola lalu lintas yang digunakan oleh alat-alat pengembangan.

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

Tidak debug gagal koneksi dari dalam aplikasi terlebih dahulu. Konfirmasi perangkat apakah 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 tidak mau.

Biasanya berarti tim belum memahami batas rebuild:

Ini bukanlah kekurangan dalam alur kerja. Ini adalah alur kerja yang melakukan apa yang harus dilakukan.

Gagal build dan pergeseran tim

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

• Gangguan dependensi: Versi paket tidak sesuai dengan proyek lainnya.
• Asumsi plugin native: Plugin konfigurasi mengharapkan setup proyek yang tidak ada.
• Kesalahpahaman kunci: Penandatanganan atau akses akun tidak konsisten di tim.
• Harapan lokal yang ketinggalan: Seseorang menganggap build segar tidak diperlukan ketika sebenarnya perlu.

Capgo's artikel di common live update issues and solutions for developers bermanfaat sebagai bacaan tambahan untuk sisi rilis masalah ini. Stacking yang berbeda, pelajaran yang sama: banyak "bug aplikasi" sebenarnya adalah bug pengiriman, lingkungan, atau versi-alignment.

The Expo development client bekerja dengan baik ketika tim menganggap keandalan lingkungan sebagai bagian dari keahlian. 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, asset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan langsung, kontrol peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron.