Panduan Pengembang Expo Anda

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

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

Tabel Konten

• Mengapa Anda Perlu Melangkah Lebih Jauh dari Expo Go
  • Apa yang patah dahulu
  • Mengapa klien pengembangan adalah langkah berikutnya yang tepat
  • Perubahan mindset
• Persyaratan dan Konfigurasi Proyek
  • Mulai dengan akun dan lapisan CLI
  • Instal paket yang membuat alur kerja mungkin
  • Periksa konfigurasi aplikasi Anda sebelumnya
  • Apa yang terlihat seperti konfigurasi awal yang baik
• Membangun Klien Custom Anda dengan EAS
  • Aliran dasar EAS
  • Apa yang sebenarnya dilakukan profil build Anda
  • Menginstal hasilnya
  • Apa yang tidak bisa Anda harapkan
• Menggunakan dan Membuat Debug dengan Klien Baru Anda
  • Sesi pengembangan 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
  • Ketika klien tidak dapat terhubung ke Metro
  • Ketika rekonstruksi 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 umpan balik yang cepat. Itu tepatnya mengapa banyak tim memulainya.

Masalah dimulai ketika aplikasi tidak lagi prototipe. Expo mendokumentasikan Expo Go sebagai sandbox dan mencatat bahwa tidak dapat menyimulasikan dengan akurat beberapa kemampuan native seperti pemberitahuan atau autentikasi OAuth, sementara model pembangunan pengembangan dibangun sekitar expo-dev-client dan diposisikan sebagai “Debug” build untuk aplikasi produksi tingkat dalam pembangunan Expo pengenalan tools.

Apa yang patah terlebih dahulu

Dalam prakteknya, kerusakan pertama 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 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. Itu adalah tempat yang lemah untuk memvalidasi perilaku produksi.

Mengapa klien pengembang adalah langkah yang tepat berikutnya

Klien pengembangan Expo memberikan Anda sebuah 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 umum.

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, Capgo’s tulisan tentang alternatif Expo adalah konteks yang berguna karena menyoroti di mana tim mulai mencari ke luar dari alur kerja sandbox.

Perubahan mindset

Sangat besar kesalahan yang saya lihat adalah menganggap klien pengembangan Expo seperti tugas pengaturan satu kali. Tidak. Ini adalah pilihan alur kerja.

Anda menerima satu perdagangan untuk mendapatkan kontrol:

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

Dokumentasi dan panduan ekosistem Expo menjelaskan build pengembangan sebagai “fully featured development environment” that’s representative of a real production environment once apps depend on custom native code or production-grade QA, as covered in Draftbit’s overview of yang mewakili lingkungan produksi yang nyata sekali aplikasi bergantung pada native __CAPGO_KEEP_0__ atau QA yang berkualitas produksi, seperti yang dibahas dalam ringkasan Draftbit tentang alat-alat pengembangan Expo dan build 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 terdaftar ke dalam akun Expo dari terminal. Tim sering melupakan hal ini karena perintah lokal dapat terlihat baik sampai build remote pertama atau prompt kredential muncul.

Pengaturan yang bersih biasanya mencakup:

• Sesi akun Expo: 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.
• Proyek yang sudah berjalan lokal: Jangan memperkenalkan kompleksitas build sebelum aplikasi startup dasar berfungsi.

Instal paket yang membuat alur kerja ini mungkin

Pusat dari pengaturan ini adalah expo-dev-clientTidak ada, Anda tidak memiliki launcher kustom dan shell native yang berorientasi debug yang menggambarkan alur kerja klien pengembangan Expo.

Instalnya di proyek aplikasi, lalu verifikasi konfigurasi Expo Anda konsisten. Perintah yang tepat mungkin berbeda tergantung pada 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.”

Hukum praktis: Bangun klien pengembangan sekali daftar ketergantungan native stabil cukup untuk rekan kerja untuk menginstal dan menggunakan binary yang sama.

Periksa konfigurasi aplikasi Anda sebelumnya

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

Pastikan proyek memiliki:

• Nama aplikasi unik: Berfungsi baik ketika pengembang menginstal variasi yang berbeda pada satu perangkat.
• Identifikasi paket unik atau bundle: Penting untuk pembangunan asli dan tanda tangan yang lebih lanjut.
• 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 direproduksi dimulai dengan peralatan lokal yang stabil dan konfigurasi eksplisit.

Apa yang terlihat seperti konfigurasi yang baik

Gunakan daftar periksa ini sebelum memulai EAS:

Tujuan bukanlah kesempurnaan. Tujuan adalah membuat pembangunan pertama kali menjadi menenangkan. Itu adalah kemenangan.

Membangun Klien Kustom Anda dengan EAS

Poin ini adalah tempat di mana alur kerja menjadi nyata. Anda berhenti berbicara tentang klien khusus dan menghasilkan satu.

Expo merekomendasikan alur kerja pembangunan untuk aplikasi dengan klien native khusus code: instal expo-dev-client, buatlah 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 pembangunan ulang.

Alur dasar EAS

Urutan ini sederhana meskipun langkah pertama terasa asing:

1. Instal dan autentikasi dengan EAS CLI
2. Konfirmasi atau inisialisasi konfigurasi pembangunan
3. Buatlah profil pembangunan pengembangan
4. Aktifkan bangun untuk iOS atau Android
5. Pasang file biner hasilnya pada perangkat atau simulator

Apa yang EAS berikan adalah konsistensi. Sebaliknya, setiap pengembang tidak perlu mengimprovisasi kondisi bangun native lokal, tim dapat menghasilkan file biner dari definisi bangun bersama.

Apa yang profil bangun Anda sebenarnya lakukan

A development Profil bukan hanya label. Profil memberitahu sistem bangun bahwa file 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
• tetap dapat digunakan kembali hingga ketergantungan native berubah

Hal ini juga merupakan tempat dimana CI menjadi lebih praktis. Setelah profil bangun ada dan berperilaku secara prediktif, Anda dapat 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. Hal ini relevan karena klien pengembangan seringkali menjadi bagian dari layer dasar operasional ketika tim mengirimkan perubahan produk yang lebih sering di berbagai permukaan mobile.

Langkah-langkah singkat dapat membantu jika Anda ingin melihat aliran dalam aksi:

Menginstal hasilnya

Setelah proses build selesai, tatal keluaran seperti sebuah aplikasi biner nyata, karena itu apa yang dia

• Pada Android: Anda akan menginstal sebuah .apk pada perangkat fisik atau emulator.
• Pada iOS: Anda akan bekerja dengan sebuah .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: 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 Anda menambahkan modul native baru, mengubah izin, memperbarui SDK-level dependensi native, atau memodifikasi konfigurasi native yang dikendalikan plugin, Anda akan membutuhkan build pengembangan segar. Itu normal. Hadiahnya adalah bahwa pekerjaan JavaScript sehari-hari Anda masih bergerak cepat di dalam klien yang memantulkan aplikasi Anda.

Melakukan dan Membangun 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-client, bersama dukungan debugging seperti inspeksi permintaan jaringan, seperti yang dokumentasikan di halaman Expo SDK untuk klien dev.

Sebuah sesi pengembangan normal

Sebuah sesi yang biasa terlihat seperti ini:

Kamu menarik cabang terbaru. Klien pengembangan yang terpasang sudah ada di perangkatmu. Kamu memulai 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 untuk memeriksa perilaku yang bergantung pada lingkungan native yang sebenarnya. Klien khusus memungkinkan kamu untuk menguji aliran-aliran tersebut tanpa harus keluar dari lingkaran regulermu.

Alat-alat debugging yang penting

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

• Antarmuka Launcher: Bermanfaat ketika kamu beralih antara lingkungan atau server yang dihosting oleh rekan kerjamu.
• Menu pengembang: Memberikan kamu aksi-aksi yang kamu 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 di 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 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 branch lokal.

Jika tim Anda juga mengirimkan shell mobile berbasis web, Capgo’s guide debugging ultimate untuk Capacitor apps adalah patut dibaca untuk disiplin debugging yang lebih luas. Alat-alatnya berbeda, tetapi disiplinnya sama: periksa perilaku transportasi, lingkungan, dan runtime sebelum menebak.

Apa yang baik dan apa yang tidak baik

Apa yang baik:

Apa yang tidak berfungsi dengan baik:

• Menganggap klien sebagai barang yang dapat dibuang: Jika tim tidak memelihara, kebingungan akan menyebar dengan cepat.
• Mengabaikan batasan pembangunan ulang native: Setelah perubahan terjadi pada dependensi native, klien yang ketinggalan waktu akan 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 berhenti menjadi pengaturan pribadi dan menjadi bagian dari operasional tim.

Alur kerja yang matang biasanya memisahkan kekhawatiran.

Perubahan JavaScript dan asset bergerak melalui jalur pembaruan yang lebih cepat.

Pengulas dan QA tidak perlu bertanya apakah mereka sedang menguji hal yang tepat karena tim telah setuju pada saluran, profil build, dan tujuan pembaruan.

Tim profesional yang bekerja sama pada alur kerja otomatisasi CI/CD di layar display kantor besar.

• Di mana CI/CD berada Klien pengembangan bekerja dengan baik dengan CI karena memberikan otomatisasi target stabil.
• Polanya yang umum seperti ini: Perubahan pull request:
• Alur kerja tester bersama: QA menginstal satu atau lebih klien pengembang yang diketahui dan mengganti konteks melalui launcher 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 langsung:

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.

Itu membuka pembagian yang berguna:

Untuk tim di luar stack update Expo, Capgo’s Panduan Integrasi CI/CD untuk Update OTA menampilkan 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 adalah sederhana. Bangun ketika perubahan native code terjadi. Publikasikan ketika binary yang terpasang sudah mengandung semua yang perubahan tersebut butuhkan.

Habits Tim yang Mencegah Kacau

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

• Berikan nama saluran dengan jelas: staging, production, dan nama preview harus jelas.
• Triggers Rebuild Dokumen: Pengembangan plugin, perubahan izin, atau pembaruan native SDK tidak boleh menjadi keputusan yang berdasar.
• Strategi: Tunggu satu klien yang dapat diinstal per lingkungan: Terlalu banyak variasi menciptakan kebisingan dukungan.
• Validasi pembaruan harus eksplisit: Seseorang harus memastikan bahwa pembaruan berlaku dan meluncur di dalam binary yang sama yang diharapkan tim.

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 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 di perangkat fisik karena segmentasi jaringan lokal, VPN, atau aturan firewall di lingkungan perusahaan dan tim yang terdistribusi, seperti yang disinggung dalam video ini Video Pemecahan Masalah Klien Dev Expo.

Ketika klien tidak terhubung ke Metro

Masalah ini yang memakan waktu paling lama karena aplikasi tampak rusak ketika aplikasi sering kali baik.

Periksa hal-hal ini terlebih dahulu:

• Asumsi jaringan yang sama: Perangkat dan laptop mungkin terlihat terhubung sambil duduk di segmen terisolasi.
• Penghalang VPN: VPN korporat atau pribadi dapat mengarahkan lalu lintas dalam cara yang tidak ditolerir Metro dengan baik.
• 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. Konfirmasi perangkat dapat mencapai mesin yang menjalankan Metro.

When rebuilds tampaknya acak-acakan

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:

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

Gagal build dan pergeseran tim

Ketika build gagal, penyebab utama seringkali salah satu dari ini:

• Kesalahan dependensi: Versi paket tidak sesuai dengan proyek yang lain.
• Asumsi plugin native: Suatu plugin konfigurasi mengharapkan pengaturan proyek yang tidak ada.
• Kesulitan autentikasi: Tanda tangan atau akses akun tidak konsisten di seluruh tim.
• Harapan lokal yang ketinggalan: Seseorang menganggap bahwa bangunan segar tidak diperlukan ketika sebenarnya perlu.

Capgo’s artikel tentang masalah pembaruan hidup yang umum dan solusi untuk pengembang bermanfaat sebagai bacaan tambahan untuk sisi rilis masalah ini. Menghadapi masalah 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 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 memperbarui JavaScript, asset, dan konfigurasi tanpa menunggu tinjauan toko, Capgo adalah salah satu pilihan untuk dievaluasi. Ini menyediakan pembaruan hidup, pengendalian peluncuran, dan integrasi CI/CD untuk Capacitor dan Electron.