Att hantera "fragmentering": utvecklare låter av på stöd för flera skärmar

Android körs på olika enheter, vilket innebär att det också körs på olika skärmstorlekar och upplösningar. Många människor kallar detta "fragmentering". Tänk inte 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 det etiketten "fragmentering".

Det finns olika sätt att ta itu med problemen som uppstår när du använder skärmar med olika storlekar och tätheter. Apple har separata listor för appar som är designade för iPhone kontra iPad. Microsoft skapar ett nytt ekosystem för sina 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åligt 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. Allt är inbyggt, men det finns några saker som utvecklare måste 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. Droid-DNA: n har en skärm med högre upplösning än Motorola XOOM-surfplatta, men vi vill inte se en surfplattlayout för appar på skärmen med telefonstorlek.

En utvecklare måste tillhandahålla tillgångar (bilder) som är tillräckligt höga för att se skarpa på hög upplösning (bortsett från vanvittigt hög upplösning) och se till att använda densitetsoberoende pixelenheter när de utformar sin 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 är gjort för dig när du kodar en app. Allt utvecklaren behöver göra är att göra rätt deklarationer och tillhandahålla rätt tillgångar för att stödja alla storlekar (både fysisk och upplösning) eller layout. Till och med flera layout-appar 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 praktisk är det? Vi frågade några utvecklare om det, se vad de hade att säga efter pausen.

Mer: Googles webbplats för Android-utvecklare.

Vi ställde en handfull utvecklare (både stora och små) ett par 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 som du har sett eller delar som Google inte har täckt?
• Hur påverkade detta utvecklingen tid och kostnader, om alls?
• Något mer om det ämne du vill dela med?

Jag försökte göra frågorna så neutrala som möjligt så att vi inte går in på detta med någon partiskhet på plats. Om du är osäker frågar du de människor som känner, eller hur? Jag har gjort min rättvisa andel programmering, men kodning i Java och byggande 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 kan tänka mig att ett stort antal av er är som jag och inte känner till komplikationerna med att bygga Android-appar. Vi ser bara vad Android-utvecklarna säger, och de gör det låter lätt. För dem är det antagligen - de har skrivit det här från grunden sedan 2007. Låt oss se vad folk 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 bra exempel på oberoende utvecklare med en passion för Android som har fått ut några fantastiska applikationer.

Att följa riktlinjerna är ganska svårt, särskilt om du vill ha en smal app men människor vill ha kompatibilitet med ryggen. En av de mest irriterande sakerna är att se hur något ser ut på d.android.com/design men ingenting om hur man faktiskt gör det.

En svag punkt är uppfriskande när du fysiskt inte kan använda GCM på grund av Twitter och du inte vill använda PtR. Dessutom utgör Googles appar sina egna riktlinjer. Ta till exempel bildrutan, 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 det, 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 kommer snart att öppna källkod (yay!), Och du kan hitta själva appen i Google Play. Här hittar du också alla Joe-appar (det finns några juveler).

Christophe Versieux - BeTrains - SNCB Belgien; HoloEverywhere

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 tågschema-app för belgiska rails) är det värt att installera bara för att se hur väl det är gjort. Folk i Västeuropa vet säkert om den här.

Dessutom har han samutvecklat HoloEverywhere, ett bibliotek som andra utvecklare kan använda för att bygga Holo-stilapplikationer 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.

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

Jag minns en kund som ville att jag skulle lägga flikar på botten av skärmen, iPhone-knappar överallt, iPhone-stil växla 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. Kunderna och företagen behöver bara vara medvetna om dessa riktlinjer, tror jag starkt.

Bibliotek som ActionBarSherlock, HoloEverywhere (min skapelse), UnifiedPreferences och SlidingMenu är verkligen enkla att använda och ger i några få kodrader en fantastisk användarupplevelse.

Tid och kostnad minimeras som sagt genom att följa Googles riktlinjer. Fragment och layoutmappar är riktigt enkla att använda (och viktigare att återanvända): en surfplatta-app tar bara en bit kod från telefonlayouten och ingenting måste skrivas om. Små förändringar i telefonappen avspeglas omedelbart i surfplatta-appen, eftersom samma fragment används.

Några fantastiska projekt skapas av gemenskapen, 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 titta och Android-utveckling kommer att vara lätt för dem!

Du kan hitta BeTrains på Google Play och du vill titta 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 troligen en särskild budget för design på både deras webbplats och deras applikationer. Det är också ett företag som jag köper från regelbundet, men detta hade ingen betydelse och Matthew var inte medveten om att jag är en frekvent kund när han gjorde frivilligt arbete.

På Zappos, eftersom vi är en återförsäljare, måste vi först och främst hålla oss till vårt eget märke. Späckiga, roliga och lite utanför väggen. Som sagt, båda av oss är starka troende i riktlinjerna för Android-design - och allt vi gör i UI är hämtat från andan i dessa regler. För ett år sedan var vår app mest en iOS-port från hur den såg ut och fungerade. Idag är det (tror jag) en pärla av 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 slutar alla - 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 funnit att de flesta vanliga "nya" open source-bibliotek som vi har använt har hamnat som en del av riktlinjerna (skjutmeny, crouton).

Riktlinjerna bör aldrig vara en hämmare. Vissa saker - övergripande navigering - måste vara konsekvent 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ÅRA APP - så vi kan inte bara göra baslinjen holo-tema.

I år har vi i princip börjat från en grundläggande omskrivning av vår app för att arbeta med fragment. Under de senaste 6 månaderna har vi arbetat hårt för att lägga till 7 "surfplatterstö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 arbetade heltid på vår app sedan augusti eller så, innan det var en person på heltid.

Kort sagt är, tror jag, att Android-designriktlinjerna 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 stor 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 påstående. Kolla in deras Android-app från Google Play.

Josh Burton - jRemote

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

Att följa designriktlinjerna är ganska rakt fram, 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 / surfplattor etc. kommer att bli slöseri med tid, ansträngning och frustration. Men om du planerar din app, utvecklar med hjälp av fragment från början och skapar dina resurser för alla rätt dpi-hinkar, gör det att utveckla en bris, och du behöver verkligen inte spendera mycket tid på att tänka på riktlinjerna alls. 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 surfplattor. Om din app är byggd med fragment kan du lägga till en surfplatta på 30 minuter. Ärligt talat, det är så lätt.

Jag tror för många utvecklare att de inte har surfplattor att testa på, och att använda emulatorn kan vara ont. Men de nya ADT-verktygen som just har släppts gör det mycket lättare. Multikonfigurationsvyn i layoutredigeraren betyder 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 det från Google Play och titta bara för att se hur en app kan vara enkel och vacker på samma gång.

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