당신은 UI가 준비되었고 프로필 화면에 '사진 업로드' 버튼이 있고 이제 쉽게 보일 것 같았지만 실제로 이미지 선택 흐름은 native 권한, OS가 제어하는 인터페이스, 개발자들이 기대하는 것과 다른 반환 형태, 그리고 실제로 빌드할 때만 나타나는 빌드 타임 디테일과 같은 어려움을 겪고 있을 것입니다.
Expo 이미지 픽커는 Expo 패키지 저장소에 설명된 것과 같이 장치 라이브러리에서 이미지를/비디오를 선택하거나 카메라로 사진을 찍는 시스템 UI를 열기 위한 공식 Expo 라이브러리입니다. Expo 패키지 저장소. Expo에서 native 미디어 입력에 대한 신뢰할 수 있는 브릿지를 얻지만, 모든 장치에서 동일하게 동작하는 커스텀 미디어 경험을 얻지는 못합니다.
이 안내서는 첫 번째 구현에 대한 것입니다. 데모가 아닌 첫 번째 구현에 대한 것입니다. 프로덕션에서 중요하다고 여겨지는 결정에 초점을 맞추고 있습니다: 관리되는 워크플로우 설정, 나중에 놀랄 수 있는 권한 처리, 안전한 결과 분석, 사용자가 파일을 선택한 후 업로드 패턴을 포함합니다. 사용자가 커스텀 네이티브 설정에서 작업 중이라면, 이와 Expo 개발 클라이언트 워크플로우가 어떻게 다를지 이해하는 것도 도움이 됩니다. Expo 개발 클라이언트 워크플로우.
Expo 이미지 픽커를 사용하는 방법
엑스포 이미지 픽커를 시작하는 방법
프로필 사진을 요청하는 제품 매니저가 있습니다. 한 주 후에, 같은 기능이 또한 수표 업로드, 사건 보고서에 카메라 캡처, 사용자가 처음으로 권한을 거부할 때 다시 시도할 수 있도록 합니다. 이미지 입력은 빠르게 확장되는데, 이는 네이티브 권한, OS 소유의 UI, 임시 파일 처리, 백엔드 업로드 흐름과 관련이 있습니다.
expo-image-picker 은 엑스포 SDK 모듈입니다. 플랫폼 픽커 또는 카메라 UI를 열고 선택한 미디어를 React Native code가 처리할 수 있는 형태로 반환합니다. 자바스크립트 API는 작습니다. 주요 문제는 관리형 및 바레 프로젝트에서 네이티브 설정, 권한 흐름, 결과 처리를 올바르게 하기 때문입니다.
주요 트레이드 오프는 간단합니다. iOS와 Android가 자신의 미디어 UI를 표시하도록 허용합니다. 일반적으로 사용자에게 더 좋은 결과를 제공합니다: 사용자는 시스템 화면을 이미 이해하고 있습니다. 권한 프롬프트는 OS가 기대하는 방식으로 작동하고, 팀은 자바스크립트 갤러리 구현을 유지 관리할 필요가 없습니다.
이러한 기능을 네이티브 통합 기능으로 간주하고 React 인터페이스를 사용하세요.
이 마음가짐이 도움이 됩니다. 실패 모드는 일반적으로 픽커를 호출하는 버튼에서 발생하지 않습니다. 보통 다음 세 가지 곳에서 발생합니다:
- 네이티브 구성: 플러그인 설정이 누락되거나, 권한 문자열이 잘못되거나, 빌드가 변경된 후에 스테일 빌드가 발생하는 경우
- 런타임 동작: 사용자가 접근을 거부하거나, iOS에서 라이브러리 접근을 제한하거나, 선택을 하지 않고 흐름을 취소하는 경우
- 결과 처리: 현재 API는
assets배열이기 때문에 더 오래된 예제가 직접 실패합니다.result.uri직접 실패합니다.
워크플로 선택도 설정 경로를 변경합니다. 관리형 Expo 앱에서, 대부분의 네이티브 작업은 앱 구성에서 수행되며 구성이 변경되면 다시 빌드해야 합니다. Bare 앱에서 여전히 Expo 모듈 API을 얻지만 iOS 및 Android 프로젝트 설정을 직접 확인해야 합니다. 팀이 Expo Go 대신 사용하는 커스텀 클라이언트가 있다면 이 안내서가 Capgo의 네이티브 모듈 테스트에 대한 Expo 개발 클라이언트가 네이티브 모듈 테스트를 어떻게 변경하는지 설명하는 것과 잘 맞습니다. 이 분기는 가뿐한 경로가 반만의 이야기입니다. 픽커 구현은 두 가지 워크플로에서 작동하고 플랫폼에 특정한 권한 문제를 처리하지 않고 사용자가 놀라지 않도록 하며, 사용할 수 있는 파일을 업로드層에 전달하는 대신 로컬 프리뷰에서 멈추지 않는 경우에만 강력합니다..
설치 및 필수 구성
설치는 하나의 명령어로 진행됩니다. 네이티브 구성이 올바르게 설정되면 픽커가 실제 장치에서, 커스텀 개발 클라이언트에서, 그리고 프로덕션 빌드에서 작동하는지에 따라 결정됩니다.
Expo 이미지 픽커는 React에 대한 __CAPGO_KEEP_0__를 제공합니다. 플랫폼 픽커의 위에 있습니다. 사진, 비디오, 카메라 캡처를 위한 것입니다. 자바스크립트 호출은 간단합니다. 그러나 설정은 그렇지 않습니다. 사진 접근과 카메라 접근은 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 사용 설명서는 첫 번째 항목입니다. 라이브러리를 열 수 있는 흐름, 카메라를 열 수 있는 흐름, 오디오와 함께 비디오 녹음을 할 수 있는 흐름이 있는 경우, 앱에 해당 권한 문자열이 필요합니다.
Expo tooling overview
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 프로젝트 모두에서 코어 흐름이 일관적입니다. 관련된 권한을 요청하고 픽커를 시작한 후 사용자가 취소했는지 확인하고 첫 번째 자산을 읽습니다. 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.
라이브러리 및 카메라 흐름
라이브러리 흐름으로 시작하여 가장 빠른 기능을 구현하는 경로를 선택하십시오. 테스트가 더 쉽고, 시뮬레이터 환경에서 더 잘 작동하며, 카메라 하드웨어의 Edge 케이스를 피할 수 있습니다. 결과 처리 경로가 안정화된 후 카메라 지원을 추가하십시오.
개발 시 카메라 경로에는 더 많은 실패 방법이 있습니다. 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' },
]);
};이 분리로 각 함수가 집중적이게 됩니다. 또한 분석, 기능 플래그, 또는 백엔드 특정 규칙을 추가할 때 더 쉽게 할 수 있습니다. 예를 들어, 프로필 이미지 업로드를 라이브러리 업로드로 허용하지만 신뢰성 인증을 위해 카메라 캡처를 요구하는 팀이 있습니다.
애플리케이션의 더 넓은 범위가 Expo 이외의 파일 접근 패턴도 지원하거나, 네이티브 스택의 전통을 비교하고 싶다면, 이 Capacitor 사진 앨범 참조 이것이 유용한 맥락입니다.
짧은 데모가 팀원이나 QA 와 이것의 흐름을 보여주기 위해 도움이 됩니다.
시스템 UI에서 무엇을 기대할 수 있는지
expo-image-picker iOS 에서는 사용자가 제한된 앨범 접근 권한을 부여하는 대신에 전체 접근 권한을 부여할 수 있습니다. Android 에서는 OS 버전과 OEM 스킨에 따라 픽커 동작이 달라질 수 있습니다. 관리형 워크플로 프로젝트에서, Expo 는 더 많은 네이티브 연결을 처리합니다. 바레 워크플로 프로젝트에서, 사용자 빌드 앱이 네이티브 권한 변경을 포함하는지 확인해야 합니다. JavaScript 호출 사이트는 두 경우 모두 동일할 수 있지만 런타임 결과가 다를 수 있습니다.
일반적으로 이러한 케이스를 테스트하기 전에 기능이 완료된 것으로 간주합니다:
첫 번째 권한 요청
- 거부된 권한
- 사용자 취소
- 성공적인 앨범 선택
- 이것이 유용한 맥락입니다.
- 물리 장치에서 성공적인 카메라 캡처
- 반환된 로컬 URI의 즉각적인 미리보기
이러한 경우는 실제 운영 환경에서의 동작과 일대일로 매핑됩니다. 또한 파일을 서버, 중재 pipe line, 또는 게시 엔드 포인트(예: 인스타그램 미디어 게시 __CAPGO_KEEP_0__)로 전송해야 하는 경우 다음 단계를 깨끗하게 설정합니다. 인스타그램 미디어 게시 API.
픽커 결과 및 옵션 처리
픽커 결과는 일반적으로 실제 운영 로직이 필요합니다. 시스템 UI는 구조화된 객체를 반환하며, 작은 오류가 있으면 미리보기가 깨지거나 업로드가 빈번하거나 사용자가 취소할 때 앱이 충돌하는 경우가 발생합니다.
결과 객체를 올바르게 읽기
현재 Expo 앱에서 중요하는 결과 형태는 result.assets[0].uri, top-level result.uri가 아닌입니다. 이 세부 사항은 관리형 및 바레 워크 플로 프로젝트 모두에 영향을 미치며, 자바스크립트 API는 native 설정이 다르더라도 동일합니다.
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 |
부울 | 결과에 인코딩된 이미지 데이터를 추가합니다 | inline 이미지 데이터가 명시적으로 필요로 하는 통합만을 위해 |
몇 가지 트레이드 오프는 쉽게 놓치게 됩니다:
allowsEditing이미지 슬롯이 고정된 모양 또는 크기를 가지고 있을 때 유용합니다. 서버가 자신의 크롭 PIPELINE을 처리하고 원본 파일을 원한다면 유용하지 않습니다.quality업로드 시간, 메모리 압박 및 서버 저장 공간에 영향을 미칩니다.quality: 1자동으로 올바른 선택이 아닙니다.mediaTypes백엔드 규칙과 일치해야 합니다. 서버가 비디오를 거부한다면 픽커가 그들을 반환하지 않도록 하세요.base64메모리 내의 패이로드 크기를 증가시킵니다. 수신 서비스가 이를 요구하지 않는 한 피해야 합니다.
마지막 점은 낮은 메모리 장치에서 중요합니다. 로컬 파일 URI는 일반적으로 미리보기 및 멀티파트 업로드를위한 더 좋은 전달 방식입니다. Base64은 유효한 사용이 있지만 파일 참조를 전달하는 것과 비교하여 비용이 많이 들 수 있습니다.
URI versus base64
대부분의 앱의 규칙은 간단합니다:
- 사용하세요 URI 미리보기
- 사용 URI 파일 업로드를 위해 사용
- 사용 base64 받는 시스템이 인코딩된 콘텐츠를 명시적으로 요청할 때만 사용하세요.
이 패턴은 픽커 code를 작고 테스트하기 쉬운 크기로 유지하고, 백엔드 미디어 흐름의 많은 경우와 서비스를 외부 플랫폼에 게시하는 서비스를 포함하여 일치합니다. Instagram 미디어 게시 API.
팀이 자주 OTA 업데이트를 배포하거나 앱 전달을 통해 이미지-heavy 자산을 이동하는 경우, 여기서 파일 크기 결정은 PIPELINE의 나머지 부분으로 영향을 미칩니다. 이 픽커 구성에 대한 이 안내서 앱 업데이트를 위한 이미지 최적화에 대한 안내서 실제 앱에 대한 더 안전한 결과 패턴
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이 안정적이면 native 차이점을 처리하는 동안도 앱이 안정적입니다.
마지막 확인 단계도 있습니다. 추가 결과 필드를 활성화하지 마십시오. 필요한 데이터만 요청하고, 선택을 위한 픽커를 유지하고, 일반 파일 처리 단계로 변환하지 마십시오.
고급 패턴 및 플랫폼 차이점
픽커 기능이 선택된 이미지가 재시도, 인증 헤더, native 권한 차이점 및 실제 업로드 엔드포인트와 같은 요소에 의해 살아남아야 하는 순간부터 단순하지 않게 됩니다. expo-image-picker 선택을 잘 처리합니다. 나머지 기능은 앱에 달려 있습니다.
실용적인 업로드 패턴
API가 파일 업로드를 기대하는 경우 FormData 그것은 Rails, Node, Laravel, Django, Go 백엔드와 같은 일반적인 백엔드에서 작동하고, 픽커를 transport 문제에서 분리합니다.
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
uriexists before building the request - 업로드하기 전에 미리보기 렌더링하도록 하여 사용자가 잘못된 파일을 일찍 발견할 수 있도록 합니다.
- 요청이 진행 중일 때 반복적인 탭을 방지합니다.
- 선택기 취소 또는 권한 오류와 구분하여 네트워크 실패를 처리합니다.
- 서버가 큰 파일, 지원되지 않는 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 버전과 시스템 픽커 지원에 따라 달라집니다. 카메라 출력:
- 촬영된 이미지는 라이브러리 항목과 달리 이름, 방향, 압축 특성 등이 다를 수 있습니다. 편집 및 크롭: iOS와 Android 사이의 UI 및 크롭 동작이 동일하지 않습니다. 반환된 메타데이터: , 그리고 없거나 불일치할 수 있으므로 대체 항목을 추가하세요. 권한: iOS 사진 접근이 선택된 항목에만 제한될 수 있으면서, Android의 동작은 OS 버전과 시스템 픽커 지원에 따라 달라집니다. 카메라 출력: 촬영된 이미지는 라이브러리 항목과 달리 이름, 방향, 압축 특성 등이 다를 수 있습니다.
Expo에서 작업하는 팀과 함께 작업하는 경우에도 DesignStack 앱 개발 가이드 이것은 Expo 단일 라이브러리 외부에서 나타나는 미디어 처리 결정을 보여주는 유용한 Android 컨텍스트를 제공합니다.
관리형 워크플로우와 바레 워크플로우의 차이점
이 시점에서 설정 선택은 실제로 작동에 중요합니다.
관리형 워크플로우에서, 권한 문자열과 플러그인 구성은 일반적으로 앱 구성에서 살펴보며, 새로운 빌드 생성 시 네이티브 변경이 적용됩니다. 이로 인해 자바스크립트 표면 영역이 깨끗하지만, 구성 수정은 다음 네이티브 빌드까지 보이지 않습니다. OTA 업데이트는 누락된 네이티브 권한을 패치하지 않습니다.
바레 워크플로우에서, 동일한 기능은 더 많은 움직임이 있습니다. iOS 사용 설명서, Android 매니페스트 동작, 패키지 설치, 빌드 타이밍을 자체적으로 확인해야 합니다. 이로 인해 제어권이 있습니다. 그러나 픽커 문제는 네이티브 구성이 아닌 자바스크립트 호출 사이트 때문일 수 있습니다.
Teams that switch between Expo and Capacitor often underestimate how different these abstraction layers are. Capgo has a useful explanation of how Capacitor handles platform differences일반적인 문제 해결
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__
Expo 이미지 픽커 버그 대부분이 작은 범주의 몇 가지 카테고리로 분류됩니다. 가장 빠른 해결책은 일반적으로 실패하는 레이어를 식별하는 것입니다: config, 권한, 결과 처리, 또는 렌더링.
일반적인 실패에 대한 빠른 확인.
픽커가 열리지 않거나 권한이 실패하면 native 설정을 먼저 확인하십시오. bare 앱에서 특히, iOS 사용 설명서가 누락된 경우가 일반적인 원인입니다.
사용자가 픽커를 닫은 후 앱이 충돌하는 경우 결과 처리를 검사하십시오. 많은 implementation은 여전히 직접 URI를 가정하고 skip하는 check를 수행합니다. canceled 몇 가지 빠른 매핑을 도와드립니다:
권한이 거부된 오류:
- 앱 구성과 native 권한 문자열을 확인하고 다시 빌드하십시오. 이미지 URI:
undefined읽기 그것result.assets?.[0]?.uri, notresult.uri.- 취소하면 아무 일도 일어나지 않는다: 그것이 맞을 수도 있습니다. 취소는 무작위 상태로 처리하세요.
- 이미지가 렌더링되지 않는다: URI가 저장되었는지 확인하고 state에 전달되었는지 확인하세요.
<Image source={{ uri }} />. - 카메라가 시뮬레이터에서 이상하게 작동한다: 라이브러리 버그를 추적하기 전에 실제 기기에서 테스트하세요.
작업 중인 프로덕션 체크리스트
배송 전에 마지막으로 확인하세요:
- 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, 유효성 검사 규칙, 복사본, 또는 픽커 흐름과 관련된 자산 처리와 같은 경우에 관련이 있습니다.
