Expo Go

Analys av Reviewed

När jag använder Expo Go märks det snabbt att telefonen här främst är en testmiljö för appar, inte en färdig appbutikstjänst för vardagsunderhållning. Jag kan prova projekt som byggs med JavaScript och React och se hur de fungerar på en riktig mobilskärm. Det är användbart när jag vill kontrollera en idé, visa ett tidigt utkast eller själv känna skillnaden mellan att läsa kod och att faktiskt använda resultatet.

Det är också viktigt att förstå vad appen inte försöker vara. Expo Go är inte en allmän verktygslåda för att skapa appar direkt på telefonen och inte heller en samling fristående appar med samma gränssnitt. Upplevelsen beror på projektet jag öppnar och på att den aktuella utvecklingsmiljön kan nås. För en utvecklare eller nyfiken testare är det en praktisk genväg; för den som bara vill ladda ner en färdig app och börja använda den finns mer passande alternativ.

När nätverket blir en del av testningen

Expo Go kommer från Expo Project och hör hemma bland utvecklingsbibliotek och demoappar. Plattformen är fri och öppen, men själva mobilappen blir mest begriplig när jag ser den som en följeslagare till ett projekt som körs och ändras på annat håll. Det gör nätverksläget till en del av arbetsflödet: telefonen behöver kunna få kontakt med projektmiljön för att visa den version jag vill prova.

I praktiken påverkar det hur jag planerar en testomgång. Om jag ändrar en skärm och vill kontrollera resultatet på telefonen behöver jag både en fungerande projektstart och en anslutning som tillåter kommunikationen. En vanlig missuppfattning är att Expo Go ensamt innehåller projektet och alltid kan visa det oberoende av utvecklingsdatorn. Jag skulle i stället behandla det som ett visnings- och teststeg i en större utvecklingsprocess.

Det här upplägget är särskilt användbart när en detalj är svår att bedöma på en datorskärm. Jag kan kontrollera om text känns trång, om en knapp är lätt att nå med tummen eller om en vy ser rimlig ut i mobilformat. Det är konkreta saker som ofta går förlorade när jag bara tittar på en webbläsarförhandsvisning eller en statisk skärmbild.

En annan fördel med att testa på den riktiga enheten är att jag får en mer jordnära känsla för flödet. Jag märker om en liten förändring gör navigeringen tydligare eller om den bara ser bra ut i en isolerad vy. Samtidigt ska jag inte dra för stora slutsatser av ett enda lyckat test: ett projekt som öppnas i Expo Go har inte automatiskt bevisat att det är redo för distribution eller fungerar likadant i alla tänkbara miljöer.

Vem har mest nytta av upplägget?

Jag skulle främst rekommendera Expo Go till personer som arbetar med React-baserade mobilprojekt, studenter som lär sig genom att prova och team som vill visa en tidig idé på en faktisk telefon. Det passar också den som behöver en snabb kontroll av gränssnittet innan mer omfattande testning. För den som aldrig arbetar med ett projekt eller en utvecklingsmiljö kan appen däremot kännas tom eller svår att förstå, eftersom dess värde inte ligger i ett stort bibliotek av färdiga funktioner.

Jämfört med att bara granska en app i en webbläsare ger enheten en bättre känsla för beröring och skärmyta. Jämfört med att installera en separat testversion för varje liten ändring kan Expo Go vara smidigt i projekt där det passar. Men om arbetet kräver en färdig distributionslösning, särskilda projektanpassningar eller testning utanför den miljö som Expo Go stöder, är den inte en fullständig ersättning för andra utvecklings- och testverktyg.

På språng: användning på mobilen

Det mest realistiska vardagsscenariot är inte att jag bygger en hel app på bussen, utan att jag använder telefonen för att kontrollera något medan jag är på språng. Kanske har jag just ändrat en knapptext eller en startsida och vill se om den fungerar bättre i handen än på datorn. Då är mobilen själva testytan, medan det egentliga arbetet fortfarande hör hemma i projektets utvecklingsflöde.

Det gör Expo Go praktiskt för korta avstämningar, men mindre lämpat för längre arbetspass utan tillgång till resten av arbetsmiljön. Jag kan inte förvänta mig att appen ska ersätta en kodredigerare eller lösa projektets problem på egen hand. Mitt råd är att förbereda projektet när jag har en stabil arbetsplats och sedan använda telefonen för riktade kontroller: en viss vy, ett navigeringssteg eller ett visuellt beslut.

Det finns också en skillnad mellan att demonstrera ett projekt och att överlämna en produkt. Att öppna en fungerande prototyp för en kollega kan vara ett effektivt sätt att få reaktioner på känslan och användbarheten. Men om mottagaren behöver en app som fungerar självständigt och utan koppling till utvecklingsflödet bör jag välja ett annat sätt att dela den. Förväntningarna blir bättre när jag säger att det rör sig om testning, inte om en färdig konsumentapp.

På en liten skärm blir även testdisciplin viktig. Jag försöker ändra en sak i taget och kontrollera den på telefonen innan jag går vidare. Om jag samtidigt ändrar flera vyer eller beteenden blir det svårare att förstå vilken ändring som orsakar ett problem. Det är ett enkelt arbetssätt, men särskilt värdefullt när jag använder en mobil för snabb återkoppling och inte vill förvandla en kort kontroll till felsökning av flera saker samtidigt.

När anslutningen strular

Den tydligaste friktionen uppstår när telefonen inte kan nå projektet eller när projektet inte startar som väntat. Då hjälper det sällan att bara trycka runt i Expo Go och hoppas att rätt vy dyker upp. Jag skulle först kontrollera att utvecklingsprojektet faktiskt körs, att telefonen och den miljö som serverar projektet kan kommunicera och att jag öppnar rätt projekt. Det är en mer användbar felsökningsordning än att börja ändra appens inställningar utan att veta var avbrottet sitter.

Om en anslutning bryts mitt i en kontroll bör jag skilja mellan två frågor: är det själva projektet som har ett fel, eller har kontakten mellan telefonen och projektmiljön fallerat? Att starta om projektflödet och försöka öppna det igen kan vara rimligt, men jag skulle inte tolka ett tillfälligt anslutningsproblem som bevis på att appkoden är trasig. Omvänt kan en sida som väl visas fortfarande innehålla ett verkligt problem i projektet.

Det är här den stora skillnaden mot en installerad, färdig app märks. En vanlig konsumentapp är oftast tänkt att startas direkt för sitt avsedda ändamål. Expo Go är i stället en del av en process, och därför kan problem bero på projektet, nätverksvägen eller själva testmiljön. Den extra felsökningsbördan är ett rimligt pris för snabb iteration, men det är ändå en nackdel för den som förväntar sig ett självgående verktyg.

Ett praktiskt tips är att göra viktiga demonstrationer i god tid, inte precis när någon väntar på att få se en prototyp. Jag skulle kontrollera att projektet öppnas och att den centrala vägen fungerar innan mötet. Om det inte går att skapa en stabil anslutning är en skärminspelning eller en annan förberedd demonstration ofta bättre än att improvisera inför publiken. Det är ingen särskild funktion i appen, utan ett sätt att arbeta runt beroendet av ett fungerande testflöde.

Data och förberedelser

Eftersom upplevelsen bygger på kontakt med en projektmiljö är det klokt att tänka på datatrafik, särskilt när jag använder mobil uppkoppling. Jag skulle föredra ett tillgängligt och stabilt nätverk för återkommande testning och spara större genomgångar till en plats där anslutningen inte är en osäkerhetsfaktor. Det gör arbetet mer förutsägbart och minskar risken att jag blandar ihop nätverksproblem med ändringar i appen.

Det är också värt att vara uppmärksam på vad jag testar. En snabb visuell kontroll av en startsida är inte samma sak som att gå igenom alla flöden i ett projekt. Om jag vill undersöka en särskild vy kan jag hålla testet smalt och notera exakt vad jag gjorde innan något slutade fungera. Då blir det lättare att återskapa problemet när jag återgår till utvecklingsmiljön.

För den som oroar sig för användning utanför hemmet är den praktiska slutsatsen enkel: planera inte ett viktigt test som om anslutningen vore oväsentlig. Använd en nätverksmiljö som fungerar för projektet och ha en alternativ plan för en demonstration. Jag skulle inte välja Expo Go som enda sättet att visa en prototyp om jag vet att platsens nätverk är begränsat eller opålitligt.

Appen är gratis, vilket gör den lätt att prova utan att först behöva ta ställning till en kostnad. Den har PEGI 3 och passar därmed även yngre användare ur åldersmärkningens perspektiv, men dess praktiska målgrupp är ändå personer med intresse för apputveckling och testning. Det är viktigt att skilja mellan låg tröskel att installera och låg tröskel att förstå: nyttan blir störst när användaren redan har ett projekt att öppna.

Vad siffrorna säger – och inte säger

Expo Go har ett genomsnitt på 4,3 från omkring 32 000 betyg, och det visar att många användare har haft anledning att använda appen. Samtidigt är betyg mindre vägledande än vanligt här, eftersom upplevelsen påverkas av projektet och arbetsmiljön runt appen. Jag skulle därför läsa omdömet som en allmän signal, inte som ett löfte om att varje projekt öppnas utan friktion.

Med över fem miljoner installationer har appen nått långt utanför en liten grupp utvecklare. Den har funnits sedan den 8 december 2015, och version 57.0.9 visar att det är en etablerad produkt snarare än ett tillfälligt demoexperiment. Utvecklaren är Expo Project. Jag ser ändå den långa närvaron främst som bakgrund: det som avgör om den passar mig är om mitt projekt och mitt sätt att testa fungerar väl med den.

Mitt omdöme om uppkopplingsberoendet

Expo Go är som bäst när jag använder det för tydliga, avgränsade kontroller på en riktig mobil: känns en vy naturlig, går det att följa ett flöde och håller en ändring ihop i praktiken? Då sparar det tid och ger en sorts återkoppling som skärmbilder inte kan ersätta. Som gratis app inom utvecklings- och demoområdet är det ett rimligt första steg för den som redan arbetar med React och vill se sitt projekt på telefonen.

Min reservation är att nätverket och den omkringliggande projektmiljön påverkar upplevelsen mer än hos en vanlig mobilapp. Jag skulle inte rekommendera det till någon som vill skapa en app helt på telefonen, använda en färdig tjänst utan utvecklingsarbete eller förlita sig på en nätverksoberoende demonstration. I sådana fall är en färdig app, en annan testmetod eller en mer komplett distributionslösning ett bättre val.

För rätt person är Expo Go däremot en användbar bro mellan kod och verklig mobilanvändning. Mitt bästa råd är att se den som ett testfönster, hålla provomgångarna fokuserade och kontrollera anslutningen innan viktiga visningar. Om jag går in med de förväntningarna får jag ett smidigt sätt att granska projekt på enheten; om jag förväntar mig en fristående appbyggare blir jag sannolikt besviken.

Expo Go Vanliga frågor