Takling af 'fragmentering': udviklere lyder fra på understøttelse af flere skærme

Android kører på en række enheder, hvilket betyder, at den også kører på en række skærmstørrelser og opløsninger. Mange mennesker kalder dette "fragmentering". Husk ikke, at de har brugt produkter designet og udviklet på samme måde i årevis på deres desktop. Tilsyneladende, hvis alt ikke er nøjagtigt det samme, får det "fragmentering" -mærket.

Der er forskellige måder at tackle de problemer, der opstår, når du bruger skærme med forskellige størrelser og densiteter. Apple har separate lister til apps designet til iPhone versus iPad. Microsoft opretter et nyt økosystem til sine storskærmsenheder. Android giver en måde for udviklere at få den samme app til at fungere forskelligt på forskellige skærme. Der er godt og dårligt ved hver metode, men vi vil fokusere på Android her.

I Android kan applikationer justere layoutet til forskellige størrelsesskærme såvel som opløsning. Alt dette er indbygget, men der er et par ting, som udviklere har brug for at erklære i deres kode for at appen skal se godt ud. Det skal man huske på, hvordan skærmstørrelse og densitet vil ændre appens udseende. Droid-DNA'et har en skærm med højere opløsning end Motorola XOOM-tablet, men vi ønsker ikke at se et tabletlayout til apps på skærmen med telefonstørrelse.

En udvikler skal levere aktiver (billeder), der er høj nok kvalitet til at se skarpe på høj opløsning (husk sindssygt høj opløsning), og sørg for at bruge densitetsuafhængige pixelenheder, når de designer deres layout. Det er det, der forhindrer, at ting som knapper og andre kontrolelementer er virkelig store på skærme med lav tæthed som Galaxy S2, eller fra at være rigtig små på skærme med høj densitet som DNA.

Det lyder kompliceret, men det meste af dette er gjort for dig, når du koder en app. Alt, hvad udvikleren skal gøre, er at afgive de rigtige erklæringer og give de rigtige aktiver til at understøtte enhver størrelse (både fysisk og opløsning) eller layout. Selv flere layout-apps som Google+-appen bruger den samme kode til at dække enhver tænkelig skærm.

Vi prøver ikke at bedømme udviklere her. Det er svært at skrive apps. Android-udviklerne har forkynt alt dette siden frigivelsen af ​​Gingerbread, men hvor praktisk er det? Vi spurgte et par udviklere om det, se hvad de havde at sige efter pausen.

Mere: Googles Android-udviklerwebsted.

Vi stillede en håndfuld udviklere (både store og små) et par grundlæggende spørgsmål om emnet.

• Hvor vanskeligt er det at overholde retningslinjerne?
• Det ser let ud på papiret, men er der nogen specielle problemer, du har set, eller dele, som Google ikke har dækket?
• Hvordan påvirkede dette udviklingstid og omkostninger, hvis overhovedet?
• Noget mere om det emne, du gerne vil dele?

Jeg forsøgte at gøre spørgsmålene så neutrale som muligt, så vi ikke går ind på dette med nogle bias på plads. Når du er i tvivl, spørger du de mennesker, der kender, ikke? Jeg har lavet min retmæssige del af programmeringen, men kodning i Java og opbygning af Android-apps er meget forskellig fra at skrive kode i C eller maskinkode eller endda Perl. Der er nuancer, som jeg ikke forstår, selvom jeg får de generelle metoder til at oprette en app.

Jeg kan forestille mig, at et godt antal af jer er som mig og kender ikke de forviklinger, der er ved at bygge Android-apps. Vi ser kun, hvad Android-udviklerne siger, og de gør det lyder let. For dem er det sandsynligvis - de har skrevet dette fra grunden siden 2007. Lad os se, hvad de mennesker, der har været i stand til at følge dem, har at sige.

Joe Simpson (@kennydude) - Boid

Joe er medlem af Team Boid og udgiver også applikationer på egen hånd. Han (og resten af ​​sit team) er et godt eksempel på uafhængige udviklere med en lidenskab for Android, der har bragt nogle fantastiske applikationer ud.

Det er ret vanskeligt at følge retningslinjerne, især hvis du vil have en mager app, men folk vil have back-kompatibilitet. En af de mest irriterende ting er at se, hvordan noget ser ud på d.android.com/design, men intet om, hvordan man rent faktisk gør det.

Et svagt punkt er forfriskende, når du fysisk ikke kan bruge GCM på grund af Twitter, og du ikke ønsker at bruge PtR. Googles apps udgør også deres egne retningslinjer. Tag eksempelvis indsprøjtningsruden, Google+ gør det anderledes end YouTube (selvom jeg ved, at supportbiblioteket forhåbentlig vil løse dette).

Du kan også komme til et punkt, og der er ingen dokumentation for noget (EdgeEffect for eksempel).

Jeg er studerende, så omkostninger er noget, jeg ser det ikke ud, og ja det tager tid, men dine brugere vil elske dig. Grundlæggende er Live Shows (ADiA, App Clinic, Office Hours) et must (desværre), selvom de ikke kan tilbyde feedback om Googles apps.

Boid er snart ved at åbne open source (yay!), Og du kan finde selve appen i Google Play. Du finder også alle Joe's apps (der er nogle juveler der) lige her.

Christophe Versieux - BeTrains - SNCB Belgien; HoloEverywhere

Christophe har bygget adskillige Android-applikationer, herunder BeTrains - SNCB Belguim - en app med et smukt layout, der viser, hvad der kan gøres med en velbygget applikation. Mens de fleste i USA aldrig vil bruge den (det er en togskema-app til belgiske skinner), er det værd at installere bare for at se, hvor godt det er gjort. Folk i Vesteuropa kender bestemt til denne.

Derudover har han co-udviklet HoloEverywhere, et bibliotek, som andre udviklere kan bruge til at bygge Holo-stil applikationer til Android 2.1 og nyere. Med mange telefoner, der stadig kører Gingerbread, er dette en rigtig god fornøjelse for udviklere, der ønsker at holde deres apps ser aktuelle.

Det er slet ikke svært. Helt seriøst. Den svære del kommer, når kunden beder om at komme væk fra disse retningslinjer!

Jeg kan huske en kunde, der ville have mig til at lægge faner i bunden af ​​skærmen, iPhone-knapper overalt, iPhone-stil skifte og dette projekt var virkelig svært at opnå, og jeg mistede virkelig en masse tid og penge på det.

Jeg var virkelig vred på ham, da han spurgte om alle disse dumme ting, og han troede bare, at jeg var en doven udvikler.

Jeg har nu en masse kontakt med ham, og vi omskriver totalt hans app, opretter en fantastisk kode ved at fjerne alle disse unyttige funktioner og oprette en "ren" Android-app. Kunder og virksomheder skal bare være opmærksomme på disse retningslinjer, jeg er overbevist om.

Biblioteker som ActionBarSherlock, HoloEverywhere (min oprettelse), UnifiedPreferences og SlidingMenu er virkelig nemme at bruge og giver i nogle få kodelinjer en fantastisk brugeroplevelse.

Tid og omkostninger minimeres som sagt ved at følge Googles retningslinjer. Fragmenter og layoutmapper er virkelig nemme at bruge (og mere vigtigt at genbruge): en tablet-app skal bare hente stykke kode fra telefonlayoutet, og intet må skrives om. Små ændringer i telefonappen afspejles straks i tabletapp, da den samme fragment bruges.

Nogle fantastiske projekter er skabt af samfundet, ikke altid af Google. Nogle mennesker, meget aktive på Google+ som Roman Nurik (Google), Reto Meier (Google) Juhani Lehtimäki, Jake Wharton, Taylor Ling,.. (jeg er altid bange for at glemme vigtige mennesker) er meget lærerige. Udviklere skal bare vide, hvor de skal kigge, og Android-udvikling vil være let for dem!

Du kan finde BeTrains på Google Play, og du vil tage et kig på HoloEverywhere, hvis du er interesseret i Android-udvikling.

Matthew Runo - Zappos

I modsætning til nogle af de mindre uafhængige udviklere, vi talte med, hørte vi også fra Matthew på Zappos. Zappos er et web-detailfirma og har sandsynligvis et dedikeret budget for design på både deres websted og deres applikationer. Det er også et firma, som jeg køber regelmæssigt fra, men dette havde ingen betydning, og Matthew var ikke klar over, at jeg er en hyppig kunde, da han meldte sig frivilligt.

Hos Zappos, da vi er forhandler, er vi først og fremmest nødt til at holde os til vores eget brand. Skøre, sjovt og lidt fra væggen. Når det er sagt, er begge af os stærke troende på retningslinjerne for Android-design - og alt hvad vi gør i UI er taget fra ånden i disse regler. For et år siden var vores app for det meste en iOS-port ud fra, hvordan den så ud og fungerede. I dag er det (tror jeg) en perle af hvad du kan gøre i Android. Vi overholder retningslinjerne, når det er muligt - og vores designere arbejder ud fra dem som udgangspunkt.

Designretningslinjerne er ikke alle være alle og slutter alt sammen - til sidst er de bare der for at prøve at skubbe design af Android-apps, så de er mere ensartede. Vi har fundet ud af, at de fleste af de almindelige "nye" open source-biblioteker, som vi har brugt, er havnet som en del af retningslinjerne (skyde-menu, crouton).

Retningslinjerne skal aldrig være en tilbageholdelse. Visse ting - samlet navigation - skal være ensartet, så din app "bare fungerer". Alt andet - start ved retningslinjerne og kør med dit design. Vi ønsker, at vores app skal være VORES APP - så vi kan ikke bare gøre det grundlæggende holo-tema.

I år er vi dybest set startet fra en grundlæggende omskrivning af vores app til at arbejde med fragmenter. I de sidste 6 måneder har vi arbejdet hårdt på at tilføje 7 "tabletstøtte, og vi arbejder i øjeblikket på 10" support. Den sværeste ting at gøre er at teste på enheder, men vi har et fantastisk QA-team, der hjælper med det. Vi har haft 2 personer, der arbejdede på fuld tid på vores app siden august eller deromkring, før det var en person på fuld tid.

I bund og grund er, at Android-designretningslinjerne hjælper os med at strømline vores proces - og dermed reducere omkostningerne. Lad os indse det, de fleste designere fra iOS - så det at have en stor ressource som design.android.com er en vidunderlig hjælp til at få dem sparket i Android-økosystemet.

Jeg kan sige, at Zappos 'designvalg fungerer godt, og min kone har et skab fuld af tøj, punge og støvler, der styrker min påstand. Tjek deres Android-app fra Google Play.

Josh Burton - jRemote

Josh har skrevet mange små applikationer til Android, og hans jRemote-applikation (det er en controller til det populære jDownloader-pc-program) er et perfekt eksempel på, hvordan man bruger layout til at oprette en app, der ser godt ud på både telefonen og en tablet. Det maksimerer brugen af ​​enhedsskærmen og giver dig de oplysninger, du leder efter, nøjagtigt, hvordan du ville forvente det.

At overholde designretningslinjerne er ret ligetil, så længe du holder dig til dem fra start. At udvikle en hel app og derefter i slutningen gå tilbage og prøve at implementere fragmenter / tabletlayouts osv. Vil være spild af tid, kræfter og frustration. Men hvis du planlægger din app, udvikler ved hjælp af fragmenter fra starten og skaber dine ressourcer til alle de rigtige dpi-spande, gør det at udvikle sig en leg, og du behøver virkelig ikke bruge meget tid på at overveje retningslinjerne overhovedet. Og hvis du sidder fast, er designdokumenterne kun et klik væk. De er en stor ressource.

Det frustrerer mig virkelig, at så mange enheder ikke har tabletlayouts. Hvis din app er bygget ved hjælp af fragmenter, kan du tilføje et tabletlayout på 30 minutter. Helt ærligt er det så let.

Jeg tror for mange udviklere, at de ikke har tablet-enheder at teste på, og at bruge emulatoren kan være en smerte. Men de nye ADT-værktøjer, der lige er frigivet, gør det meget lettere. Multikonfigurationsvisningen i layouteditoren betyder, at du kan se, hvordan dit layout ser ud på 5-6 forskellige skærmstørrelser på én gang. Og det er hurtigt. Selvfølgelig skal du stadig teste på en emulator / enhed til sidst, men det fremskynder bestemt arbejdsgangen.

jDownloader er et praktisk program, der skal bruges på dit skrivebord, og jRemote ligner en vidunderlig måde at kontrollere det på. Hvis intet andet, skal du downloade den fra Google Play og kigge bare for at se, hvordan en app kan være enkel og smuk på samme tid.

Vi har hørt fra mange andre udviklere, der stort set siger de samme ting. Vi er lige ude af plads til at liste dem alle sammen. Kernen i det hele er, at hvis du planlægger fremad, fungerer Android-udviklerens retningslinjer virkelig i de fleste tilfælde. Vi er glade for at høre det og vil fortsat nyde gode apps og støtte hårdtarbejdende udviklere.