당신은 UI가 준비되었고 프로필 화면에 '사진 업로드' 버튼이 있고 이제 쉽게 보일 것 같았지만 실제로 이미지 선택 흐름은 네이티브 권한, OS가 제어하는 인터페이스, 개발자들이 기대하는 것과 다른 반환 형태, 그리고 빌드 타임에 나타나는 몇 가지 세부 사항을 다룹니다.
Expo 이미지 픽커는 Expo 패키지 저장소에 설명된 것과 같이 장치 라이브러리에서 이미지를 선택하거나 카메라로 사진을 찍어 선택할 수 있는 시스템 UI를 열기 위한 공식 Expo 라이브러리입니다. Expo 패키지 저장소. Expo Image Picker는 실제로 native 미디어 입력에 대한 신뢰할 수 있는 브릿지를 제공하지만, 모든 장치에서 동일하게 동작하는 커스텀 미디어 경험을 제공하지는 않습니다.
이 안내서는 첫 번째 구현에 대한 것입니다, demo가 아닌 것입니다. 프로덕션에서 중요하다고 여겨지는 결정에 초점을 맞추고 있습니다: 관리되는 워크플로우 설정, 나중에 놀라지 않도록 허용되는 권한 처리, 안전한 결과 파싱, 사용자가 파일을 선택한 후 업로드 패턴입니다. 사용자가 커스텀 네이티브 설정에서 작업하고 있다면, 이와 Expo 개발 클라이언트 워크플로우가 어떻게 다른지 이해하는 것도 도움이 됩니다. Expo 개발 클라이언트 워크플로우.
Expo 이미지 픽커를 사용하는 방법
익스포 시작하기
프로필 사진을 요청하는 제품 매니저가 있습니다. 한 주 후에, 같은 기능이 또한 수표 업로드, 사건 보고서에 카메라 캡처, 사용자가 처음으로 권한을 거부할 때 다시 시도할 필요가 있습니다. 이미지 입력은 빠르게 확장되는데, 이는 네이티브 권한, OS 소유의 UI, 임시 파일 처리, 백엔드 업로드 흐름과 관련이 있습니다.
expo-image-picker 익스포 SDK 모듈은 그 일을 처리하는 익스포 모듈입니다. 플랫폼 픽커 또는 카메라 UI를 열고 선택한 미디어를 React Native code가 처리할 수 있는 형식으로 반환합니다. 자바스크립트 API는 작습니다. 주된 난관은 관리형 및 bare 프로젝트에서 네이티브 설정, 권한 흐름, 결과 처리를 올바르게 하기 때문입니다.
주된 트레이드 오프는 간단합니다. iOS와 Android가 자신의 미디어 UI를 표시하도록 허용합니다. 그 대신에 사용자 정의 픽커를 구축하는 대신, 일반적인 시스템 화면을 사용자들이 이미 이해하고 있으며, 권한 프롬프트가 OS가 기대하는 대로 동작하고, 팀이 자바스크립트에서 갤러리 구현을 유지 관리할 필요가 없습니다.
이러한 기능을 네이티브 통합 기능으로 다루세요. React 인터페이스를 사용하세요.
이 마음가짐이 도움이 됩니다. 실패 모드는 일반적으로 픽커를 호출하는 버튼에서 오지 않습니다. 일반적으로 다음 세 가지 곳에서 오는 것입니다:
- 네이티브 구성: 플러그인 설정이 누락되거나, 권한 문자열이 잘못되거나, 구성이 변경된 후에 빌드가 오래되었습니다.
- 런타임 동작: 사용자가 접근을 거부하거나, iOS에서 라이브러리 접근을 제한하거나, 선택을 하지 않고 흐름을 취소할 수 있습니다.
- 결과 처리: 현재 API는
assets배열이기 때문에 더 오래된 예제가 직접적으로result.uri실행되지 않습니다.
워크플로우 선택도 설정 경로를 변경합니다. 관리형 Expo 앱에서 대부분의 네이티브 작업은 앱 구성에서 수행되며 구성이 변경될 때 다시 빌드해야 합니다. Bare 앱에서 여전히 Expo 모듈 API을 얻을 수 있지만 iOS 및 Android 프로젝트 설정을 직접 확인해야 합니다. 팀이 Expo Go 대신 사용하는 커스텀 클라이언트를 사용하는 경우 이 안내서는 Capgo의 네이티브 모듈 테스트에 대한 Expo 개발 클라이언트가 네이티브 모듈 테스트를 어떻게 변경하는지 설명하는 것과 잘 어울립니다. 이 분할은 이 안내서의 나머지 부분에서 중요합니다. 픽커 구현은 happy path만 고려하는 것이 아니라, 플랫폼별 권한 구둣점을 처리하는 것과 사용자가 놀라지 않도록 하며, 업로드 층에 사용할 수 있는 파일을 전달하는 것에 성공할 때 solid합니다..
설치 및 필수 구성
설치는 하나의 명령어로 완료됩니다. 네이티브 구성이 올바르게 설정되는 것이 픽커가 실제 장치에서, 커스텀 개발 클라이언트에서, 그리고 프로덕션 빌드에서 작동하는지 결정합니다.
Expo 이미지 픽커는 React에 대한 __CAPGO_KEEP_0__를 제공합니다. 플랫폼 픽커에 대한 React-facing API입니다. JavaScript 호출은 간단합니다. 그러나 사진 접근 및 카메라 접근은 iOS 및 Android에 의해 제어되므로 React Native에 의해 제어되지 않습니다.
expo-image-picker Expo 이미지 픽커 구현을 개발하는 개발자가 노트북 컴퓨터 화면에 API을 입력하는 중입니다.
대신
npx expo install expo-image-picker사용 expo install __CAPGO_KEEP_0__ npm install 또는 yarn addExpo는 패키지 버전을 SDK와 일치시켜서 일반적인 네이티브 호환성 문제를 피할 수 있습니다. Expo 모듈이 릴리스 프로세스에 어떻게 들어가는지 비교하는 경우, 이 Expo 도구 개요 관리 워크플로 설정
관리 워크플로에서 플러그인을 앱 구성 파일에 선언하여 Expo가 빌드 시간에 네이티브 변경을 적용할 수 있도록 합니다.
예시와 함께
이것은 최소한의 설정입니다. 실제로는 iOS에서 시스템 프롬프트가 앱이 접근 권한이 필요한 이유를 설명해야 하므로, 팀은 권한 텍스트를 추가하는 경우가 많습니다. 사용자 액션에 맞춰서 텍스트를 작성하는 것이 좋습니다. "프로필 사진을 업로드하세요"보다는 "미디어 접근 권한이 필요합니다" app.json:
{
"expo": {
"plugins": ["expo-image-picker"]
}
}운영상의 한 가지 세부 사항이 많은 시간을浪費합니다. 네이티브 설정, 권한 문자열, 또는 다른 네이티브 구성이 변경되면 다시 빌드해야 합니다. JavaScript를 다시 로드하면 변경 사항이 적용되지 않습니다. Expo Go에서는 클라이언트가 이미 포함하고 있는 것에 제한됩니다. 개발 빌드 또는 프로덕션 빌드에서는 네이티브 프로젝트가 구성에 따라 반영됩니다.
bare React Native 설정 세부 사항 pluginsbare 앱에서 패키지 __CAPGO_KEEP_0__은 동일하지만, 네이티브 프로젝트를 더 많이 확인해야 합니다. iOS 사용 설명서를 확인해야 합니다. 라이브러리를 열 수 있는 흐름, 카메라를 열 수 있는 흐름, 오디오와 함께 비디오를 녹음할 수 있는 흐름이 있는 경우, 앱은 해당 권한 문자열이 포함된
Appflow 비교/이동 마케팅 복사본
In a bare app, the package API is the same, but you need to verify more of the native project yourself. iOS usage descriptions are the first thing to check. If your flow can open the library, launch the camera, or record video with audio, your app needs the corresponding permission strings in Info.plist 설치하기 전에 다시 빌드하세요.
bare 프로젝트에 대한 실용적인 체크리스트는 다음과 같습니다.
- 설치
expo-image-picker와npx expo install expo-image-picker. - Expo config 플러그인 사용 프로젝트의 경우 플러그인 구성 추가하세요.
- iOS 사용 설명이 노출하는 기능과 일치하는지 확인하세요.
- iOS 및 Android 앱을 다시 빌드하세요. native config 변경 후.
권한이 없는 텍스트가 종종 런타임 오류처럼 보인다. UI code은 정상이고 버튼 핸들러가 실행되지만 실패는 스택의 아래쪽입니다. 일반적으로 code 컴포넌트를 건드리지 전에 Info.plist, the app config, and whether the current build includes the latest native changes before I touch the component code.
설정을 더 예측 가능하게 하기 위한 몇 가지 습관이 있습니다:
- 권한이 없는 텍스트를 실제 액션에 대해 작성하세요: 사용자는 왜 이 경고를 보는지 이해해야 합니다.
- 카메라와 라이브러리를 별도로 설정하세요: 한쪽이 작동하는 동안 다른 쪽이 실패하는 경우가 있습니다.
- 자연스러운 변경 후 다시 빌드하세요: 핫 리로드 및 빠른 리프레시가 네이티브 권한을 업데이트하지 않습니다.
- 장치에서 테스트하세요: 시뮬레이터의 동작은 권한 및 카메라 문제를 숨길 수 있습니다.
개발 중에 픽커가 작동하지만 테스트 플라이트 또는 플레이 스토어 빌드에서 깨지면, 그 경우를 최초로 구성 문제로 간주하세요. 대부분의 경우, 그럴 것입니다.
카메라 및 미디어 라이브러리 접근
사용자가 “사진 업로드”를 탭하면 카메라 또는 라이브러리가 열리고, 그 순간 앱의 일은 하나입니다. 올바른 시스템 UI를 열어주고 거부 또는 취소 시 화면을 깨지지 않도록 처리하고, 미리보기 또는 업로드를 위해 사용할 수 있는 로컬 파일 참조를 반환해야 합니다.
그것은 간단해 보이지만, 관리형 및 bare 빌드 모두 iOS 및 Android에서 테스트할 때까지 간단하지 않습니다. 자바스크립트 API은 compact하지만, 런타임 동작은 OS 프롬프트, 장치 하드웨어 및 네이티브 권한을 이전에 구성한대로 여전히 의존합니다.
안전하지만 최소한의 컴포넌트
Expo 관리 및 bare workflow 프로젝트 모두에서 core 흐름이 일관적입니다. 관련된 권한을 요청하고 픽커를 시작한 후 사용자가 취소했는지 확인하고 첫 번째 자산을 읽습니다. result.assets.
기본적인 컴포넌트는 다음과 같습니다:
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>
);
}세 가지 세부 사항이 여기서 중요합니다.
- 라이브러리 및 카메라 권한을 별도로 요청하십시오. 그들은 독립적으로 실패합니다.
- 취소는 일반 사용자 동작으로 다루어져야 합니다. 오류 상태로 다루지 마십시오.
- 에서 읽습니다.
assets[0], 왜냐하면 픽커는 자산 배열을 반환하기보다는 최상위uri.
라이브러리 및 카메라 흐름
라이브러리 흐름으로 시작하면 가장 빠른 기능 개발 경로를 선택할 수 있습니다. 테스트가 더 쉽고, 시뮬레이터 환경에서 더 잘 작동하며, 카메라 하드웨어의 경계 문제를 피할 수 있습니다. 카메라 지원을 추가하면 결과 처리 경로가 안정화된 후에 진행하십시오.
개발 시 카메라 경로에는 더 많은 실패 방법이 있습니다. iOS 시뮬레이터 지원이 제한적이고, Android 에뮬레이터는 실제 장치와 같은 카메라 동작을 노출하지 않을 수 있습니다. bare 프로젝트에서는 실제 문제는 네이티브 구성 또는 테스트 환경일 수 있지만, 컴포넌트 code를 확인하게 됩니다.
정확한 UI 패턴은 사용자에게 원천을 요청한 후 픽커 API를 호출하는 것입니다:
const showPickerOptions = () => {
Alert.alert('Upload image', 'Choose a source', [
{ text: 'Camera', onPress: takePhoto },
{ text: 'Photo Library', onPress: pickFromLibrary },
{ text: 'Cancel', style: 'cancel' },
]);
};이 분리로 각 함수가 집중적이게 되고, 나중에 분석, 기능 플래그, 또는 백엔드 특정 규칙을 추가할 때도 더 쉽게 할 수 있습니다. 예를 들어, 프로필 이미지 업로드는 라이브러리 업로드를 허용하지만, 신분 확인을 위한 새로운 카메라 캡처를 요구하는 팀이 있습니다.
애플리케이션에서 파일 접근 패턴을 지원하는 범위가 더 넓다면 또는 네이티브 스택의 규칙을 비교하고자 한다면 Capacitor 사진 앨범 참조 팀원이나 QA에게 이 흐름을 보여주고 있을 때 짧은 데모가 도움이 됩니다:
시스템 UI에서 무엇을 기대해야 하는지
iOS에서 사용자는 제한된 앨범 접근 권한을 부여할 수 있고, Android에서는 OS 버전과 OEM 스킨에 따라 픽커 동작이 달라질 수 있습니다. 관리 워크플로 프로젝트에서는 Expo가 더 많은 네이티브 연결을 처리합니다. 바레 워크플로 프로젝트에서는 빌드된 앱이 네이티브 권한 변경을 포함하는지 확인해야 합니다. JavaScript 호출 사이트는 두 경우 모두 동일할 수 있지만 런타임 결과는 달라질 수 있습니다.
expo-image-picker 이러한 케이스를 테스트하기 전에 기능이 완료되었다고 호출하지 않습니다:
첫 번째 권한 요청
거부된 권한
- 사용자 취소
- 앨범 선택 성공
- 이 기능을 테스트하기 전에 항상 이러한 케이스를 테스트합니다:
- 첫 번째 권한 요청
- 물리적 장치에서 성공적인 카메라 캡처
- 반환된 로컬 URI의 즉각적인 미리보기
이러한 경우는 실제 운영 환경에서의 동작과 일대일로 매핑됩니다. 또한 파일을 서버, 중재 pipe line, 또는 게시 엔드 포인트(예: Instagram media publishing __CAPGO_KEEP_0__)로 보내야 할 때 다음 단계를 깨끗하게 설정합니다. Instagram media publishing API.
픽커 결과 및 옵션 처리
픽커 결과는 일반적으로 실제 운영 로직이 필요합니다. 시스템 UI는 구조화된 객체를 반환하며, 작은 실수는 깨진 미리보기, 빈 업로드, 또는 사용자가 취소한 후 충돌로 이어집니다.
결과 객체를 올바르게 읽는 방법
현재 Expo 앱에서 중요하는 결과 형태는 result.assets[0].uri, top-level result.uri가 아닌 . 이 세부 사항은 관리형 및 바레 워크플로 프로젝트 모두에 영향을 미치며, 자바스크립트 API는 native setup이 다르지만 동일합니다.
guard-first 패턴을 사용하십시오:
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);이 패턴은 가장 자주 발생하는 두 가지 실패 사례를 처리합니다. 취소된 픽커는 asset를 읽을 수 없으며 code가 가정하는 경우 result.assets[0] 항상 존재할 경우 런타임에서 실패합니다.
URI를 얻은 후에 미리보기 렌더링은 다음과 같습니다:
<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />업로드를 나중에 계획한다면 URI만 가지고 있지 말고 객체 전체를 유지하세요. 실제로 asset , fileName, mimeType, width, height은 유효성 검사, 로깅, 또는 더 깨끗한 멀티파트 요청을 빌드하는 데 유용합니다. fileSize 다운스트림 동작을 변경하는 옵션
선택 화면 이외에도 파일 크기, 편집 동작 및 백엔드가 수락해야 하는 것에 영향을 미치는 몇 가지 픽커 옵션이 있습니다.
옵션
| 타입 | 변경하는 것 | 일반적인 사용 | Typical use |
|---|---|---|---|
mediaTypes |
배열 | 사용자가 선택할 수 있는 것을 제한합니다 | 이미지만 선택할 수 있도록 제한합니다. API이 이미지만 허용한다면 |
allowsEditing |
부울 | OS에서 지원하는 경우 편집 또는 자르기 UI를 제공합니다 | 어바웃, 정사각형 커버, 수표 캡처 |
quality |
숫자 | 지원하는 이미지를 압축합니다 | 모바일 네트워크에서 업로드 크기를 줄입니다 |
base64 |
부울 | 결과에 인코딩된 이미지 데이터를 추가합니다 | 내부 이미지 데이터가 명시적으로 필요하다고 명시한 통합만 해당합니다 |
몇 가지 트레이드 오프는 쉽게 놓치게 됩니다:
allowsEditing이미지 슬롯이 고정된 모양 또는 크기를 가지고 있을 때 유용합니다. 서버가 자신의 크롭 PIPELINE을 처리하고 원본 파일을 원한다면 유용하지 않습니다.quality업로드 시간, 메모리 압박 및 서버 저장소에 영향을 미칩니다.quality: 1자동으로 올바른 선택이 아닙니다.mediaTypes백엔드 규칙과 일치해야 합니다. 서버가 비디오를 거부한다면 픽커가 그들을 반환하지 않도록 하세요.base64메모리 내의 패이로드 크기를 증가시킵니다. 수신 서비스가 이를 요구하지 않는 한 피해야 합니다.
마지막 점은 낮은 메모리 장치에서 중요합니다. 로컬 파일 URI는 일반적으로 미리보기 및 멀티파트 업로드를위한 더 나은 전달 방법입니다. Base64은 유효한 사용을 하지만 파일 참조를 전달하는 것과 비용이 더 높습니다.
URI versus base64
대부분의 앱의 규칙은 간단합니다:
- 사용 URI 미리보기
- 사용 URI 파일 업로드를 위해
- 사용 base64 받는 시스템이 인코딩된 콘텐츠를 명시적으로 요청할 때만 사용합니다.
이 패턴은 픽커 code를 작고 테스트하기 쉬운 크기로 유지하고, 많은 백엔드 미디어 흐름과 일치합니다. 이에는 외부 플랫폼으로 게시할 서비스도 포함됩니다. 인스타그램 미디어 게시 API.
팀이 자주 OTA 업데이트를 배포하거나 이미지-heavy 자산을 앱 배포를 통해 이동하는 경우, 여기서 파일 크기 결정은 PIPELINE의 나머지 부분으로 영향을 미칩니다. 이 PICKER 구성에 대한 유용한 동반자 인 앱 업데이트를 위한 이미지 최적화에 대한 이 안내서 실제 앱에 대한 더 안전한 결과 패턴
A safer result pattern for real apps
데모 code 에서만 imageUri 생산 환경에서는 다음 단계인 미리보기, 유효성 검사, 업로드 또는 다시 시도 시 raw picker 응답을 재해석할 필요가 없도록 normalized 객체를 저장하는 것이 좋습니다.
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,
});이것은 앱 내부에서 하나의 예측 가능한 형태를 제공하고, 또한 관리형 및 베어 프로젝트를 동기화하기가 더 쉬워집니다. 왜냐하면 앱 code이 안정적이기 때문입니다.
마지막으로 한 번 확인해 보세요. 추가 결과 필드를 그냥 활성화하지 마세요. 필요한 데이터만 요청하고, 픽커를 선택에 집중시켜서 일반 파일 처리 단계로 변하지 않도록 하세요.
고급 패턴 및 플랫폼 차이점
픽커 기능이 선택된 이미지가 재시도, 인증 헤더, 네이티브 권한 차이점, 그리고 실제 업로드 엔드포인트와 같은 요소로 복잡해지면 더 이상 단순하지 않습니다. expo-image-picker 선택을 잘 처리합니다. 나머지 기능은 앱에 달려 있습니다.
실용적인 업로드 패턴
API가 파일 업로드를 기대하는 경우 FormData 는 여전히 가장 안전한 기본값입니다. Rails, Node, Laravel, Django, Go 백엔드와 같은 일반적인 백엔드에서 작동하고, 픽커를 수송 관련 사항과 분리합니다.
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();
}그것은 code이 작동하는 경로를 증명하는 데 충분하지만, 실제 앱은 일반적으로 하나의 추가层가 필요합니다. 그것을 파생 name 그리고 type 선택한 자산에서 가능할 때, 인증을 픽커 함수 외부에 첨부하고 업로드 상태를 픽커 상태와 분리하여 사용자가 실패한 요청으로 인해 라이브러리를 다시 열도록 강요하지 않도록 합니다.
리뷰에서 흔히 발생하는 오류를 방지하기 위해 몇 가지 확인을 수행합니다.
- Confirm the local
urilocal이 존재하는지 확인하기 전에 요청을 빌드합니다. - 업로드하기 전에 미리보기 렌더링하도록 하여 사용자가 잘못된 파일을 일찍 발견할 수 있도록 합니다.
- 요청이 진행 중일 때 반복적인 탭을 방지합니다.
- 네트워크 오류와 픽커 취소 또는 권한 오류를 분리하여 처리합니다.
- 서버가 큰 파일, 지원되지 않는 MIME 타입, 또는 인증이 누락된 경우를 거부하는 백엔드 검증을 기대합니다.
서버가 base64 대신 multipart를 요구하는 경우, 일반적으로 서버 제약이 아닌 픽커 요구사항입니다. multipart는 메모리 비용이 저렴하고 모바일에서 더 쉽게 이해할 수 있습니다.
플랫폼 차이점이 실제로 중요합니다.
픽커 UI는 네이티브이므로 네이티브 동작을 상속받습니다. 사용자에게 보이는 것과 code가 가정해야 하는 것은 모두 영향을 받습니다.
On iOS, editing flows and permission prompts follow Apple’s conventions. Limited Photos access can return a narrower set of assets than your test account saw on a fully granted device. On Android, picker behavior varies more by OS version and manufacturer skin, especially around albums, file names, and how camera captures are returned. Bare React Native apps feel these differences more directly because you own more of the native setup, but managed Expo apps still need code that treats the picker as platform-shaped rather than perfectly uniform.
실제 앱에서 중요한 몇 가지 예시만 있으면 됩니다.
편집 및 크롭:
- iOS와 Android 사이의 UI 및 크롭 동작이 동일하지 않습니다. 반환된 메타데이터:
- ,
fileName,mimeType없거나 불일치할 수 있으므로 대체 값을 추가하세요.fileSize권한: - iOS의 사진 접근 권한은 선택한 항목만 제한할 수 있지만 Android의 동작은 OS 버전과 시스템 픽커 지원에 따라 달라집니다. 카메라 출력:
- 촬영된 이미지는 라이브러리 항목과 달리 이름, 방향, 압축 특성 등이 다를 수 있습니다. 실제 앱에서 중요한 몇 가지 예시만 있으면 됩니다.
Expo에서 작업하는 팀과 함께 작업하는 경우에도 디자인 스택 앱 개발 가이드 이것은 미디어 처리 결정을 보여주는 단일 라이브러리의 바깥쪽에서 나타나는 안드로이드 컨텍스트를 제공합니다.
관리형 워크플로우와 바레 워크플로우의 차이점
이 시점에서 설정 선택이 운영 방식에 영향을 미칩니다.
관리형 워크플로우에서, 권한 문자열과 플러그인 구성은 일반적으로 앱 구성에서 살펴보며, 새로운 빌드를 만들 때 네이티브 변경이 적용됩니다. 이로 인해 자바스크립트 표면 영역이 깨끗해지지만, 구성 수정은 다음 네이티브 빌드까지 보이지 않습니다. OTA 업데이트도 미스인 네이티브 권한을 패치하지 않습니다.
바레 워크플로우에서, 동일한 기능은 더 많은 움직임이 있습니다. 네이티브 iOS 사용 설명서, 안드로이드 매니페스트 동작, 패키지 설치, 빌드 타이밍을 확인해야 합니다. 이로 인해 제어권이 있습니다. 그러나 픽커 문제는 네이티브 구성이 아닌 자바스크립트 호출 사이트 때문일 수 있습니다.
Teams that switch between Expo and Capacitor often underestimate how different these abstraction layers are. Capgo has a useful explanation of 나는 두 워크플로우 모두에서 동일한 선호도를 가지고 있습니다. 픽커를 Capacitor로 좁게 유지하고, 결과를 한 번만 정규화하고, __CAPGO_KEEP_1__ layer를 통해 업로드하고, 플랫폼 특정 동작을 구성하고 테스트하는 것이 아니라 가정으로 부드럽게 처리하는 대신 명시적으로 구성하고 테스트하는 것이 좋습니다.일반적인 문제 해결
My preference is consistent across both workflows. Keep picker code narrow, normalize the result once, upload through a dedicated API layer, and treat platform-specific behavior as something to configure and test explicitly rather than smooth over with assumptions.
__CAPGO_KEEP_1__는 __CAPGO_KEEP_0__를 통해 업로드하는 데 사용하는 전용 layer입니다.
Expo 이미지 픽커 버그 대부분이 작은 그룹으로 분류됩니다. 가장 빠른 해결책은 일반적으로 실패하는 레이어를 식별하는 것입니다: config, 권한, 결과 처리, 또는 렌더링.
일반적인 실패에 대한 빠른 확인
픽커가 열리지 않거나 권한이 실패하면 네이티브 설정을 먼저 확인하십시오. 특히 bare 앱에서 iOS 사용 설명서가 누락된 경우가 일반적입니다.
사용자가 픽커를 닫은 후 앱이 충돌하는 경우 결과 처리를 검사하십시오. 많은 구현은 여전히 직접 URI를 가정하고 skip check를 생략하고 있습니다. canceled 몇 가지 빠른 매핑이 도움이 될 것입니다:
권한이 거부된 오류:
- 앱 구성과 네이티브 권한 문자열을 확인하고 다시 빌드하십시오. 이미지 URI:
undefined읽기 , 아니라result.assets?.[0]?.uri, notresult.uri.- 취소 버튼을 누르면 아무 일도 일어나지 않는다: 그것이 맞을 수도 있습니다. 취소 버튼을 클릭하면 아무 일도 일어나지 않도록 처리하세요.
- 이미지가 렌더링되지 않는다: URI가 저장되었는지 확인하고 state에 전달되었는지 확인하세요.
<Image source={{ uri }} />. - 카메라가 시뮬레이터에서 이상하게 작동한다: 라이브러리 버그를 추적하기 전에 실제 장치에서 테스트하세요.
단축된 프로덕션 체크리스트
shipping하기 전에 마지막으로 확인하세요:
- Expo 툴링을 사용하여 설치: 사용:
npx expo install expo-image-picker. - 자연적인 부분을 구성: 플러그인과 필요한 권한 설명을 추가하세요.
- 권한을 의도적으로 요청하십시오: 카메라와 미디어 라이브러리 흐름을 분리하십시오.
- 모든 결과를 보호하십시오: 확인
result.canceled안전하게 읽으십시오assets[0]. - URI 기반 업로드를 선호하십시오: base64을 특별한 경우에만 유지하십시오.
- 실제 장치를 테스트하십시오: 카메라 캡처 및 권한 프롬프트와 관련하여 특히 중요합니다.
If your team ships Capacitor or Electron apps alongside React Native projects, Capgo JavaScript, CSS, 설정, 및 자산 업데이트를 저장소 검토 없이 모든 변경에 대기하지 않고 배포하는 옵션입니다. 이미지 관련 수정이 웹层에 존재할 때, 업로드 UI, 유효성 검사 규칙, 복사본, 또는 픽커 흐름과 관련된 자산 처리와 관련하여 관련성이 있습니다.
