Hantera "fragmentering": Utvecklare ljuder på att stödja flera skärmar

Android körs en mängd olika enheter, vilket innebär att den också körs på en mängd olika skärmstorlekar och upplösningar. Många människor kallar detta för "fragmentering". Tänk på att de har använt produkter som har designats och utvecklats på samma sätt i flera år på skrivbordet. Uppenbarligen om allt inte är exakt samma får etiketten "fragmentering".

Det finns olika sätt att hantera de problem som uppstår när du använder skärmar med olika storlekar och densiteter. Äpple har separata listor för appar som är utformade för iPhone kontra iPad. Microsoft skapar ett nytt ekosystem för storskärmsenheter. Android ger ett sätt för utvecklare att få samma app att fungera annorlunda för olika skärmar. Det finns bra och dåliga med varje metod, men vi kommer att fokusera på Android här.

I Android kan applikationer justera layouten för olika skärmar och upplösning. Det här är allt inbyggt, men det finns några saker som utvecklare behöver förklara i sin kod för att appen ska se bra ut. Saken att tänka på är hur skärmstorlek och densitet kommer att förändra appens utseende. De

Droid-DNA har en skärm med högre upplösning än Motorola XOOM surfplatta, men vi vill inte se en surfplattlayout för appar på telefonstorleken.

En utvecklare måste tillhandahålla tillgångar (bilder) som har tillräckligt hög kvalitet för att se skarpa ut med hög upplösning (tänk inte vansinnigt hög upplösning), och var noga med att använda densitetsoberoende pixelenheter när du utformar deras layout. Detta är vad som hindrar saker som knappar och andra kontroller från att vara riktigt stora på skärmar med låg densitet som Galaxy S2, eller från att vara riktigt små på skärmar med hög densitet som DNA.

Det låter komplicerat, men det mesta av det här görs åt dig när du kodar en app. Allt som utvecklaren behöver göra är att göra rätt deklarationer och tillhandahålla rätt tillgångar för att stödja valfri storlek (både fysisk och upplösning) eller layout. Till och med flera layoutappar som Google+-appen använder samma kod för att täcka alla tänkbara skärmar.

Vi försöker inte bedöma utvecklare här. Att skriva appar är tufft. Android-utvecklarna har predikat allt detta sedan lanseringen av pepparkakor, men hur praktiskt är det? Vi frågade några utvecklare om det, se vad de hade att säga efter pausen.

Mer: Googles Android-utvecklarsida.

Vi ställde en handfull utvecklare (både stora och små) några grundläggande frågor om ämnet.

• Hur svårt är det att följa riktlinjerna?
• Det ser lätt ut på papper, men finns det några speciella problem du har sett eller delar som Google inte har täckt?
• Hur påverkade detta utvecklingstiden och kostnaderna, om alls?
• Något mer om ämnet du vill dela?

Jag försökte göra frågorna så neutrala som möjligt så att vi inte går in på detta med en viss förspänning på plats. När du är osäker, frågar du de människor som vet, eller hur? Jag har gjort min del av programmeringen, men kodning i Java och byggande av Android-appar skiljer sig mycket från att skriva kod i C eller maskinkod, eller till och med Perl. Det finns nyanser som jag inte förstår, även om jag får de allmänna metoderna för att bygga en app.

Jag antar att ett stort antal av er är som jag och inte känner till svårigheterna med att bygga Android-appar. Vi ser bara vad Android-utvecklarna säger, och de låter det låta enkelt. För dem är det förmodligen - de har skrivit de här sakerna från grunden sedan 2007. Låt oss se vad folket som har kunnat följa dem har att säga.

Joe Simpson (@kennydude) - Boid

Joe är medlem i Team Boid och publicerar också applikationer på egen hand. Han (och resten av hans team) är ett utmärkt exempel på oberoende utvecklare med en passion för Android som har valt ut några fantastiska applikationer.

Att följa riktlinjerna är ganska svårt, särskilt om du vill ha en mager app men folk vill ha bakkompatibilitet. En av de mest irriterande sakerna är att se hur något ser ut på d.android.com/design [Googles webbplats för utvecklare av Android] men inget om hur man faktiskt gör det.

En svag punkt är uppfriskande när du fysiskt inte kan använda GCM [Google Cloud Messaging] på grund av Twitter, och du inte vill använda PtR [Pull to Refresh]. Googles appar utgör också sina egna riktlinjer. Ta till exempel inrutan, Google+ gör det annorlunda än YouTube (även om jag vet att supportbiblioteket förhoppningsvis kommer att lösa detta).

Du kan också komma till en punkt och det finns ingen dokumentation om något (EdgeEffect till exempel).

Jag är student, så kostnader är något jag inte ser ut, och ja det tar tid, men dina användare kommer att älska dig. I grund och botten är Live Shows (ADiA, App Clinic, Office Hours) ett måste (tyvärr) även om de inte kan ge feedback om Googles appar.

Boid är snart att gå öppen källkod (yay!), och du kan hitta appen i Google Play. Du hittar också alla Joes appar (det finns några juveler där) precis här.

Christophe Versieux - BeTrains - SNCB Belgien; Holo överallt

Christophe har byggt många Android-applikationer, inklusive BeTrains - SNCB Belguim - en app med en underbar layout som visar vad som kan göras med en välbyggd applikation. Medan de flesta i USA aldrig kommer att använda den (det är en app för tågschema för belgiska räls) är det värt att installera bara för att se hur bra det är gjort. Folket i Västeuropa känner verkligen till den här.

Dessutom har han utvecklat HoloEverywhere, ett bibliotek som andra utvecklare kan använda för att bygga Holo-applikationer för Android 2.1 och högre. Med många telefoner som fortfarande kör pepparkakor är detta en riktig behandling för utvecklare som vill hålla sina appar ser aktuella ut.

Det är inte svårt alls. Allvarligt. Den svåra delen kommer när kunden ber om att komma bort från dessa riktlinjer!

Jag minns en kund som ville att jag skulle sätta flikar längst ner på skärmen, iPhone-knappar överallt, Växla i iPhone-stil och det här projektet var riktigt svårt att uppnå och jag tappade verkligen mycket tid och pengar på Det.

Jag var riktigt arg på honom när han frågade alla dessa dumma saker, och han trodde bara att jag var en lat utvecklare.

Jag har nu mycket kontakt med honom och vi skriver helt om hans app, skapar fantastisk kod genom att ta bort alla dessa värdelösa funktioner och skapa en "ren" Android-app. Jag tror starkt att kunderna och företagen måste vara medvetna om dessa riktlinjer.

Bibliotek gillar ActionBarSherlock, HoloEverywhere (min skapelse), UnifiedPreferencesoch Skjutmeny är väldigt enkla att använda och ger i några rader kod en fantastisk användarupplevelse.

Tid och kostnad, som jag sa, minimeras genom att följa Googles riktlinjer. Fragment och layoutmappar är riktigt enkla att använda (och viktigare att återanvända): en surfplattaapp tar bara en bit kod från telefonens layout och ingenting får skrivas om. Små förändringar i telefonappen återspeglas omedelbart i tablettappen, eftersom samma fragment används.

Några fantastiska projekt skapas av samhället, inte alltid av Google. Vissa människor, mycket aktiva på Google+ som Roman Nurik (Google), Reto Meier (Google) Juhani Lehtimäki, Jake Wharton, Taylor Ling,.. (Jag är alltid rädd för att glömma viktiga människor) är väldigt lärorika. Utvecklare behöver bara veta var de ska leta och Android-utveckling blir lätt för dem!

Du kan hitta BeTrains på Google Play, och du vill ta en titt på HoloEverywhere om du är intresserad av Android-utveckling.

Matthew Runo - Zappos

Till skillnad från några av de mindre oberoende utvecklarna vi pratade med hörde vi också från Matthew på Zappos. Zappos är ett webbhandelsföretag och har sannolikt en dedikerad budget för design på både deras webbplats och deras applikationer. Det är också ett företag som jag köper regelbundet från, men detta hade ingen betydelse och Matthew var inte medveten om att jag är en frekvent kund när han frivilligt.

Eftersom vi är återförsäljare på Zappos måste vi först och främst hålla oss till vårt eget varumärke. Wacky, roligt och lite utanför väggen. Som sagt, vi båda är starka troende på riktlinjerna för Android-design - och allt vi gör i användargränssnittet är hämtat från andan i dessa regler. För ett år sedan var vår app mestadels en iOS-port från hur den såg ut och fungerade. Idag är det (tror jag) en pärla till vad du kan göra i Android. Vi följer riktlinjerna när det är möjligt - och våra designers arbetar utifrån dem som utgångspunkt.

Riktlinjerna för design är inte en vara alla och sluta allt - i slutändan är de bara där för att försöka driva designen av Android-appar så att de är mer konsekventa. Vi har upptäckt att de flesta vanliga "nya" öppen källkodsbibliotek som vi har använt har hamnat som en del av riktlinjerna (skjutmeny, krutong).

Riktlinjerna ska aldrig vara ett tillbakagång. Vissa saker - övergripande navigering - måste vara konsekventa så att din app "bara fungerar". Allt annat - börja med riktlinjerna och kör med din design. Vi vill att vår app ska vara VÅR APP - så vi kan inte bara göra baslinjetemat.

I år har vi i grunden startat från en grundläggande omskrivning av vår app för att arbeta med fragment. Under de senaste sex månaderna har vi arbetat hårt för att lägga till 7 "surfplattestöd, och vi arbetar för närvarande med 10" support. Det svåraste att göra är att testa på enheter, men vi har ett fantastiskt QA-team som hjälper till med det. Vi har haft 2 personer som arbetar heltid på vår app sedan augusti eller så, innan det var en heltidsanställd.

Slutsatsen är, tror jag, riktlinjerna för design av Android hjälper oss att effektivisera vår process - och därmed minska kostnaderna. Låt oss inse det, de flesta designers från iOS - så att ha en bra resurs som design.android.com är en underbar hjälp för att få dem att starta i Android-ekosystemet.

Jag kan säga att Zappos designval fungerar bra, och min fru har en garderob full av kläder, plånböcker och stövlar som förstärker mitt krav. Kolla in deras Android-app från Google Play.

Josh Burton - jRemote

Josh har skapat många små applikationer för Android och hans jRemote-applikation (det är en kontroller för de populära jDownloader PC-program) är ett perfekt exempel på hur man använder layouter för att skapa en app som ser bra ut på både telefonen och en surfplatta. Det maximerar användningen av enhetsskärmen och ger dig den information du letar efter exakt hur du förväntar dig det.

Att följa designriktlinjerna är ganska enkelt, så länge du håller dig till dem från början. Att utveckla en hel app och sedan i slutet gå tillbaka och försöka implementera fragment / tablettlayout etc kommer att bli slöseri med tid, ansträngning och frustration. Men om du planerar din app, utveckla med hjälp av fragment från början och skapa dina resurser för alla rätt dpi skopor, det gör att du utvecklar en lek och du behöver verkligen inte spendera mycket tid på att tänka på riktlinjerna på Allt. Och om du fastnar är designdokumenten bara ett klick bort. De är en stor resurs.

Det frustrerar mig verkligen att så många enheter inte har surfplattlayouter. Om din app är byggd med fragment kan du lägga till en surfplattelayout på 30 minuter. Ärligt talat är det så enkelt.

Jag tror att för många utvecklare har de inte surfplattor att testa på, och det kan vara ont att använda emulatorn. Men de nya ADT-verktygen som just släppts gör det mycket lättare. Multikonfigurationsvyn i layoutredigeraren innebär att du kan se hur din layout ser ut på 5-6 olika skärmstorlekar samtidigt. Och det är snabbt. Naturligtvis kommer du fortfarande att behöva testa på en emulator / enhet så småningom, men det påskyndar definitivt arbetsflödet.

jDownloader är ett praktiskt program att använda på skrivbordet, och jRemote ser ut som ett underbart sätt att kontrollera det. Om inget annat, ladda ner den från Google Play och titta bara för att se hur en app kan vara enkel och vacker samtidigt.

Vi hörde från många andra utvecklare som ganska mycket säger samma saker. Vi har bara lite utrymme här för att lista ut dem alla. Kärnan i allt är att om du planerar framåt fungerar riktlinjerna för Android-utvecklare verkligen i de flesta fall. Vi är glada att höra det och kommer att fortsätta att njuta av fantastiska appar och stödja hårt arbetande utvecklare.