Lompat ke konten utama
Mobile Guida

Pemilih Gambar Expo: Panduan Komprehensif untuk 2026

Belajar pemilih gambar expo di aplikasi React Native Anda. Panduan ini komprehensif mencakup instalasi, izin, akses kamera/galeri, pemotongan, base64, dan unggah.

Martin Donadieu

Martin Donadieu

Pengembang Konten

Pemilih Gambar Expo: Panduan Komprehensif untuk 2026

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

Itu di mana Pemilih 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 dalam input media asli, tetapi tidak pengalaman media yang disesuaikan yang berperilaku identik pada setiap perangkat.

Petunjuk ini ditulis untuk implementasi pertama, bukan demo. Ini berfokus pada keputusan yang berpengaruh dalam produksi: pengaturan setup kerja yang dikelola versus tidak dikelola, pengelolaan izin yang tidak akan mengejutkan Anda nanti, parsing hasil yang aman, dan pola unggah yang praktis setelah pengguna memilih file. Jika Anda bekerja dalam setup native yang disesuaikan, itu juga membantu memahami bagaimana ini berbeda dari workflow klien pengembangan Expo. Daftar Isi.

Mulai Membuat Expo Image Picker

Mulai Berjalan dengan Expo Image Picker

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

expo-image-picker adalah modul Expo SDK untuk itu. Modul ini membuka picker atau UI kamera platform dan mengembalikan media yang dipilih dalam bentuk yang dapat dihandle oleh React Native code. JavaScript API yang kecil. Tantangan utama terletak pada mengatur setup native, aliran izin, dan pengelolaan hasil yang benar pada proyek yang dikelola dan proyek tanpa pengelola.

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

Tangani ini sebagai fitur integrasi native dengan interface React.

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

  • Konfigurasi native: pengaturan plugin yang hilang, string izin yang salah, atau build yang ketinggalan zaman setelah mengubah konfigurasi
  • Siklus waktu eksekusi: pengguna dapat menolak akses, memberikan akses library yang terbatas pada iOS, atau membatalkan aliran tanpa memilih apa-apa
  • Penguraian hasil: modul API yang saat ini mengembalikan assets array, sehingga contoh-contoh yang lebih tua 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 pembangunan ulang ketika konfigurasi tersebut 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 daripada Expo Go, panduan ini cocok dengan Capgo’s penjelasan tentang bagaimana klien pengembangan Expo mengubah pengujian modul native.

Itu perbedaan yang penting karena jalur bahagia hanya setengah 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 tampilan lokal.

Pemasangan dan Konfigurasi Utama

Pemasangan memerlukan satu perintah. Mengatur konfigurasi native yang tepat adalah yang menentukan apakah picker berfungsi di perangkat nyata, di klien pengembangan kustom, dan di build produksi Anda.

expo-image-picker memberikan reaktif API atas pilihan platform untuk foto, video, dan pengambilan gambar. Panggilan JavaScript sederhana. Namun, pengaturan tidak, karena akses foto dan kamera dikendalikan oleh iOS dan Android, bukan oleh React Native.

Seorang pengembang yang bekerja pada implementasi picker gambar Expo dengan mengetik code di layar komputer laptop.

Mulai dengan installer versi-aware Expo:

npx expo install expo-image-picker

Gunakan expo install daripada npm install atau yarn add. Expo mengatur versi paket ke SDK Anda, yang menghindari masalah kompatibilitas native yang umum. Jika Anda sedang membandingkan bagaimana modul Expo masuk ke dalam proses rilis Anda, ini Pendahuluan alat Expo adalah referensi yang berguna.

Pengaturan alur kerja yang diatur

Dalam alur kerja yang diatur, deklarasikan plugin di konfigurasi aplikasi agar Expo dapat menerapkan perubahan native pada saat waktu pembangunan.

Contoh dengan app.json:

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

Itu adalah pengaturan minimum. Dalam prakteknya, tim biasanya menambahkan teks izin juga, terutama di iOS di mana prompt sistem harus menjelaskan mengapa aplikasi membutuhkan akses. Tetapkan kata-kata yang spesifik untuk aksi pengguna. “Mengunggah foto profil” lebih baik daripada “Membutuhkan akses media.”

Satu detail operasional menyebabkan waktu yang banyak terbuang. Mengubah pluginsstring izin, atau konfigurasi native lainnya memerlukan pembangunan ulang. Mengeload JavaScript tidak menerapkan perubahan tersebut. Di Expo Go, Anda juga terbatas oleh apa saja yang sudah termasuk di klien. Dalam pembangunan pengembangan atau produksi, proyek native menunjukkan konfigurasi Anda hanya setelah pembangunan baru.

Pengaturan detail React Native yang tidak berpakaian

Dalam aplikasi yang tidak berpakaian, paket API sama, tetapi Anda perlu memverifikasi lebih banyak proyek native sendiri. Penggunaan deskripsi iOS adalah hal pertama untuk diperiksa. Jika alur Anda dapat membuka library, meluncurkan kamera, atau merekam video dengan suara, aplikasi Anda membutuhkan string izin yang sesuai di Info.plist sebelum Anda membangun ulang.

Daftar cek praktis untuk proyek tanpa bahan seperti ini:

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

Teks izin yang hilang sering terlihat seperti bug runtime karena UI code masih baik dan handler tombol berjalan. Namun, gagalnya terletak lebih rendah di stack. Saya biasanya memeriksa Info.plistkonfigurasi aplikasi, dan apakah build saat ini termasuk perubahan native terbaru sebelum saya mengubah komponen code.

Banyak kebiasaan yang membuat setup lebih prediktif:

  • Tulis teks izin untuk aksi yang sebenarnya: pengguna harus memahami mengapa mereka melihat prompt tersebut.
  • Konfigurasi kamera dan library secara terpisah: Satu dapat berfungsi sementara yang lain masih gagal.
  • Rebuild setelah perubahan native: Pembaruan panas dan refresh cepat tidak memperbarui izin native.
  • Tes di perangkat: Perilaku simulator dapat menyembunyikan masalah izin dan kamera.

Jika picker bekerja selama pengembangan tetapi rusak di TestFlight atau build Play Store, anggap itu sebagai masalah konfigurasi terlebih dahulu. Sebagian besar waktu, itu adalah.

Akses Kamera dan Media Library

Pengguna mengetuk “Upload foto,” mengharapkan kamera atau library terbuka, dan aplikasi Anda memiliki satu pekerjaan 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.

Terdengar sederhana sampai Anda tes baik build yang diatur dan build yang tidak berpakaian di iOS dan Android. JavaScript API tetap kompak, tetapi perilaku waktu eksekusi masih bergantung pada pertanyaan OS, perangkat keras, dan bagaimana Anda mengonfigurasi izin native sebelumnya.

Diagram alir yang menggambarkan proses pilih gambar aplikasi mobile untuk memilih antara sumber kamera atau library media.

Komponen yang minimal tetapi aman

Alur utama yang konsisten dalam proyek kerja sama Expo dan kerja sama bare. Tuntukan izin yang relevan, meluncurkan pemilih, periksa apakah pengguna membatalkan, lalu baca aset 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.

  • Tuntukan 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 aset daripada uri.

Alur library dan kamera

Mulai dengan alur library jika Anda ingin jalur yang paling cepat untuk 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.

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

Polanya UI yang bersih adalah bertanya kepada pengguna tentang 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 kemudian. Misalnya, beberapa tim memungkinkan unggahan library untuk foto profil tetapi memerlukan tangkapan kamera segar untuk verifikasi identitas.

If aplikasi Anda lebih luas juga mendukung pola akses file di luar Expo atau Anda membandingkan konvensi di atas stack native, hal ini Capacitor referensi library foto bermanfaat sebagai konteks.

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

Apakah yang dapat diharapkan dari antarmuka sistem

expo-image-picker membuka pemilih platform atau UI kamera. Aplikasi Anda tidak mengontrol setiap layar dalam alur tersebut. Perbedaan ini penting karena "berfungsi di perangkat saya" sering kali berarti "sistem operasi memungkinkan jalur yang saya uji."

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

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

  • permintaan izin pertama
  • izin ditolak
  • pengguna membatalkan
  • pemilihan library sukses
  • penangkapan kamera yang sukses pada perangkat fisik
  • pratinjau langsung dari URI lokal yang dikembalikan

Kasus-kasus tersebut dapat dipetakan langsung ke perilaku produksi yang sebenarnya. Mereka juga mengatur langkah berikutnya dengan jelas jika Anda perlu mengirimkan file ke server, pipeline moderasi, atau endpoint publikasi seperti Instagram media publishing __CAPGO_KEEP_0__ Instagram media publishing API.

Hasil pemilihan adalah bagian yang biasanya memerlukan logika produksi yang sebenarnya. Antarmuka UI sistem kembali objek yang terstruktur, bukan hanya jalur file, dan kesalahan kecil di sini dapat menyebabkan pratinjau yang rusak, unggahan kosong, atau crash setelah pengguna membatalkan

Membaca objek hasil dengan benar

Bentuk hasil yang berpengaruh dalam aplikasi Expo saat ini adalah

, bukan top-level result.assets[0].uriDetail tersebut mempengaruhi baik proyek kerja alih-manajemen maupun proyek kerja tanpa alih-manajemen karena JavaScript __CAPGO_KEEP_0__ sama meskipun pengaturan native berbeda di bawahnya result.uri. That detail affects both managed and bare workflow projects because the JavaScript API is the same even though native setup differs underneath.

Hal ini menangani dua kasus gagal yang paling sering saya lihat. Pemilihan yang dibatalkan tidak memberikan Anda asset untuk dibaca, dan __CAPGO_KEEP_0__ yang asumsi

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);

Pemilihan yang dibatalkan tidak memberikan Anda asset untuk dibaca, dan code yang asumsi result.assets[0] Akan gagal pada waktu eksekusi jika tidak ada.

Setelah Anda memiliki URI, menampilkan pratinjau sangatlah mudah:

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

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

Pilihan yang mengubah perilaku hilir

Beberapa pilihan picker mempengaruhi lebih dari layar pilihan saja. Mereka membentuk ukuran file, perilaku pengeditan, dan apa yang harus diterima backend Anda.

Pilihan Jenis Apa yang diubah Penggunaan yang umum
mediaTypes array Mengatur apa yang dapat dipilih oleh pengguna Mengatur pilihan hanya ke gambar jika API hanya menerima gambar
allowsEditing boolean Mengizinkan OS menawarkan UI potong atau edit jika didukung Avatar, cover persegi, pengambilan bukti
quality number Mengompres output gambar yang didukung Mengurangi ukuran upload untuk jaringan mobile
base64 boolean Menambahkan data gambar yang dikodekan ke hasil Hanya untuk integrasi yang secara eksplisit memerlukan data gambar inline

Apa yang perlu diingat adalah beberapa kekurangan yang mudah terlewatkan:

  • allowsEditing berguna ketika slot gambar memiliki bentuk atau ukuran tetap. Ini kurang berguna jika server Anda melakukan pipeline potong sendiri dan Anda ingin file asli.
  • quality mempengaruhi waktu unggah, 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 pilihannya kembali.
  • base64 meningkatkan ukuran payload di memori. Hindari hal ini kecuali layanan penerima memerlukan.

Poin terakhir ini sangat penting pada perangkat dengan memori rendah. URI file lokal biasanya lebih baik untuk tampilan awal 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:

  • Pilih URI untuk tampilan awal.
  • Menggunakan URI untuk mengunggah file.
  • Menggunakan base64 hanya ketika sistem penerima secara eksplisit meminta konten yang dienkripsi.

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

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

Hasil pola yang lebih aman untuk aplikasi nyata

Untuk demo code, hanya menyimpan imageUri Cukup baik. Di produksi, simpan objek yang telah dinormalisasi sehingga langkah berikutnya, tampilan, validasi, unggah, atau ulangi, tidak perlu memulai ulang tanggapan picker 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,
});

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

Pengecekan akhir membantu. Jangan mengaktifkan bidang hasil tambahan hanya untuk kasus-kasus tertentu. Mintalah data yang Anda ketahui Anda butuhkan, dan jaga picker tetap fokus pada seleksi daripada mengubahnya menjadi langkah pengolahan file umum.

Polanya Lanjutan dan Perbedaan Platform

Fitur picker biasanya berhenti menjadi sederhana ketika gambar yang dipilih pertama kali harus bertahan dari ulangi, header autentikasi, perbedaan izin native, dan endpoint unggah yang nyata. expo-image-picker mengatasi seleksi dengan baik. Bagian fitur lainnya ada di aplikasi Anda.

Infografis berjudul Pengunggahan Gambar: Pertimbangan Penyimpanan Lokal vs. Server menampilkan kelebihan dan kekurangan penyimpanan server.

Polanya Pengunggahan yang Praktis

Untuk API yang mengharapkan unggahan file, FormData masih merupakan default yang paling aman. Ini berfungsi di backend yang umum seperti Rails, Node, Laravel, Django, dan Go, dan menjaga picker 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();
}

Itu code sudah cukup untuk membuktikan jalur tersebut berfungsi, tetapi aplikasi produksi biasanya membutuhkan lapisan tambahan. Derivasikan name dan dari aset yang dipilih ketika memungkinkan, tambahkan autentikasi di luar fungsi pemilih, dan jaga keadaan unggah terpisah dari keadaan pemilih sehingga permintaan gagal tidak memaksa pengguna untuk membuka kembali perpustakaan. type Beberapa periksaan mencegah gagal umum yang saya lihat dalam tinjauan:

Konfirmasi lokal

  • ada sebelum membangun permintaan uri Tampilkan pratinjau sebelum unggah sehingga pengguna menemukan file yang salah secara dini
  • Mencegah sentuhan berulang sementara permintaan sedang dalam penerbangan
  • Tangani gagal jaringan terpisah dari pembatalan pemilih atau kesalahan izin
  • Diharapkan validasi backend menolak file besar, jenis MIME yang tidak didukung, atau autentikasi yang hilang
  • Jika backend Anda memerlukan base64 bukan multipart, itu biasanya konstrain server, bukan kebutuhan pemilih. Multipart lebih murah dalam memori dan lebih mudah dipahami pada perangkat mobile.

Di mana perbedaan platform sebenarnya berpengaruh

Antarmuka pemilih adalah native, jadi mengikuti perilaku native. Hal itu mempengaruhi baik apa yang dilihat pengguna maupun apa yang harus dianggap __CAPGO_KEEP_0__ Anda.

The picker UI is native, so it inherits native behavior. That affects both what users see and what your code should assume.

On iOS, pengaturan aliran edit dan prompt izin mengikuti konvensi Apple. Akses Foto yang terbatas dapat mengembalikan set aset yang lebih terbatas daripada akun uji Anda melihat pada perangkat yang sepenuhnya diberikan. Pada Android, perilaku picker bervariasi lebih banyak oleh versi OS dan kulit pabrikan, terutama seputar album, nama file, dan bagaimana tangkapan kamera dikembalikan. Aplikasi React Native yang sederhana merasakan perbedaan-perbedian ini lebih langsung karena Anda memiliki lebih banyak pengaturan native, tetapi aplikasi Expo yang dikelola masih memerlukan code yang menganggap picker sebagai bentuk platform daripada uniform yang sempurna.

The rule praktis adalah sederhana. Tergantung pada bidang-bidang yang dapat Anda validasi, bukan pada UI yang identik atau metadata yang identik di antara perangkat.

Beberapa contoh yang penting dalam aplikasi nyata:

  • Pengeditan dan pengguntingan: UI dan perilaku pengguntingan tidak identik antara iOS dan Android
  • Metadata yang dikembalikan: fileName, mimeType, dan fileSize dapat tidak ada atau tidak konsisten, jadi tambahkan fallback
  • Izin: Akses foto iOS dapat terbatas pada item yang dipilih, sementara perilaku Android lebih tergantung pada versi OS dan dukungan picker sistem
  • Tangkapan kamera: Tangkapan gambar yang ditangkap mungkin kembali dengan karakteristik nama, orientasi, atau kompresi yang berbeda daripada asset 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 satu library.

Perbedaan antara alur kerja yang diatur dan alur kerja yang tidak diatur

Pada titik ini, pilihan pengaturan mulai berpengaruh secara operasional.

Dalam alur kerja yang diatur, string izin dan konfigurasi plugin biasanya hidup di konfigurasi aplikasi, dan perubahan native diterapkan ketika Anda membuat build baru. Hal itu menjaga luas permukaan JavaScript tetap bersih, tetapi juga berarti perbaikan konfigurasi tidak 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. Keuntungan adalah kendali. Biaya adalah bahwa masalah picker mungkin disebabkan oleh konfigurasi native, bukan oleh situs panggilan JavaScript.

Tim yang beralih antara Expo dan Capacitor sering kali melawan perkiraan bahwa lapisan abstraksi ini sangat berbeda. Capgo memiliki penjelasan yang berguna tentang bagaimana Capacitor mengelola perbedaan platform, dan itu adalah titik perbandingan yang baik jika Anda sedang memutuskan berapa banyak pengaturan native yang ingin Anda miliki.

Saya lebih suka konsisten di kedua alur kerja. Jaga picker code tetap sempit, normalisasi hasilnya sekali, unggah melalui layer API yang dedikasi, dan tatalah perilaku platform khusus sebagai sesuatu yang perlu dikonfigurasi dan diuji secara eksplisit daripada dihaluskan dengan asumsi.

Mengatasi Masalah yang Umum

Most Bug Expo Picker Image terletak dalam kategori kecil. Solusi tercepat biasanya adalah mengidentifikasi layer mana yang gagal: konfigurasi, izin, penanganan hasil, atau rendering.

Daftar Periksa untuk Mengatasi Masalah Umum Ketika Menggunakan Library expo-image-picker dalam Proyek Pengembangan Mobile.

Cek Cepat untuk Kegagalan Umum

Jika Picker Tidak Buka atau Izin Gagal, Cek Pengaturan Nativ Terlebih Dahulu. Terutama di Aplikasi Bare, Deskripsi Penggunaan iOS yang Hilang adalah Penyebab Umum.

Jika Aplikasi Mengalami Crash Setelah Pengguna Menutup Picker, Periksa Penanganan Hasil Anda. Banyak Implementasi Masih Mengasumsikan URI Langsung dan Melupakan canceled Cek.

Beberapa Mappin Cepat membantu:

  • Error Izin Ditolak: Verifikasi Konfigurasi Aplikasi dan String Izin Nativ, Kemudian Rebuild.
  • undefined URI Gambar: Baca dari result.assets?.[0]?.uri, bukan result.uri.
  • Tidak ada yang terjadi setelah cancel: Mungkin itu benar. Tindakan cancel dianggap sebagai keadaan tidak beroperasi.
  • Gambar tidak terrender: Pastikan URI disimpan dalam keadaan dan dipasang ke <Image source={{ uri }} />.
  • Kamera berperilaku aneh di simulator: Test di perangkat fisik sebelum mencari bug di library.

Daftar checklist produksi singkat

Gunakan sebagai pemeriksaan akhir sebelum mengirimkan:

  • Pasang dengan alat Expo: Gunakan npx expo install expo-image-picker.
  • Konfigurasi bagian native: Tambahkan plugin dan deskripsi izin yang diperlukan.
  • Minta izin secara sengaja: Alirkan aliran kamera dan media library secara terpisah.
  • Lindungi setiap hasil: Periksa result.canceled dan baca dengan aman assets[0].
  • Lebih baik unggah berdasarkan URI: Tetapkan base64 hanya untuk kasus-kasus khusus.
  • Uji perangkat nyata: Terutama untuk pengambilan kamera 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 unggah, aturan validasi, salinan, atau pengelolaan aset di sekitar aliran picker.

Perbarui langsung untuk aplikasi Capacitor

Jika bug layer web masih aktif, kirimkan perbaikan melalui Capgo bukan menunggu hari-hari untuk persetujuan toko aplikasi. Pengguna mendapatkan update di latar belakang sementara perubahan native tetap dalam jalur review normal.

Mulai Sekarang

Terbaru dari Blog Kami

Capgo memberikan Anda wawasan terbaik yang Anda butuhkan untuk membuat aplikasi mobile profesional yang sebenarnya.