Panduan Lengkap Pengembang Expo

Kamu biasanya sudah siap untuk klien pengembang Expo pada saat yang tepat ketika Expo Go mulai berbohong.

Aplikasi berjalan di sandbox. Refresh cepat terasa hebat. Lalu 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 menguji lingkungan yang disederhanakan.

Itu adalah saat klien pengembang Expo mengubah alur kerja. Klien ini mempertahankan 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 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
  • Apa yang Patah Pertama
  • Mengapa Klien Pengembangan Adalah Langkah Berikutnya yang Tepat
  • Perubahan Mindset
• Prasyarat dan Konfigurasi Proyek
  • Mulai dengan Akun dan Layer CLI
  • Pasang Paket yang Membuat Alur Kerja Mungkin
  • Periksa Konfigurasi Aplikasi Anda Awal
  • Apa yang Harus Dilihat dalam Konfigurasi Awal yang Baik
• Membangun Klien Custom Anda dengan EAS
  • Alur Dasar EAS
  • Apa yang dilakukan profil pembangunan Anda secara nyata
  • Menginstal hasilnya
  • Apa yang tidak perlu Anda harapkan
• Menggunakan dan Membuat Debug dengan Klien Baru Anda
  • Sesi pembangunan 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
  • When the client tidak dapat terhubung ke Metro
  • When rebuilds tampak acak
  • Kegagalan pembangunan dan pergeseran tim

Mengapa Anda Perlu Melampaui Expo Go

Expo Go berguna pada awalnya. Ini menghilangkan gesekan pengaturan, 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 merupakan prototipe. Expo mendokumentasikan Expo Go sebagai sebuah laboratorium dan mencatat bahwa ia tidak dapat mengakurasi simulasi beberapa kemampuan native seperti notifikasi atau autentikasi OAuth, sementara model pembangunan pengembangan dibangun di sekitar expo-dev-client dan diposisikan sebagai sebuah “Debug” build untuk aplikasi produksi dalam pengenalan pembangunan Expo.

Apa yang patah dahulu

Dalam prakteknya, patah dahulu biasanya salah satu dari ini:

• Ketergantungan native: 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.
• QA Tim: Seorang tester memerlukan binary stabil yang mewakili pengaturan native aplikasi yang sebenarnya.

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

Expo Go sangat baik untuk membuktikan antarmuka. Ini adalah tempat yang lemah untuk memvalidasi perilaku produksi.

Mengapa klien pengembangan adalah langkah berikutnya 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, 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?” Itu pertanyaan yang tepat.

Jika Anda juga membandingkan model pengiriman aplikasi yang lebih luas, Capgo’s tulisan tentang alternatif Expo bisa menjadi 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. Ini bukanlah hal itu. Ini adalah pilihan alur kerja.

Anda menerima satu kekurangan untuk mendapatkan kontrol:

Alur Kerja

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 berasal dari melupakan konfigurasi dasar, bukan dari Expo sendiri.

Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai "lingkungan pengembangan yang lengkap" itu merupakan representasi dari lingkungan produksi yang nyata ketika aplikasi bergantung pada code native yang disesuaikan atau QA yang berkualitas produksi, seperti yang dibahas dalam ulasan Draftbit tentang Alat dev Expo dan bangunan pengembangan.

Mulai dengan akun dan lapisan CLI

Anda memerlukan dua hal yang berfungsi sebelum lapisan aplikasi menjadi penting:

1. Akses Expo ke CLI
2. Akses EAS ke CLI

Anda juga ingin masuk ke akun Expo Anda dari terminal. Tim sering 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 pekerjaan 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 perlu memperkenalkan kompleksitas pembangunan sebelum aplikasi dasar berfungsi.

Instal paket yang membuat alur kerja ini 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, 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 kita sendiri.”

Aturan praktis: Bangun klien pengembangan sekali ketergantungan native sudah stabil cukup untuk rekan tim untuk 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 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 memperketatnya 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

Pakailah daftar periksa ini sebelum memulai EAS:

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

Membangun Klien Kustom Anda dengan EAS

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

Expo merekomendasikan alur kerja build pengembangan untuk aplikasi dengan klien native code: instal 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 bahkan jika langkah pertama terasa asing:

1. Instal dan autentikasi dengan EAS CLI
2. Konfigurasi atau konfirmasi pengaturan pembangunan
3. Buat profil pembangunan untuk pengembangan
4. Aktifkan pembangunan untuk iOS atau Android
5. Pasang hasil biner pada perangkat atau simulator

Apa yang EAS berikan 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:

• mengandung perilaku klien pengembangan
• mudah untuk pengembang dan tes untuk diluncurkan
• terhubung ke server Metro selama pekerjaan sehari-hari
• 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 .apk pada perangkat fisik atau emulator.
• Di iOS: Anda akan bekerja dengan .ipa atau output yang kompatibel dengan simulator tergantung pada target.
• Untuk rekan tim: Bagikan hasil 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 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 dikemudikan 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 Membangun Kembali dengan Klien Baru Anda

Kali pertama Anda membuka klien yang diinstal dan menghubungkannya ke Metro, perbedaan 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 kantor profesional..

Sebuah sesi biasa terlihat seperti ini:

Anda menarik cabang terbaru. Klien pengembangan yang terinstal 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 memeriksa perilaku yang bergantung pada lingkungan native asli. Klien khusus memungkinkan Anda menguji aliran-aliran tersebut tanpa keluar dari lingkaran reguler Anda.

Alat debugging yang penting

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

Antarmuka Launcher:

• Bermanfaat ketika beralih antara lingkungan atau server yang dihosting oleh tim rekan. Menu pengembang:
• Alat debugging yang penting adalah alat yang sebenarnya membantu Anda dalam mengatasi masalah sehari-hari. Memberikan aksi yang Anda harapkan selama iterasi aktif.
• Pengintai Jaringan: Membantu ketika tampilan 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. Biasanya, bug ada di luar komponen yang Anda lihat.

Keuntungan yang nyata. Satu file biner yang terinstal dapat memvalidasi beberapa lingkungan 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 cabang lokal.

Jika tim Anda juga mengirimkan shell mobile berbasis web, Capgo’s Petunjuk Ultimate untuk Mengatasi Masalah Capacitor adalah patut dibaca untuk disiplin debugging yang lebih luas. Alatnya berbeda, tetapi disiplinnya sama: periksa perilaku transportasi, lingkungan, dan waktu eksekusi sebelum menebak.

Apa yang baik dan apa yang tidak baik

Apa yang baik:

Apa yang tidak berfungsi dengan baik:

• Menganggap klien sebagai benda yang dapat dibuang: Jika tim tidak menjaganya, kebingungan akan menyebar dengan cepat.
• Mengabaikan batasan pembangunan ulang asli: Setelah ketergantungan native berubah, 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 berhenti 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 benar karena tim telah setuju pada saluran, profil build, dan tujuan pembaruan.

Dimana CI/CD berada

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

Gaya umum seperti ini:

• Perubahan pull request: CI membuat atau memvalidasi build pengembangan ketika ketergantungan native telah berubah.
• Struktur berdasarkan cabang: Berbagai cabang menerjemahkan ke berbagai saluran pembaruan atau target server.
• Alur kerja 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 membutuhkan pembangunan ulang. Tester tahu apakah mereka memvalidasi perubahan asli atau pembaruan yang disampaikan di atas biner yang sudah ada.

Peran pembaruan hidup

Klien pengembang seringkali 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 pemisahan yang berguna:

Panduan integrasi CI/CD __CAPGO_KEEP_0__ untuk update OTA menunjukkan model operasional yang sama pada sisi __CAPGO_KEEP_0__. Ini adalah salah satu pilihan untuk tim yang ingin memiliki saluran rollout yang dikendalikan dan otomatisasi seputar pengiriman update. Capgo’s CI/CD integration guide for OTA updates Polanya yang dapat diandalkan adalah sederhana. Bangun ketika perubahan native Capacitor terjadi. Publikasikan ketika binary yang terinstal sudah mengandung semua yang perubahan butuhkan.

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

Pengaturan teknis yang penting, tetapi aturan operasional yang lebih penting:

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 baru, izin, atau pembaruan native SDK tidak boleh menjadi keputusan subjektif.
• Tetapkan strategi satu klien yang dapat diinstal per lingkungan: Banyak variasi dapat menciptakan kebisingan dukungan.
• Pastikan validasi pembaruan eksplisit: Seseorang harus memastikan bahwa pembaruan berlaku dan meluncurkan di dalam binary yang sama yang tim harapkan.

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

Pitfall dan Solusi Umum

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

Masalah 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 muncul dalam hal ini Video Pemecahan Masalah 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.
• 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.

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:

Ini bukan kelemahan dalam alur kerja. Ini adalah alur kerja melakukan apa yang harus dilakukan.

Gagal build dan pergeseran tim

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

• Tidak cocoknya dependensi: A versi paket tidak sesuai dengan proyek lainnya.
• Asumsi plugin native: A plugin konfigurasi mengharapkan pengaturan proyek tidak ada.
• Kesalahpahaman kredit: Tanda tangan atau akses akun tidak konsisten di tim.
• Harapan lokal yang ketinggalan: Seseorang menganggap bangun kembali tidak diperlukan ketika sebenarnya perlu.

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 stack yang berbeda: banyak ‘bug aplikasi’ sebenarnya adalah bug pengiriman, lingkungan, atau bug versi.

Klien pengembangan Expo bekerja dengan baik ketika tim menganggap keandalan lingkungan sebagai bagian dari keahlian. Bukan sebagai hal yang dilupakan. 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 terkendali untuk membarui JavaScript, aset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan langsung, pengendalian peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron.