Expo Image Picker: Panduan Komprehensif untuk 2026

Anda mungkin telah mencapai titik di mana UI sudah siap, layar profil memiliki tombol "Unggah foto", dan sekarang bagian yang mudah tiba-tiba tidak mudah lagi. Aliran pilihan gambar yang sebenarnya menyentuh izin native, antarmuka yang dikontrol oleh OS, bentuk kembali yang berbeda dari yang banyak pengembang harapkan, dan beberapa detail waktu build yang hanya muncul setelah Anda kirimkan build nyata.

Itu di mana Pilih Gambar Expo masuk. Ini adalah library Expo resmi untuk membuka antarmuka sistem untuk memilih gambar dan video dari perpustakaan perangkat atau mengambil foto dengan kamera, seperti yang dijelaskan di Repositori Paket Expo. Dalam prakteknya, itu berarti Anda mendapatkan jembatan yang dapat diandalkan ke input media native, tetapi tidak pengalaman media yang kustom yang berperilaku identik di setiap perangkat.

Panduan ini ditulis untuk implementasi pertama, bukan demo. Fokus pada keputusan yang berpengaruh di produksi: pengaturan alur kerja yang dielola versus alur kerja yang tidak dielola, pengelolaan izin yang tidak akan mengejutkan Anda nanti, parsing hasil yang aman, dan pola unggah yang praktis setelah pengguna memilih file. Jika Anda bekerja di pengaturan native yang kustom, juga membantu untuk memahami bagaimana ini berbeda dari alur kerja pengembang Expo Alur Kerja Pengembang Expo.

Daftar Isi

• Mulai Dengan Expo Pilih Gambar
• Pemasangan dan Konfigurasi Dasar
  • Konfigurasi Alur Terkelola
  • Detail Konfigurasi React Native Tanpa Kelola
• Akses Kamera dan Media Library
  • Komponen yang Sederhana Tapi Aman
  • Alur Perpustakaan dan Kamera
  • Apa yang Dapat Diharapkan dari Antarmuka Sistem
• Mengelola Hasil Pilih dan Opsi
  • Membaca Objek Hasil dengan Benar
  • Opsi yang Mengubah perilaku Hilir
  • URI versus base64
  • A pola hasil yang lebih aman untuk aplikasi nyata
• Pola lanjutan dan perbedaan platform
  • A pola unggah yang lebih praktis
  • Dimana perbedaan platform sebenarnya berlaku
  • Perbedaan alur kerja yang diatur vs. alur kerja yang tidak diatur
• Pengaturan masalah umum
  • Pemeriksaan cepat untuk gagal umum
  • Daftar checklist produksi singkat

Mengawali Penggunaan Expo Image Picker

Seorang manajer produk meminta foto profil. Sepekan kemudian, fitur yang sama juga memerlukan unggah bukti pembelian, pengambilan foto untuk laporan insiden, dan ulang coba ketika pengguna menolak izin pertama kali. Input gambar memperluas cepat karena menyentuh izin native, UI yang dimiliki OS, pengelolaan file sementara, dan alur unggah backend.

expo-image-picker Apakah itu modul Expo SDK untuk itu? Ia membuka picker platform atau UI kamera dan mengembalikan media yang dipilih dalam bentuk yang dapat dihandle oleh React Native code. JavaScript API kecil. Tantangan utama terletak pada mendapatkan setup native, alur izin, dan pengelolaan hasil yang benar pada proyek yang diatur dan tidak diatur.

Perbedaan utama adalah sederhana. Anda membiarkan iOS dan Android menampilkan UI media sendiri daripada membangun picker kustom. Biasanya itu memberikan hasil yang lebih baik: pengguna sudah mengerti layar sistem, prompt izin berperilaku seperti yang diharapkan OS, dan tim Anda menghindari menjaga implementasi galeri dalam JavaScript.

Integrasi ini seperti fitur native dengan interface React.

Menggunakan mindset ini membantu karena mode gagal jarang terjadi pada tombol yang memanggil picker. Biasanya datang dari salah satu tiga tempat:

• Konfigurasi Native: pengaturan plugin hilang, string izin yang salah, atau build yang ketinggalan zaman setelah mengubah konfigurasi
• Penggunaan Runtime: pengguna dapat menolak akses, memberikan akses library yang terbatas pada iOS, atau membatalkan aliran tanpa memilih apa-apa
• Pengolahan Hasil: hasil API saat ini kembali sebagai assets array, sehingga contoh lama yang membaca result.uri langsung gagal

Pilihan alur kerja juga mengubah jalur pengaturan. Dalam aplikasi Expo yang diatur, sebagian besar pekerjaan native hidup di konfigurasi aplikasi dan memerlukan rebuild ketika konfigurasi itu berubah. Dalam aplikasi yang tidak berpakaian, Anda masih mendapatkan modul Expo API, tetapi Anda perlu memverifikasi pengaturan proyek iOS dan Android yang lebih langsung. Jika tim Anda menggunakan klien kustom bukan Expo Go, panduan ini cocok digunakan bersama Capgo’s penjelasan tentang bagaimana klien pengembangan Expo mengubah pengujian modul native.

Karena itu, hal ini sangat penting untuk bagian sisa panduan ini karena jalur bahagia hanya setengah dari cerita. Implementasi picker yang solid adalah ketika itu berfungsi dalam kedua alur kerja, mengatasi kekacauan izin platform tanpa mengejutkan pengguna, dan mengirimkan file yang dapat digunakan ke layer unggah Anda daripada berhenti di preview lokal.

Instalasi dan Konfigurasi Dasar

Instalasi membutuhkan satu perintah. Mengatur konfigurasi native yang tepat adalah yang menentukan apakah picker berfungsi di perangkat nyata, di klien dev kustom, dan di build produksi Anda.

expo-image-picker Memberikan wajah React terhadap API atas picker-platform untuk foto, video, dan pengambilan kamera. Panggilan JavaScriptnya sederhana. Namun, pengaturan tidaklah mudah karena akses foto dan kamera dikendalikan oleh iOS dan Android, bukan oleh React Native.

Mulai dengan installer versi-aware Expo:

npx expo install expo-image-picker

Pilih expo install atau npm install Expo memasang versi paket yang sesuai dengan __CAPGO_KEEP_0__ Anda, sehingga menghindari masalah kompatibilitas native yang umum. Jika Anda membandingkan bagaimana modul Expo masuk ke dalam proses rilis Anda, ini yarn add. Expo matches the package version to your SDK, which avoids a common class of native compatibility problems. If you are comparing how Expo modules fit into your release process, this merupakan referensi yang berguna. Jangan gunakan

Setup aliran kerja yang diatur

Dalam aliran kerja yang diatur, deklarasikan plugin di konfigurasi aplikasi agar Expo dapat menerapkan perubahan native pada waktu build.

Contoh dengan app.json:

{
  "expo": {
    "plugins": ["expo-image-picker"]
  }
}

Setup ini adalah yang minimum. Pada prakteknya, tim biasanya menambahkan teks izin juga, terutama pada iOS di mana prompt sistem harus menjelaskan mengapa aplikasi membutuhkan akses. Tetapkan kata-kata kunci untuk tindakan pengguna. “Mengunggah foto profil” lebih baik daripada “Membutuhkan akses media.”

Detail operasional satu hal ini menyebabkan waktu yang banyak terbuang. Mengubah pluginsstring izin, atau konfigurasi native lainnya memerlukan rebuild. Mengeload JavaScript tidak menerapkan perubahan-perubahan tersebut. Di Expo Go, Anda juga terbatas oleh apa yang sudah termasuk dalam klien. Pada build pengembangan atau build produksi, proyek native menampilkan konfigurasi Anda hanya setelah build baru.

Detail setup React Native tanpa paket

Pada aplikasi tanpa paket, paket API tetap sama, tetapi Anda perlu memverifikasi lebih banyak proyek native sendiri. Penggunaan deskripsi iOS adalah hal pertama untuk dicek. Jika aliran Anda dapat membuka library, meluncurkan kamera, atau merekam video dengan suara, aplikasi Anda membutuhkan string izin yang sesuai di Info.plist sebelum Anda melakukan rebuild.

Daftar checklist yang berguna untuk proyek tanpa paket seperti ini:

1. Instal expo-image-picker dengan npx expo install expo-image-picker.
2. Tambahkan konfigurasi plugin jika proyek Anda menggunakan Expo config plugins.
3. Konfirmasi deskripsi penggunaan iOS sesuai dengan fitur yang Anda tunjukkan.
4. Rebuild aplikasi iOS dan Android setelah perubahan konfigurasi native apa pun.

Teks izin sering terlihat seperti kesalahan runtime karena UI code masih baik dan handler tombol berjalan. Namun, gagalnya terletak lebih rendah di stack. Saya biasanya memeriksa konfigurasi aplikasi dan apakah build saat ini sudah mencakup perubahan native terbaru sebelum menyentuh komponen code. Info.plist, the app config, and whether the current build includes the latest native changes before I touch the component code.

Tuliskan teks izin untuk aksi yang sebenarnya:

• Pengguna harus memahami mengapa mereka melihat prompt. Konfigurasi kamera dan library secara terpisah:
• Salah satu dapat berfungsi sementara yang lain masih gagal. Rebuild setelah perubahan native:
• Hot reload dan fast refresh tidak memperbarui izin native. Rebuild setelah perubahan native: hot reload dan fast refresh tidak memperbarui izin native.
• Test di perangkat: Perilaku simulator dapat menyembunyikan masalah izin dan kamera.

Jika picker berfungsi selama pengembangan tetapi gagal dalam TestFlight atau build Play Store, anggap itu sebagai masalah konfigurasi terlebih dahulu. Banyak kasus, itu adalah.

Akses Kamera dan Media Library

Pengguna mengetuk “Upload foto,” mengharapkan kamera atau library terbuka, dan aplikasi Anda memiliki satu tugas pada saat itu. Buka UI sistem yang tepat, tangani penolakan atau pembatalan tanpa mengganggu layar, dan kembalikan referensi file lokal yang dapat digunakan untuk melihat atau mengunggah.

Itu terdengar sederhana sampai Anda menguji baik build yang diatur dan build yang tidak diatur di iOS dan Android. JavaScript API tetap kompak, tetapi perilaku runtime masih bergantung pada pertanyaan OS, perangkat keras, dan bagaimana Anda mengonfigurasi izin native sebelumnya.

Komponen yang minimal tetapi aman

Alur dasar konsisten di proyek workflow Expo yang diatur dan tidak diatur. Minta izin relevan, luncurkan picker, periksa apakah pengguna membatalkan, kemudian baca asset pertama dari result.assets.

Komponen dasar terlihat seperti ini:

import { useState } from 'react';
import { View, Button, Image, Alert } from 'react-native';
import * as ImagePicker from 'expo-image-picker';

export default function PhotoInput() {
  const [imageUri, setImageUri] = useState<string | null>(null);

  const pickFromLibrary = async () => {
    const permission = await ImagePicker.requestMediaLibraryPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow photo library access.');
      return;
    }

    const result = await ImagePicker.launchImageLibraryAsync({
      mediaTypes: ['images'],
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  const takePhoto = async () => {
    const permission = await ImagePicker.requestCameraPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow camera access.');
      return;
    }

    const result = await ImagePicker.launchCameraAsync({
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  return (
    <View>
      <Button title="Choose from library" onPress={pickFromLibrary} />
      <Button title="Take photo" onPress={takePhoto} />
      {imageUri ? (
        <Image
          source={{ uri: imageUri }}
          style={{ width: 200, height: 200 }}
        />
      ) : null}
    </View>
  );
}

Tiga detail yang penting di sini.

• Minta izin library dan kamera secara terpisah. Mereka gagal secara independen.
• Tangani pembatalan sebagai aksi pengguna normal, bukan keadaan kesalahan.
• Baca dari assets[0], karena pemilih kembali array asset daripada tingkat atas uri.

Aliran perpustakaan dan kamera

Mulai dengan aliran perpustakaan jika Anda ingin jalur tercepat ke fitur yang berfungsi. Lebih mudah untuk diuji, berfungsi di lebih banyak pengaturan simulator, dan menghindari kasus perangkat keras kamera. Tambahkan dukungan kamera setelah jalur penanganan hasil stabil.

Jalur kamera memiliki cara lebih banyak untuk gagal dalam pengembangan. Support iOS Simulator terbatas. Emulator Android mungkin tidak menampilkan perilaku kamera yang sesuai dengan perangkat nyata. Dalam proyek sederhana, celah-celah itu dapat membuat Anda mencari komponen code meskipun masalah sebenarnya adalah konfigurasi native atau lingkungan uji.

Polanya UI yang bersih adalah meminta pengguna untuk sumber sebelum memanggil pemilih API:

const showPickerOptions = () => {
  Alert.alert('Upload image', 'Choose a source', [
    { text: 'Camera', onPress: takePhoto },
    { text: 'Photo Library', onPress: pickFromLibrary },
    { text: 'Cancel', style: 'cancel' },
  ]);
};

Pemisahan itu menjaga setiap fungsi fokus. Ini juga membuatnya lebih mudah untuk menambahkan analitis, flag fitur, atau aturan khusus backend nanti. Misalnya, beberapa tim memungkinkan unggahan perpustakaan untuk foto profil tetapi memerlukan tangkapan kamera segar untuk verifikasi identitas.

Jika aplikasi Anda yang lebih luas juga mendukung pola akses file di luar Expo atau Anda membandingkan konvensi di antara stack native, ini Referensi perpustakaan foto Capacitor bermanfaat sebagai konteks.

Demo singkat membantu ketika Anda menunjukkan aliran ini kepada rekan tim atau QA:

What untuk diharapkan dari antarmuka sistem

expo-image-picker membuka pemilih platform atau UI kamera. Aplikasi Anda tidak mengontrol setiap layar dalam aliran tersebut. Perbedaan ini penting karena “berfungsi pada perangkat saya” sering kali berarti “sistem operasi memungkinkan jalur yang saya tes.”

Pada iOS, pengguna mungkin memberikan akses library terbatas daripada akses penuh. Pada Android, perilaku pemilih dapat bervariasi tergantung pada versi OS dan kulit vendor. Dalam proyek aliran manajemen, Expo menghandle lebih banyak wiring native untuk Anda. Dalam proyek aliran dasar, Anda perlu memastikan bahwa aplikasi yang dibangun Anda termasuk perubahan izin native yang Anda buat. Situs panggilan JavaScript dapat sama persis dalam kedua kasus tersebut sementara hasil runtime berbeda.

Saya biasanya menguji kasus-kasus ini sebelum memanggil fitur selesai:

• permintaan izin pertama
• izin ditolak
• pengguna membatalkan
• pilihan library sukses
• penangkapan kamera sukses pada perangkat fisik
• pembacaan langsung URI lokal yang dikembalikan

Kasus-kasus tersebut dapat menerjemahkan secara langsung ke perilaku produksi nyata. Mereka juga mengatur langkah berikutnya dengan jelas jika Anda perlu mengirimkan file ke server, alur moderasi, atau endpoint publikasi seperti Instagram media publishing API.

Mengatasi Hasil dan Opsi Pilih

Hasil picker adalah bagian yang biasanya memerlukan logika produksi yang nyata. Antarmuka pengguna sistem mengembalikan objek yang terstruktur, bukan hanya jalur file, dan kesalahan kecil di sini dapat menyebabkan pratinjau rusak, unggahan kosong, atau aplikasi mogok setelah pengguna membatalkan.

Membaca objek hasil dengan benar

Bentuk hasil yang berpengaruh pada aplikasi Expo saat ini adalah result.assets[0].uriBukan tingkat atas result.uriDetail tersebut mempengaruhi baik proyek workflow yang diatur maupun yang tidak karena JavaScript API tetap sama meskipun pengaturan native berbeda di bawahnya.

Gunakan pola pertama pengaman:

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 1,
});

if (result.canceled) {
  return;
}

const asset = result.assets?.[0];
if (!asset) {
  return;
}

const { uri } = asset;
setImageUri(uri);

Ini mengatasi dua kasus gagal yang paling sering saya lihat. Pilih aset yang dibatalkan tidak memberikan akses untuk membaca, dan code yang mengasumsikan result.assets[0] Selalu ada akan gagal saat waktu eksekusi.

Setelah Anda memiliki URI, menampilkan pratinjau menjadi lebih mudah:

<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />

Jika Anda berencana untuk mengunggah nanti, simpan seluruhnya asset di sekitar objek, bukan hanya URI. Dalam prakteknya, fileName, mimeType, width, heightdan fileSize seringkali berguna untuk validasi, logging, atau membangun permintaan multipart yang lebih bersih.

Opsi yang mengubah perilaku hilir

Beberapa opsi pilihernya mempengaruhi lebih dari layar pilihan. Mereka membentuk ukuran file, perilaku editing, dan apa yang harus diterima backend Anda.

Beberapa kekurangan yang mudah terlewatkan:

• allowsEditing Bermanfaat ketika slot gambar memiliki bentuk atau ukuran yang tetap. Lebih tidak berguna jika server Anda melakukan pipeline crop sendiri dan Anda ingin file asli.
• quality Mempengaruhi waktu unggahan, tekanan memori, dan penyimpanan server. quality: 1 Tidak secara otomatis merupakan pilihan yang tepat.
• mediaTypes harus sesuai dengan aturan backend. Jika server menolak video, jangan biarkan picker mengembalikan mereka.
• base64 menggunakan ukuran payload yang lebih besar di memori. Hindari hal ini kecuali layanan penerima memerlukan hal ini.

Poin terakhir itu penting pada perangkat dengan memori rendah. URI file lokal biasanya lebih baik untuk tampilan pratinjau dan unggah berbagi bagian. Base64 memiliki penggunaan yang valid, tetapi lebih mahal dibandingkan dengan melewatkan referensi file.

URI versus base64

Untuk aplikasi kebanyakan, aturan sederhana adalah:

• Gunakan URI untuk pratinjau.
• Gunakan URI untuk unggah file.
• Gunakan base64 hanya ketika sistem penerima secara eksplisit meminta konten yang dikodekan.

Polanya menjaga pilihan code kecil dan lebih mudah untuk diuji. Pola ini juga sesuai dengan bagaimana banyak aliran media backend dibangun, termasuk layanan yang akhirnya menerbitkan ke platform eksternal seperti menerbitkan media Instagram ke API.

Jika tim Anda mengirimkan pembaruan OTA yang sering atau memindahkan aset gambar melalui pengiriman aplikasi, keputusan ukuran file di sini akan berdampak pada bagian pipa lainnya. Panduan ini tentang mengoptimalkan gambar untuk pembaruan aplikasi adalah mitra yang berguna untuk pengaturan pilihan.

Polanya yang lebih aman untuk aplikasi nyata

Untuk demo code, menyimpan hanya imageUri adalah cukup. Di produksi, simpan objek yang dinormalisasi sehingga langkah berikutnya, tampilan, validasi, unggah, atau ulangi, tidak perlu memulai kembali interpretasi respons pilihan mentah setiap kali.

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 0.8,
});

if (result.canceled || !result.assets?.length) {
  return;
}

const asset = result.assets[0];

setSelectedImage({
  uri: asset.uri,
  fileName: asset.fileName ?? 'upload.jpg',
  mimeType: asset.mimeType ?? 'image/jpeg',
  width: asset.width,
  height: asset.height,
  fileSize: asset.fileSize ?? null,
});

Ini memberikan bentuk yang dapat diprediksi di dalam aplikasi. Ini juga membuat proyek yang diatur dan proyek yang tidak diatur lebih mudah untuk tetap sejalan karena aplikasi code tetap stabil saat Anda bekerja melalui perbedaan native di tempat lain.

Pemeriksaan akhir yang satu ini membantu. Jangan mengaktifkan bidang hasil tambahan hanya karena itu. Mintalah data yang Anda ketahui Anda butuhkan, dan jaga pilihan tetap fokus pada seleksi daripada mengubahnya menjadi langkah pengolahan file umum.

Polanya yang Lebih Lanjut dan Perbedaan Platform

Fitur pemilih biasanya tidak sederhana lagi ketika gambar yang dipilih harus bertahan dari ulang coba, header autentikasi, perbedaan izin native, dan endpoint unggah nyata. expo-image-picker mengatasi pilihan dengan baik. Bagian fitur lainnya ada di aplikasi Anda.

Polanya Unggah yang Praktis

Untuk API yang mengharapkan unggah file, FormData masih merupakan default yang paling aman. Polanya ini berfungsi di backend yang umum seperti Rails, Node, Laravel, Django, dan Go, dan menjaga pemilih tetap terpisah dari kekhawatiran transportasi.

async function uploadImage(imageUri: string) {
  const formData = new FormData();

  formData.append('file', {
    uri: imageUri,
    name: 'upload.jpg',
    type: 'image/jpeg',
  } as any);

  const response = await fetch('https://your-api.example.com/uploads', {
    method: 'POST',
    body: formData,
    headers: {
      Accept: 'application/json',
    },
  });

  if (!response.ok) {
    throw new Error('Upload failed');
  }

  return response.json();
}

Yang code sudah cukup untuk membuktikan jalur tersebut berfungsi, tetapi aplikasi produksi biasanya membutuhkan lapisan tambahan. Derive name dan type dari asset yang dipilih ketika memungkinkan, tambahkan autentikasi di luar fungsi pemilih, dan jaga keadaan unggah tetap terpisah dari keadaan pemilih sehingga permintaan gagal tidak memaksa pengguna untuk membuka kembali perpustakaan.

Beberapa periksaan mencegah gagal umum yang saya lihat di tinjauan:

• Konfirmasi lokal uri ada sebelum membangun permintaan
• Tampilkan pratinjau sebelum upload agar pengguna dapat mengetahui file yang salah sejak awal
• Mencegah sentuhan berulang saat permintaan sedang dalam penerbangan
• Menangani kegagalan jaringan secara terpisah dari pembatalan picker atau kesalahan izin
• Diperkirakan validasi backend akan menolak file besar, jenis MIME yang tidak didukung, atau autentikasi yang hilang

Jika backend Anda memerlukan base64 daripada multipart, itu biasanya adalah keterbatasan server, bukan kebutuhan picker. Multipart lebih murah dalam hal memori dan lebih mudah dipahami pada perangkat mobile.

Dimana perbedaan platform sebenarnya berpengaruh

UI picker adalah native, sehingga mengikuti perilaku native. Hal itu mempengaruhi baik apa yang dilihat pengguna maupun apa yang harus dianggap oleh code Anda.

Pada iOS, aliran penyuntingan dan prompt izin mengikuti konvensi Apple. Akses Photos yang terbatas dapat mengembalikan set aset yang lebih sempit daripada akun uji yang diberikan pada perangkat yang sepenuhnya diberikan. Pada Android, perilaku picker lebih bervariasi tergantung pada versi OS dan kulit pabrikan, terutama seputar album, nama file, dan bagaimana tangkapan kamera dikembalikan. Aplikasi React Native yang tidak dielenggarkan merasakan perbedaan ini lebih langsung karena Anda lebih banyak mengelola setup native, tetapi aplikasi Expo yang dielenggarkan masih membutuhkan code yang menganggap picker sebagai bentuk platform daripada uniform.

Aturan praktisnya sederhana. Tergantung pada bidang yang dapat divalidasi, bukan pada UI yang identik atau metadata yang identik di antara perangkat.

Beberapa contoh yang penting dalam aplikasi nyata:

• Penyuntingan dan pengguntingan: UI dan perilaku potongannya tidak identik antara iOS dan Android
• Metadata yang dikembalikan: fileName, mimeTypedan fileSize dapat tidak ada atau tidak konsisten, jadi tambahkan fallbacks
• Izin: Akses foto iOS dapat dibatasi pada item tertentu, sementara perilaku Android lebih bergantung pada versi OS dan dukungan pemilih sistem
• Keluaran kamera: Gambar yang diambil mungkin kembali dengan nama, orientasi, atau karakteristik kompresi yang berbeda dari aset library

Jika tim Anda juga bekerja di luar Expo, ini Petunjuk pengembangan aplikasi DesignStack memberikan konteks Android yang berguna untuk keputusan pengelolaan media yang muncul di luar library tunggal.

Perbedaan antara alur kerja yang diatur dan alur kerja yang sederhana

Pada titik ini, pilihan pengaturan mulai mempengaruhi operasional.

Dalam alur kerja yang diatur, string izin dan konfigurasi plugin biasanya berada di konfigurasi aplikasi, dan perubahan native diterapkan ketika Anda membuat build baru. Hal ini menjaga luas permukaan JavaScript tetap bersih, tetapi juga berarti perbaikan konfigurasi tidak akan terlihat sampai build native berikutnya. Perbarui OTA tidak memperbaiki izin native yang hilang.

Dalam alur kerja yang tidak diatur, fitur yang sama memiliki bagian yang lebih banyak. Anda perlu memverifikasi penggunaan deskripsi iOS native, perilaku manifest Android, instalasi paket, dan waktu rebuild sendiri. Kelebihannya adalah kontrol. Biaya yang dikeluarkan adalah bahwa masalah picker mungkin disebabkan oleh konfigurasi native, bukan oleh situs panggilan JavaScript.

Tim yang berganti antara Expo dan Capacitor sering kali mengabaikan seberapa berbeda lapisan abstraksi ini. Capgo memiliki penjelasan yang berguna tentang bagaimana Capacitor mengatasi perbedaan platform, dan itu adalah titik perbandingan yang baik jika Anda sedang memutuskan seberapa banyak pengaturan native yang ingin Anda miliki.

Pilihan saya konsisten di kedua alur kerja. Jaga picker code tetap sempit, normalisasi hasil sekali, unggah melalui layer API yang khusus, dan anggap perilaku spesifik platform sebagai sesuatu yang perlu dikonfigurasi dan diuji secara eksplisit daripada menyelipkan asumsi.

Mengatasi Masalah Umum

Banyak bug Picker Image Expo jatuh ke dalam kategori yang kecil. Perbaikan cepat biasanya adalah untuk mengidentifikasi lapisan mana yang gagal: konfigurasi, izin, penanganan hasil, atau rendering.

Periksaan cepat untuk gagal umum

Jika pilih gambar tidak terbuka atau izin gagal, periksa terlebih dahulu pengaturan native. Terutama di aplikasi sederhana, deskripsi penggunaan iOS yang hilang seringkali menjadi penyebab utama.

Jika aplikasi mengalami crash setelah pengguna menutup pilih gambar, periksa penanganan hasil. Banyak implementasi masih mengasumsikan URI langsung dan melewatkan periksa. canceled Beberapa konversi cepat membantu:

Error izin tidak diberikan:

• Verifikasi pengaturan aplikasi dan string izin native, lalu bangun ulang. URI gambar:
• undefined Baca dari , bukan result.assets?.[0]?.uriTidak ada yang terjadi setelah batal: result.uri.
• __CAPGO_KEEP_0__ Mungkin itu benar. Tangani cancel sebagai keadaan tanpa aksi.
• Gambar tidak terrender: Konfirmasi bahwa URI disimpan dalam keadaan dan dikirimkan ke <Image source={{ uri }} />.
• Kamera berperilaku aneh di simulator: Jalankan tes pada perangkat fisik sebelum mengejar bug library.

Daftar checklist produksi singkat

Gunakan ini sebagai pemeriksaan akhir sebelum mengirimkan:

• Pasang dengan alat Expo: Pilih npx expo install expo-image-picker.
• Konfigurasi bagian native: Tambahkan plugin dan deskripsi izin yang diperlukan.
• Mulai meminta izin secara sengaja: Mengatur aliran kamera dan media library secara terpisah.
• Mengawasi setiap hasil: Cek result.canceled dan membaca dengan aman assets[0].
• Mengutamakan unggahan berbasis URI: Mengingatkan base64 hanya untuk kasus-kasus khusus.
• Menguji perangkat nyata: Terutama untuk pengambilan gambar dan prompt izin.

Jika tim Anda mengirimkan Capacitor atau aplikasi Electron bersamaan dengan proyek React Native, Capgo adalah salah satu pilihan untuk menyampaikan pembaruan JavaScript, CSS, konfigurasi, dan aset tanpa harus menunggu tinjauan toko untuk setiap perubahan. Ini relevan ketika perbaikan gambar hidup di layer web, seperti UI unggahan, aturan validasi, salinan, atau pengelolaan aset di sekitar aliran picker.