Vous êtes probablement arrivés à un point où l'interface utilisateur est prête, l'écran de profil a un bouton « Télécharger une photo », et maintenant la partie facile devient soudainement difficile. La véritable sélection d'image touche aux permissions natives, aux interfaces contrôlées par l'OS, aux formes de retour différentes que beaucoup de développeurs attendent, et une poignée de détails de build qui ne se montrent que lorsque vous expédiez un build réel.
C'est là que l'outil d'image Expo entre en jeu. Il s'agit de la bibliothèque officielle d'Expo pour ouvrir l'interface système pour choisir des images et des vidéos à partir de la bibliothèque du dispositif ou prendre une photo avec la caméra, comme décrit dans le Répertoire de packages Expo. En pratique, cela signifie que vous obtenez un pont fiable vers les entrées de médias natives, mais pas une expérience de médias personnalisée qui se comporte de manière identique sur chaque appareil.
Ce guide est écrit pour la première mise en œuvre, et non pour la démo. Il se concentre sur les décisions qui comptent en production : mise en place de flux de travail géré ou non géré, gestion des permissions qui ne vous surprendront pas plus tard, analyse de résultats sûre, et un modèle d'envoi pratique après que l'utilisateur ait sélectionné un fichier. Si vous travaillez dans un environnement de mise en œuvre native personnalisé, cela vous aide également à comprendre comment cela diffère d'un flux de travail de client de développement Expo. Expo development client workflow.
Table des matières
- Commencer avec l'outil d'image de l'Expo
- Installation et configuration essentielle
- Accéder à la caméra et à la bibliothèque de médias
- Gestion des Résultats et des Options du Sélecteur
- Modèles avancés et différences de plateforme
- Dépannage des problèmes courants
Commencer avec l'application Expo Image Picker
Un responsable produit demande des photos de profil. Une semaine plus tard, la même fonctionnalité nécessite également l'envoi de reçus, la capture de la caméra pour les rapports d'incident et les réessais lorsque les utilisateurs refusent la permission la première fois. L'entrée d'image s'élargit rapidement car elle touche les permissions natives, l'interface utilisateur propriétaire de l'OS, la gestion de fichiers temporaires et les flux d'envoi vers le serveur.
expo-image-picker est le module Expo SDK pour ce travail. Il ouvre le sélecteur de plateforme ou l'interface utilisateur de la caméra et retourne les médias sélectionnés sous une forme que votre application React Native code peut gérer. Le JavaScript API est petit. Le principal défi réside dans la mise en place native, la gestion des permissions et la gestion des résultats corrects sur les projets gérés et bare.
Le principal compromis est clair. Vous laissez iOS et Android présenter leurs propres interfaces utilisateur de médias au lieu de construire un sélecteur personnalisé. Cela donne généralement de meilleurs résultats : les utilisateurs comprennent déjà les écrans système, les invites de permission se comportent comme l'OS l'attend et votre équipe évite de maintenir une mise en page de galerie en JavaScript.
Traitez cela comme une intégration native avec une interface React.
Cette mentalité aide car les modes de panne sont rarement dans le bouton qui appelle le sélecteur. Ils viennent généralement d'une des trois places :
- Configuration native : setup de plugin manquant, chaînes de permission incorrectes ou une construction obsolète après avoir changé la configuration
- Comportement en temps de cours : les utilisateurs peuvent refuser l'accès, accorder un accès de bibliothèque limité sur iOS ou annuler la flux sans sélectionner quoi que ce soit
- Analyse des résultats : le module actuel API retourne un
assetsarray, donc les exemples plus anciens qui lisentresult.uriéchouent directement
La sélection du workflow change également le chemin de configuration. Dans une application Expo gérée, la plupart du travail natif vit dans la configuration de l'application et nécessite une reconstruction lorsque cette configuration change. Dans une application bare, vous obtenez toujours le module Expo API, mais vous devez vérifier les paramètres de projet iOS et Android plus directement. Si votre équipe utilise un client personnalisé au lieu d'Expo Go, ce guide s'associe bien à l'explication de Capgo sur comment un client de développement Expo modifie la mise en œuvre de la test de module natif.
Cette division compte pour le reste de la guide car le chemin heureux n'est qu'une moitié de l'histoire. Une mise en œuvre de sélection est solide lorsque cela fonctionne dans les deux workflows, gère les particularités de permissions spécifiques à la plateforme sans surprendre l'utilisateur, et transmet un fichier utilisable à votre couche d'envoi au lieu d'arrêter à une prévisualisation locale.
Installation et Configuration Essentielle
Installation nécessite une seule commande. C'est la configuration native qui détermine si le sélecteur fonctionne sur un appareil réel, dans un client de développement personnalisé, et dans votre build de production.
expo-image-picker gives a React-facing API over the platform pickers for photos, videos, and camera capture. The JavaScript call is simple. The setup is not, because photo access and camera access are controlled by iOS and Android, not by React Native.
Commencez par l'installateur version-aware d'Expo :
npx expo install expo-image-pickerUtilisez expo install au lieu de npm install ou 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 Configuration de flux géré Exemple avec
C'est le minimum de configuration. Dans la pratique, les équipes ajoutent généralement du texte de permission ainsi que, en particulier sur iOS, la prompt du système devrait expliquer pourquoi l'application a besoin d'accès. Gardez le langage spécifique à l'action de l'utilisateur. « Télécharger une photo de profil » est mieux que « Besoin d'accès aux médias ».
Un détail opérationnel cause beaucoup de temps perdu. Changer
les chaînes de permission, ou d'autres configurations natives nécessite une nouvelle construction. Le rechargement du JavaScript n'applique pas ces changements. Dans Expo Go, vous êtes également limité par ce que le client inclut déjà. Dans une construction de développement ou de production, le projet natif reflète votre configuration uniquement après une nouvelle construction. app.json:
{
"expo": {
"plugins": ["expo-image-picker"]
}
}Configuration de setup React Native sans enveloppe
Dans une application sans enveloppe, le package __CAPGO_KEEP_0__ est le même, mais vous devez vérifier plus de projet natif vous-même. Les descriptions d'utilisation iOS sont la première chose à vérifier. Si votre flux peut ouvrir la bibliothèque, lancer la caméra ou enregistrer une vidéo avec audio, votre application a besoin des chaînes de permission correspondantes dans pluginsappflow_plugins_or
Expo correspond à la version du package à votre __CAPGO_KEEP_0__, ce qui évite un type courant de problèmes de compatibilité natives. Si vous comparez comment les modules Expo s'intègrent à votre processus de mise en production, cela
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 avant de reconstruire.
Un checklist pratique pour les projets sans dépendances ressemble à ceci :
- Installer
expo-image-pickeravecnpx expo install expo-image-picker. - Si votre projet utilise des plugins de configuration Expo, ajoutez la configuration du plugin.
- Confirmez que les descriptions d'utilisation iOS correspondent aux fonctionnalités que vous exposez.
- Reconstruire les applications iOS et Android après tout changement de configuration native.
Missing permission text often looks like a runtime bug because the UI code is fine and the button handler runs. The failure is lower in the stack. I usually check Info.plist, la configuration de l'application, et si la dernière build inclut les dernières modifications natives avant de toucher le composant code.
Un certain nombre de habitudes rendent l'installation plus prévisible :
- Écrire le texte de permission pour l'action réelle : les utilisateurs doivent comprendre pourquoi ils voient la prompt.
- Configureur de la caméra et de la bibliothèque séparément : Un peut fonctionner tandis que l'autre continue à échouer.
- Reconstruire après les modifications natives : Le rechargement chaud et la mise à jour rapide ne mettent pas à jour les permissions natives.
- Tester sur appareil : Le comportement du simulateur peut cacher les problèmes de permission et de caméra.
Si le sélecteur de médias fonctionne pendant le développement mais se brise dans TestFlight ou la mise à jour de Google Play, considérez cela comme un problème de configuration en premier lieu. La plupart du temps, c'est le cas.
Accès à la Caméra et à la Bibliothèque de Médias
Un utilisateur appuie sur « Télécharger une photo », s'attend à ce que la caméra ou la bibliothèque s'ouvre, et votre application a une seule tâche à ce moment-là. Ouvrez l'interface utilisateur système appropriée, gérez le refus ou l'annulation sans casser l'écran, et renvoyez une référence de fichier local utilisable pour la prévisualisation ou l'envoi.
Cela semble simple jusqu'à ce que vous testiez les builds gérés et non gérés sur iOS et Android. Le JavaScript API reste compact, mais le comportement de l'exécution dépend toujours des invites de l'OS, du matériel du dispositif et de la façon dont vos permissions natives ont été configurées précédemment.
Un composant minimal mais sûr
Le flux de base est cohérent dans les projets de workflow Expo géré et non géré. Demandez la permission pertinente, lancez le sélecteur, vérifiez si l'utilisateur a annulé, puis lisez le premier élément de la liste de ressources : result.assets.
Un composant de base ressemble à ceci :
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>
);
}Trois détails sont importants ici.
- Demandez les permissions de bibliothèque et de caméra séparément. Elles échouent indépendamment.
- Traitez l'annulation comme une action utilisateur normale, et non comme un état d'erreur.
- Lire de
assets[0], car le sélecteur renvoie un tableau de ressources plutôt qu'un élément de niveau supérieururi.
Flux de bibliothèque et de caméra
Commencez par le flux de bibliothèque si vous voulez emprunter la voie la plus rapide vers une fonctionnalité fonctionnelle. Il est plus facile à tester, il fonctionne dans plus de configurations de simulateur, et il évite les cas d'extrémité de matériel de la caméra. Ajoutez ensuite le support de la caméra une fois que le chemin de traitement des résultats est stable.
Le chemin de la caméra a plus de façons de fail en développement. Le support du simulateur iOS est limité. Les émulateurs Android peuvent ne pas exposer le comportement de la caméra qui correspond à un appareil réel. Dans les projets non gérés, ces lacunes peuvent vous faire chercher dans le composant code même si la vraie question est la configuration native ou l'environnement de test.
Un modèle de conception de l'interface utilisateur propre consiste à demander à l'utilisateur la source avant d'appeler le sélecteur API :
const showPickerOptions = () => {
Alert.alert('Upload image', 'Choose a source', [
{ text: 'Camera', onPress: takePhoto },
{ text: 'Photo Library', onPress: pickFromLibrary },
{ text: 'Cancel', style: 'cancel' },
]);
};Cette séparation maintient chaque fonction focalisée. Cela rend également plus facile d'ajouter des analyses, des drapeaux de fonctionnalité ou des règles spécifiques au serveur ultérieurement. Par exemple, certaines équipes autorisent les téléchargements de bibliothèque pour les images de profil mais exigent des captures de caméra fraîches pour la vérification d'identité.
Si votre application plus large prend également en charge des modèles d'accès au fichier en dehors d'Expo ou que vous comparez des conventions entre les stacks natives, cela Capacitor référence de la bibliothèque photo est un contexte utile.
Une courte démo est utile lorsque vous montrez ce flux à vos collègues ou à la QA :
Ce que vous pouvez attendre de l'interface utilisateur système
expo-image-picker ouvre le sélecteur de plateforme ou l'interface utilisateur de la caméra. Votre application ne contrôle pas chaque écran dans ce flux. Cette distinction compte car « cela fonctionne sur mon appareil » signifie souvent « l'OS a autorisé le chemin que j'ai testé. »
Sur iOS, les utilisateurs peuvent accorder un accès limité à la bibliothèque au lieu d'un accès complet. Sur Android, le comportement du sélecteur peut varier en fonction de la version du système d'exploitation et de la peau du fournisseur. Dans les projets de workflow gérés, Expo gère plus de la mise en œuvre native pour vous. Dans les projets de workflow bare, vous devez confirmer que votre application compilée inclut les modifications de permissions natives que vous avez apportées. Le site d'appel JavaScript peut être identique dans les deux cas, tandis que le résultat en temps de cours diffère.
Je teste généralement ces cas avant d'appeler la fonctionnalité terminée :
- première demande de permission
- permission refusée
- annulation de l'utilisateur
- réussite de la sélection de la bibliothèque
- prise de vue réussie sur un appareil physique
- prévisualisation immédiate de l'URI local retourné
Ces cas correspondent directement au comportement de production réel. Ils mettent également en place l'étape suivante de manière propre si vous devez envoyer le fichier à un serveur, une chaîne de traitement de moderation ou un point de terminaison de publication, comme par exemple le publier des médias Instagram sur API.
Gestion des résultats et des options du sélecteur
Le résultat du sélecteur est la partie qui nécessite généralement une logique de production réelle. L'interface utilisateur système retourne un objet structuré, et non juste un chemin de fichier, et de petites erreurs ici entraînent des prévisualisations brisées, des téléchargements vides ou des plantages après que l'utilisateur annule.
Lecture de l'objet résultat correctement
La forme du résultat qui compte dans les applications Expo actuelles est result.assets[0].uripas un élément de niveau supérieur result.uri. Cette détail affecte à la fois les projets de workflow gérés et les projets bare car le JavaScript API est le même même si la mise en place native diffère en dessous.
Utilisez un modèle de garde d'abord :
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);Cela gère les deux cas de figure d'erreur que je vois le plus souvent. Un sélecteur annulé ne vous donne pas d'actif à lire, et code qui suppose result.assets[0] existe toujours et échouera en temps de routinisation.
Une fois que vous avez l'URI, la mise en page d'une prévisualisation est simple :
<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />Si vous prévoyez d'uploader plus tard, conservez l'objet entier, et non seulement l'URI. En pratique, asset , et fileName, mimeType, width, heightsont souvent utiles pour la validation, le journalisation ou la construction d'une demande multipart plus propre. fileSize Les options qui changent le comportement en aval
Une poignée d'options de sélection affectent plus que l'écran de sélection. Elles façonnent la taille du fichier, le comportement d'édition et ce que votre serveur doit accepter.
Option
| Type | Cela change | Utilisation typique | __CAPGO_KEEP_0__ |
|---|---|---|---|
mediaTypes |
array | Restreint ce que l'utilisateur peut choisir | Limitez la sélection aux images si votre API ne prend en charge que les images |
allowsEditing |
boolean | Permet à l'OS d'offrir une interface de coupe ou d'édition où cela est pris en charge | Avatars, couvertures carrées, capture de reçus |
quality |
number | Comprime les sorties d'image prises en charge | Réduit la taille de téléchargement pour les réseaux mobiles |
base64 |
boolean | Ajoute les données encodées de l'image au résultat | Seulement pour les intégrations qui exigent explicitement des données d'image inline |
A quelques compromis sont faciles à manquer :
allowsEditingest utile lorsque l'emplacement de l'image a une forme ou une taille fixe. Il est moins utile si votre serveur gère son propre pipeline de coupe et que vous souhaitez le fichier original.qualityaffecte le temps d'envoi, la pression de la mémoire et l'espace de stockage du serveur.quality: 1n'est pas automatiquement le choix le plus approprié.mediaTypesdevrait correspondre aux règles du serveur. Si le serveur rejette les vidéos, n'autorisez pas le sélecteur de retourner les fichiers.base64augmente la taille du payload en mémoire. Évitez-l’à moins que le service de réception ne le nécessite.
Dernier point important sur les appareils à faible mémoire. Une URI de fichier local est généralement la meilleure remise pour la prévisualisation et l'envoi en plusieurs parties. Le base64 a des utilisations valides, mais il est coûteux par rapport à la transmission d'une référence de fichier.
URI versus base64
Pour la plupart des applications, la règle est simple :
- Utilisez URI pour les prévisualisations.
- Utilisez Utilisez l'URI pour les téléchargements de fichiers.
- Utilisez base64 seulement lorsque le système de réception demande explicitement du contenu codé.
Cette approche garde le sélecteur code petit et plus facile à tester. Cela correspond également à la manière dont de nombreux flux de médias backend sont conçus, y compris les services qui publient finalement sur des plateformes externes telles que le l'API de publication de médias Instagram.
Si votre équipe met en œuvre des mises à jour OTA fréquentes ou déplace des actifs imageurs à travers la livraison d'applications, les décisions de taille de fichiers ici se répercutent dans le reste de la chaîne de production. Ce guide sur l'optimisation des images pour les mises à jour d'applications est un compagnon utile à la configuration du sélecteur. Un modèle de résultat plus sûr pour les applications réelles
Utilisez
Pour le démo code, il est suffisant de stocker uniquement imageUri Cela suffit. En production, stockez un objet normalisé afin que la prochaine étape, la prévisualisation, la validation, l'upload ou la réessayer, ne nécessite pas de réinterpréter la réponse du sélectionneur raw chaque fois.
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,
});Cela vous donne une forme prévisible à l'intérieur de l'application. Cela rend également les projets gérés et bare plus faciles à maintenir alignés car l'application code reste stable tout en travaillant sur les différences natives ailleurs.
Une vérification finale vous aide. N'activez pas les champs de résultats supplémentaires juste au cas où. Demandez les données que vous savez que vous avez besoin, et gardez le sélectionneur concentré sur la sélection plutôt que de le transformer en une étape de traitement de fichiers général.
Modèles avancés et différences de plateforme
Un élément de sélection fonctionne bien. Le reste de la fonctionnalité est à votre application. expo-image-picker Un infographic intitulé Téléchargements d'images : Considérations de stockage local vs. stockage serveur affichant les avantages et les inconvénients du stockage serveur.
Pour les APIs qui attendent un upload de fichier
Cela est encore le défaut le plus sûr. Il fonctionne sur les backends Rails, Node, Laravel, Django et Go courants, et il garde le sélectionneur séparé des préoccupations de transport. FormData Cela __CAPGO_KEEP_0__ est suffisant pour prouver que le chemin fonctionne, mais les applications de production ont généralement besoin d'une couche supplémentaire. Dérivez
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();
}That code is enough to prove the path works, but production apps usually need one more layer. Derive name et type attachez l'authentification à l'élément sélectionné lorsque possible, et maintenez l'état de téléchargement séparé de l'état du sélecteur afin qu'une requête échouée n'oblige pas l'utilisateur à rouvrir la bibliothèque.
Un certain nombre de vérifications empêchent les échecs courants que j'observe en revue :
- Confirmez que le fichier local
uriexiste avant de construire la requête - Affichez une prévisualisation avant le téléchargement afin que les utilisateurs détectent le fichier incorrect tôt
- Empêchez les appels répétés pendant que la requête est en cours de traitement
- Gérez les erreurs de réseau séparément des annulations du sélecteur ou des erreurs de permission
- Attendez que la validation côté serveur rejette les fichiers volumineux, les types MIME non pris en charge ou les informations d'authentification manquantes
Si votre serveur exige la base64 au lieu du multipart, il s'agit généralement d'une contrainte du serveur et non d'une exigence du sélecteur. Le multipart est moins coûteux en mémoire et plus facile à raisonner sur les appareils mobiles.
Où les différences entre plateformes ont vraiment de l'importance
L'interface utilisateur du sélecteur est native, elle hérite donc du comportement natif. Cela affecte à la fois ce que les utilisateurs voient et ce que votre code devrait supposer.
On iOS, les flux d'édition et les invites de permission suivent les conventions d'Apple. L'accès aux photos limité peut retourner un ensemble d'actifs plus étroit que votre compte de test a vu sur un appareil avec une autorisation complète. Sur Android, le comportement du sélecteur varie plus en fonction de la version du système d'exploitation et de la peau du fabricant, surtout autour des albums, des noms de fichiers et de la façon dont les captures de la caméra sont retournées. Les applications React Native nues ressentent ces différences plus directement car vous contrôlez plus de la mise en place native, mais les applications Expo gérées ont toujours besoin de code qui traite le sélecteur comme une forme de plateforme plutôt que parfaitement uniforme.
La règle pratique est simple. Faites confiance aux champs que vous pouvez valider, et non à des interfaces utilisateur ou des métadonnées identiques entre appareils.
Un ou deux exemples comptent dans les applications réelles :
- Édition et recadrage : La mise en page et le comportement de recadrage ne sont pas identiques entre iOS et Android
- Les métadonnées retournées :
fileName,mimeType, etfileSizepeuvent être absents ou incohérents, il faut donc ajouter des valeurs par défaut - Les permissions : L'accès aux photos d'iOS peut être limité aux éléments sélectionnés, tandis que le comportement d'Android dépend plus de la version du système d'exploitation et du support du sélecteur système
- La sortie de la caméra : Les images capturées peuvent revenir avec des caractéristiques de nommage, d'orientation ou de compression différentes que les actifs de la bibliothèque
Si votre équipe travaille également en dehors d'Expo, ce Guide de développement d'applications DesignStack Cela fournit un contexte Android utile pour les décisions de gestion de médias qui se produisent au-delà d'une seule bibliothèque.
Gestion gérée vs. flux de travail bare
À ce stade, les choix de configuration commencent à avoir un impact opérationnel.
Dans le flux de travail géré, les chaînes de permission et la configuration du plugin vivent généralement dans la configuration de l'application, et les modifications natives sont appliquées lors de la création d'une nouvelle build. Cela garde la surface d'interface JavaScript propre, mais cela signifie également que la correction de la configuration n'est pas visible avant la prochaine build native. Les mises à jour OTA ne corrigent pas les permissions natives manquantes.
Dans le flux de travail bare, le même fonctionnement a plus de parties en mouvement. Vous devez vérifier les descriptions d'utilisation iOS natives, le comportement de la feuille de route Android, l'installation du package et la synchronisation de la build vous-même. L'avantage est le contrôle. Le coût est que les problèmes de sélection peuvent être causés par la configuration native, et non par le site de l'appel JavaScript.
Les équipes qui passent entre Expo et Capacitor sous-estiment souvent à quel point ces couches d'abstraction sont différentes. Capgo a une explication utile de comment Capacitor gère les différences de plateforme, et c'est un bon point de comparaison si vous décidez de savoir combien de paramètres de configuration native votre équipe souhaite gérer.
Ma préférence est cohérente dans les deux flux de travail. Gardez le sélecteur code étroit, normalisez le résultat une fois, envoyez-l’à travers un couche API dédiée, et traitez le comportement spécifique de la plateforme comme quelque chose à configurer et à tester explicitement plutôt que de le lisser avec des hypothèses.
Résoudre les problèmes courants
La plupart des bogues de l'outil de sélection d'image Expo se répartissent en quelques catégories. La solution la plus rapide est généralement d'identifier la couche qui ne fonctionne pas : la configuration, les autorisations, la gestion des résultats ou la mise en page.
Vérifications rapides pour les échecs courants
Si le sélecteur ne s'ouvre pas ou si les autorisations échouent, vérifiez la mise en place native en premier lieu. Dans les applications bare en particulier, les descriptions d'utilisation iOS manquantes sont une cause courante de racine.
Si l'application s'arrête après que l'utilisateur ferme le sélecteur, inspectez la gestion de vos résultats. De nombreuses implémentations supposent toujours une URI directe et ignorent la canceled Vérifiez votre configuration d'application et les chaînes de permission native, puis rebuild.
URI de l'image :
- Lire de , pas
undefinedVérifiez votre configuration d'application et les chaînes de permission native, puis rebuild. Vérifiez votre configuration d'application et les chaînes de permission native, puis rebuild.result.assets?.[0]?.uriVérifiez votre configuration d'application et les chaînes de permission native, puis rebuild.result.uri.- Rien ne se produit après annulation : Cela peut être correct. Traitez l'annulation comme un état sans opération.
- L'image ne s'affiche pas : Confirmez que l'URI a été stockée dans l'état et transmise à
<Image source={{ uri }} />. - La caméra se comporte de manière étrange dans le simulateur : Testez sur un appareil physique avant de poursuivre une erreur de bibliothèque.
Un bref checklist de production
Utilisez cela comme dernier passage avant la livraison :
- Installer avec les outils Expo : Utilisez
npx expo install expo-image-picker. - Configurer les pièces natives : Ajoutez le plugin et les descriptions des permissions requises.
- Demander des autorisations intentionnellement : Flux de caméra et de bibliothèque de médias séparés.
- Protéger chaque résultat : Vérifier
result.canceledet lire de manière sûreassets[0]. - Préférez les téléchargements basés sur URI : Conservation de base64 pour des cas spéciaux uniquement.
- Tester des appareils réels : En particulier pour la capture de la caméra et les invitations de permission.
Si votre équipe embarque des applications Capacitor ou Electron aux côtés de projets React Native, Capgo est une option pour livrer des mises à jour de JavaScript, CSS, de configuration et d'actifs sans attendre la revue de magasin pour chaque changement. Cela est pertinent lorsque des correctifs d'image vivent dans votre couche web, comme l'interface utilisateur de téléchargement, les règles de validation, le texte ou la gestion d'actifs autour du flux de sélection de l'image.
