Skip to Content
React Native2. Installation & premier projet2.2 Téléphone & Expo Go

Chapitre 2.2 — Ton téléphone = machine de dev

Où on en est : hello-rn tourne dans Metro, le QR code attend. On branche maintenant votre vrai téléphone Android — qui devient votre outil de développement principal pour les 9 prochaines parties.

⏱️ TL;DR — Installez Expo Go depuis le Play Store, scannez le QR de npx expo start (même WiFi que le PC), et votre app tourne sur le téléphone avec Fast Refresh : chaque sauvegarde dans VS Code se reflète en ~1 seconde. Secouez le téléphone pour le menu dev. En cas de blocage réseau (WiFi d’invités, pare-feu) : le mode tunnel ou le câble USB.

🎯 Objectifs

  • Faire tourner hello-rn sur votre téléphone en moins de 5 minutes.
  • Maîtriser le menu développeur et le Fast Refresh.
  • Diagnostiquer les 3 pannes classiques de connexion Metro ↔ téléphone.
  • Comprendre pourquoi le téléphone physique bat l’émulateur au quotidien.

Installation et premier scan

  1. Sur le téléphone : installez Expo Go (Play Store, gratuit).
  2. Sur le PC : npx expo start dans hello-rn (chapitre précédent).
  3. Téléphone et PC sur le même réseau WiFi — c’est la condition n°1.
  4. Scannez le QR du terminal avec Expo Go (ou l’appareil photo Android).

Expo Go télécharge le bundle JS depuis Metro et l’exécute. Votre app React tourne sur du vrai matériel — vrais pixels, vraie densité d’écran, vrai tactile, vraies perfs.

📱 Essaie sur ton téléphone — App lancée ? Ouvrez app/(tabs)/index.tsx dans VS Code, changez un texte, sauvegardez. Regardez le téléphone : ~1 seconde. C’est le Fast Refresh — le même qu’en Next.js, l’état des composants est même préservé quand c’est possible.

Le menu développeur

Secouez le téléphone (oui, vraiment) — ou tapez m dans le terminal Metro. Le menu dev d’Expo Go s’ouvre :

EntréeUsage
ReloadRecharge le bundle complet (quand Fast Refresh ne suffit pas)
Open React DevToolsInspecter l’arbre de composants (chapitre 2.4)
Toggle performance monitorFPS des threads JS et UI en surimpression — vos deux threads du chapitre 1.2, en direct
Toggle element inspectorToucher un élément → voir ses styles/box model

Raccourcis terminal Metro à connaître : r = reload, m = menu dev, j = ouvrir le debugger, a = lancer sur l’émulateur Android (chapitre suivant).

Quand ça ne se connecte pas

Le trio des pannes classiques — dans l’ordre de probabilité :

1. Pas le même réseau. PC en Ethernet + téléphone en WiFi peut suffire à casser la découverte selon le routeur. Vérifiez que l’IP affichée sous le QR (exp://192.168.x.x) est bien joignable depuis le téléphone.

2. Le pare-feu Windows bloque le port 8081 de Node. À la première exécution, Windows demande « Autoriser l’accès » — si vous avez cliqué Annuler un jour, Metro est muet. Autorisez Node.js sur les réseaux privés (Paramètres → Pare-feu → Autoriser une application).

3. Réseau qui isole les clients (WiFi d’hôtel, réseau d’entreprise, « isolation AP » des box). Solution universelle :

npx expo start --tunnel

Le trafic passe alors par un tunnel via les serveurs Expo — plus lent, mais fonctionne partout.

Dernière option, la plus robuste : le câble USB. Activez le débogage USB sur le téléphone (Paramètres → À propos → tapez 7 fois sur « Numéro de build » → Options développeur → Débogage USB), branchez, et Metro passera par adb (installé au chapitre suivant). C’est aussi le mode le plus rapide pour transférer les gros bundles.

⚠️ Piège — Si l’app charge mais affiche une erreur rouge plein écran (RedBox), ce n’est PAS un problème de connexion : c’est une erreur JS, la stack trace est dedans. Lisez-la comme une erreur Next.js en dev. La RedBox est votre amie — elle disparaît en production.

Pourquoi le téléphone d’abord (et pas l’émulateur)

Notre décision de cours — téléphone physique en principal — n’est pas un détail :

  • Le tactile est réel : tailles de cible, gestes, clavier — l’émulateur ment avec la souris.
  • Les perfs sont réelles : l’émulateur sur un PC à 64 Go de RAM est parfois PLUS rapide que le téléphone de l’utilisateur ; tester sur du vrai matériel calibre votre œil.
  • Les capteurs existent : haptics (Partie 9), caméra, notifications réelles sur l’écran verrouillé — l’émulateur les simule mal ou pas.
  • Zéro configuration, zéro RAM consommée sur le PC.

L’émulateur garde deux usages où il est roi : tester plusieurs tailles d’écran/versions d’Android sans acheter dix téléphones, et les captures d’écran propres pour le Play Store (Partie 13). D’où le chapitre suivant.

✏️ Exercices

1. Activez le performance monitor (menu dev) et observez les deux valeurs de FPS pendant que vous scrollez l’écran d’exemple. Que représentent « UI » et « JS » ? Reliez au chapitre 1.2.

✅ Solution

UI = les FPS du thread natif Android (rendu, scroll) ; JS = les FPS du thread Hermes (votre code React). Un scroll natif fluide garde UI≈60/120 même si JS chute — et un JS bloqué (calcul lourd) fait décrocher tout ce qui dépend de React. Ce sont les deux threads du schéma d’architecture (chapitre 1.2).

2. Provoquez volontairement une RedBox : dans index.tsx, appelez une fonction inexistante dans le JSX. Lisez la stack trace, réparez, observez le retour à la normale sans reload manuel.

✅ Solution

Ex. {plante()} dans le JSX → RedBox « plante is not defined » avec le fichier et la ligne. Après correction + sauvegarde, Fast Refresh recharge et la RedBox disparaît seule. Leçon : lire la PREMIÈRE ligne de la stack, le reste est du bruit de framework.

3. Votre WiFi isole les clients (le scan QR donne un timeout). Citez, dans l’ordre où vous les tenteriez, trois façons de développer quand même.

✅ Solution

(1) npx expo start --tunnel — universel, juste plus lent. (2) Câble USB + débogage USB (via adb) — rapide et fiable. (3) Partage de connexion : faire du téléphone le hotspot et y connecter le PC — les deux sont alors sur le même « réseau ». (Bonus : l’émulateur, chapitre suivant, qui n’a pas ce problème.)

🧠 Quiz

1. Quelles sont les deux conditions pour que le scan QR fonctionne en mode LAN ?

Réponse

Téléphone et PC sur le même réseau, et le port de Metro (8081) non bloqué par le pare-feu Windows (autoriser Node.js sur les réseaux privés).

2. Comment ouvre-t-on le menu développeur d’Expo Go ?

Réponse

En secouant le téléphone, ou m dans le terminal Metro. (Reload : r.)

3. Que signale une RedBox, et en quoi diffère-t-elle d’un échec de connexion ?

Réponse

Une RedBox = erreur JavaScript à l’exécution avec stack trace (l’app est bien connectée et chargée). Un échec de connexion = Expo Go n’atteint pas Metro (timeout, écran de chargement infini). Les remèdes sont totalement différents.

4. Dans quels cas préférer --tunnel ?

Réponse

Quand le réseau empêche la connexion directe : isolation des clients WiFi, réseau d’entreprise, pare-feu incontrôlable. Le trafic passe par les serveurs Expo — ça marche partout, plus lentement.

5. Donnez deux avantages décisifs du téléphone physique et deux cas où l’émulateur gagne.

Réponse

Téléphone : tactile/gestes réels, performances réelles (+ capteurs, notifications réelles). Émulateur : multiplier les tailles d’écran et versions d’Android, et faire des captures d’écran propres pour le store.

👉 Chapitre suivant : 2.3 — Android Studio & l’émulateur — le gros morceau de l’installation, une bonne fois pour toutes.

2.1 Node & create-expo-app2.3 Android Studio & émulateur