Guida Anda untuk Klien Pengembangan Expo

Anda biasanya sudah siap untuk klien pengembangan Expo pada saat yang tepat ketika Expo Go mulai berbohong kepada Anda.

Aplikasi tersebut 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 meng-debug aplikasi Anda. Anda meng-debug 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 Harus Melangkah Lebih Jauh dari Expo Go
  • Apa yang Paling Pertama Rusak
  • Mengapa Klien Pengembangan Adalah Langkah Berikutnya yang Tepat
  • Pergeseran Dalam Pikiran
• Persyaratan dan Konfigurasi Proyek
  • Mulai dengan Akun dan CLI Layer
  • Instal Paket yang Membuat Alur Kerja Mungkin
  • Periksa Konfigurasi Aplikasi Anda Pada Awalnya
  • Apa yang Seharusnya Konfigurasi Awalnya Terlihat
• Membangun Klien Custom Anda dengan EAS
  • Alur Dasar EAS
  • Apakah Profil Bangun Anda Benar-Benar Melakukan
  • Menginstal Hasilnya
  • Apakah yang Tidak Harus Diharapkan
• Menggunakan dan Mengdebug dengan Klien Baru Anda
  • Sesi Pengembangan Normal
  • Alat Debug yang Paling Penting
  • Apakah yang Berfungsi Baik dan Apa yang Tidak
• Integrasi dengan CI/CD dan Live Update
  • Dimana CI/CD Berada
  • Peran Live Update
  • Habitan Tim yang Mencegah Kacau
• Menyelesaikan Kesulitan Umum dan Solusi
  • When klien tidak dapat terhubung ke Metro
  • When rebuild tampak acak
  • Gagal membangun dan perubahan tim

Mengapa Anda Perlu Bergerak Lebih Jauh dari 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 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 produksi di pengenalan pembangunan Expo.

Apa yang pertama kali rusak.

Dalam prakteknya, kerusakan pertama biasanya salah satu 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: Sandbox tidak mencerminkan bagaimana aplikasi produksi akan meminta izin atau menerima event.
• QA Tim: Seorang tester memerlukan binary stabil yang merepresentasikan pengaturan native aplikasi yang sebenarnya.

Kerusakan-kerusakan itu bukanlah kasus sampingan. Mereka adalah tahap normal dalam proyek mobile nyata.

Expo Go sangat baik untuk membuktikan antarmuka. Namun, itu merupakan tempat yang lemah untuk memvalidasi perilaku produksi.

Mengapa klien pengembangan adalah langkah yang tepat berikutnya

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 terhadapnya, bukan bergantung pada kontainer generic.

Pergeseran itu lebih penting daripada yang terdengar. Saat 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 bisa menjadi 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 sebagai tugas pengaturan satu kali. Tidak, itu merupakan pilihan alur kerja.

Anda menerima satu perdagangan untuk mendapatkan kendali:

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 Anda dalam keadaan yang dapat bertahan dari build yang dapat diulang. Banyak upaya pertama yang gagal datang dari melupakan konfigurasi dasar, bukan dari Expo itu sendiri.

Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai “lingkungan pengembangan yang lengkap” 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 akun dan layer CLI

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

1. Akses Expo CLI
2. Akses EAS 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 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: Jangan memperkenalkan kompleksitas pembangunan sebelum aplikasi dasar berfungsi.

Pasang 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.

Pasangnya 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 binary pengembangan kita sendiri.”

Aturan praktis: Buat klien pengembangan sekali ketergantungan native sudah stabil cukup untuk rekan tim Anda untuk menginstal dan menggunakan binary yang sama.

Periksa konfigurasi aplikasi Anda awal

Banyak kebingungan datang dari menganggap app.json atau app.config.js sebagai metadata saja. Tidak. File-file ini mendefinisikan identitas.

Pastikan proyek memiliki:

• Apa nama aplikasi unik: Bermanfaat ketika pengembang menginstal variasi yang berbeda pada satu perangkat.
• Apa identifikasi paket atau bundle unik: Diperlukan 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 membangun pertama kali. Panduan Capgo untuk Mengatur lingkungan lokal Capacitor tidak khusus Expo, tapi itu adalah pengingat yang baik bahwa kerja mobile yang dapat direproduksi dimulai dengan perangkat lokal yang stabil dan konfigurasi eksplisit.

Apa konfigurasi yang baik pertama kali

Pakai 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

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, 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 bahkan jika langkah pertama terasa asing:

1. Instal dan autentikasi dengan EAS CLI
2. Menginisialisasi atau memastikan konfigurasi pembangunan
3. Membuat profil pembangunan untuk pengembang
4. Mengaktifkan pembangunan untuk iOS atau Android
5. Menginstal file biner hasilnya pada perangkat atau simulator

Yang diberikan oleh EAS adalah konsistensi. Sebaliknya, pengembang tidak perlu mengimprovisasi keadaan pembangunan native lokal, tim dapat menghasilkan file biner dari definisi pembangunan bersama.

Mengapa profil pembangunan Anda melakukan hal ini

A development Profil bukan hanya label. Profil ini memberitahu sistem pembangunan bahwa file 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 digunakan ulang hingga ketergantungan native berubah

Ini juga di mana CI mulai menjadi lebih praktis. Setelah profil build ada dan berperilaku secara prediktif, Anda bisa mengotomatisasinya.

Jika tim Anda berpikir lebih luas tentang bagaimana React Native masuk ke dalam 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

Setelah build selesai, tatal hasilnya seperti aplikasi binary nyata, karena itu apa yang dia adalah.

• Pada Android: Anda akan menginstal sebuah .apk pada perangkat fisik atau emulator.
• Pada iOS: Kamu akan bekerja dengan .ipa atau simulator yang kompatibel tergantung pada target.
• For rekan tim: Bagikan 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

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 dikendalikan plugin, kamu akan membutuhkan build pengembangan segar. Itu normal. Hadiahnya adalah pekerjaan JavaScript sehari-hari kamu masih bergerak cepat di dalam klien yang mencerminkan aplikasi kamu.

Berjalan dan Debugging dengan Klien Baru

Kali pertama kamu membuka klien yang terpasang dan menghubungkannya ke Metro, perbedaannya jelas. Ini terasa seperti Expo, tapi tidak lagi dalam arti mainan.

Mulai server dengan npx expo start --dev-clientKemudian buka klien pengembangan di simulator, emulator, atau perangkat fisik dan hubungkan melalui antarmuka launcher UI. Launcher itu salah satu perubahan penting yang diperkenalkan oleh expo-dev-clientbersama dengan dukungan debugging seperti inspeksi permintaan jaringan, seperti yang terdokumentasi di halaman Expo SDK untuk klien dev.

Sebuah sesi pengembangan normal

Sebuah sesi biasa terlihat seperti ini:

Kamu pull branch terbaru. Klien pengembangan yang terpasang sudah ada di perangkatmu. Kamu menjalankan Metro, meluncurkan aplikasi, dan terhubung ke server saat ini. Kemudian kamu bekerja sebagaimana biasa, mengubah JavaScript dan melihat perubahan dengan cepat.

Perbedaan besar muncul ketika kamu membutuhkan memeriksa perilaku yang bergantung pada lingkungan native yang nyata. Klien khusus memungkinkan kamu menguji aliran-aliran tersebut tanpa keluar dari lingkaran biasa.

Alat debugging yang penting

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

• Antarmuka Launcher: Terutama berguna ketika beralih antara lingkungan atau server yang dihosting oleh rekan kerja.
• Menu pengembang: Gives you the actions you expect during active iteration.
• Pengintai Jaringan: Membantu ketika tampilan UI terlihat rusak tetapi masalah sebenarnya adalah gagal permintaan, status autentikasi, atau pengaturan lingkungan yang salah.

Jika API gagal saat menjalankan klien pengembangan, periksa jalur permintaan dan asumsi lingkungan sebelum menyentuh UI code. Biasanya, bug ada di luar komponen yang Anda lihat.

Keuntungan praktisnya adalah: satu file biner yang terinstal dapat memvalidasi beberapa lingkungan 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 Capacitor adalah bacaan yang patut untuk mindset debugging yang lebih luas. Alatnya mungkin berbeda, tetapi disiplinnya sama: periksa perilaku transportasi, lingkungan, dan runtime sebelum menebak.

Apakah yang baik dan tidak baik

Apakah yang baik:

Apa yang tidak berfungsi dengan baik:

• Menganggap klien sebagai barang yang dapat dibuang: Jika tim tidak menjaganya, kebingungan akan muncul 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.

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 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 build, dan tujuan pembaruan.

Dimana CI/CD berada?

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

Gaya umum yang sering digunakan seperti ini:

• Perubahan pull request: CI membuat atau memvalidasi build pengembangan ketika ketergantungan native berubah.
• Branch-based environments: Dari cabang yang berbeda menerjemahkan ke saluran pembaruan atau target server yang berbeda.
• Alur kerja tester yang dibagikan: QA menginstal satu atau lebih klien pengembang yang diketahui dan mengganti konteks melalui peluncur 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 pengembang dan pembaruan yang dipublikasikan dalam shell aplikasi yang mirip produksi, seperti yang dijelaskan sebelumnya dalam dokumentasi Expo.

Memungkinkan pemisahan yang berguna:

Untuk tim di luar stack pembaruan Expo, Capgo’s panduan integrasi CI/CD untuk pembaruan OTA menunjukkan model operasional yang mirip di sisi Capgo. Ini adalah salah satu pilihan untuk tim yang ingin memiliki saluran peluncuran yang dikendalikan dan otomatisasi seputar pengiriman pembaruan. Polanya yang dapat diandalkan sederhana. Bangun ketika perubahan native Capacitor terjadi. Publish ketika binary yang terpasang 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 penting, tetapi aturan operasional lebih penting:

Switch channel or server in the installed client

• Berikan nama channel 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 meluncurkan 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 jika Anda tahu di mana cari. Mereka terasa misterius karena gagal 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 troubleshooting Expo Dev Client.

Mengapa klien tidak terhubung ke Metro

Masalah ini yang 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 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.

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 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 muncul.

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 utama seringkali 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: Tidak konsisten dalam tanda tangan atau akses akun di tim.
• Harapan lokal yang ketinggalan: Seseorang menganggap bahwa bangunan segar tidak diperlukan ketika sebenarnya perlu.

Artikel Capgo tentang masalah dan solusi pembaruan hidup umum untuk pengembang bermanfaat sebagai bacaan tambahan untuk sisi rilis masalah ini. Stack yang berbeda, pelajaran yang sama: 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 teknik. Bukan sebagai hal yang diabaikan. 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 mengirimkan pembaruan JavaScript, aset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan live, pengendalian peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron workflow.