Aanpak van 'fragmentatie': ontwikkelaars klinken af ​​op ondersteuning van meerdere schermen

Android werkt op verschillende apparaten, wat betekent dat het ook op verschillende schermformaten en resoluties draait. Veel mensen noemen dit 'fragmentatie'. Let niet op het feit dat ze al jaren producten op dezelfde manier gebruiken en ontwerpen die op dezelfde manier zijn ontwikkeld. Blijkbaar krijgt het alles als het niet precies hetzelfde is.

Er zijn verschillende manieren om de problemen aan te pakken die zich voordoen wanneer u schermen met verschillende formaten en dichtheden gebruikt. Apple heeft afzonderlijke lijsten voor apps die zijn ontworpen voor de iPhone versus de iPad. Microsoft maakt een nieuw ecosysteem voor zijn apparaten met een groot scherm. Android biedt ontwikkelaars een manier om dezelfde app anders te laten werken voor verschillende schermen. Er is goed en slecht over elke methode, maar we gaan ons hier concentreren op Android.

In Android kunnen applicaties de lay-out aanpassen voor schermen van verschillende grootte en de resolutie. Dit is allemaal ingebouwd, maar er zijn een paar dingen die ontwikkelaars in hun code moeten aangeven om de app er goed uit te laten zien. Het ding om in gedachten te houden is hoe schermgrootte en dichtheid het uiterlijk van de app zullen veranderen. Het Droid-DNA heeft een scherm met een hogere resolutie dan de Motorola XOOM-tablet, maar we willen geen tabletindeling voor apps zien op het scherm van telefoonformaat.

Een ontwikkelaar moet elementen (afbeeldingen) bieden die hoog genoeg zijn om scherp te zijn met een hoge resolutie (laat staan ​​waanzinnig hoge resolutie), en zorg ervoor dat u dichtheid-onafhankelijke pixeleenheden gebruikt bij het ontwerpen van hun lay-out. Dit zorgt ervoor dat dingen als knoppen en andere bedieningselementen niet echt groot zijn op schermen met een lage dichtheid zoals de Galaxy S2, of dat ze erg klein zijn op schermen met een hoge dichtheid zoals het DNA.

Het klinkt ingewikkeld, maar de meeste dingen worden voor je gedaan bij het coderen van een app. Het enige dat de ontwikkelaar hoeft te doen, is de juiste verklaringen afleggen en de juiste middelen bieden voor elke grootte (zowel fysiek als resolutie) of lay-out. Zelfs meerdere lay-out-apps zoals de Google+ app gebruiken dezelfde code voor elk denkbaar scherm.

We proberen ontwikkelaars hier niet te beoordelen. Apps schrijven is moeilijk. De Android-ontwikkelaars prediken dit allemaal sinds de release van Gingerbread, maar hoe praktisch is het? We hebben er een paar ontwikkelaars naar gevraagd, kijk wat ze na de pauze te zeggen hadden.

Meer: Google's Android-ontwikkelaarssite.

We hebben een handvol ontwikkelaars (zowel grote als kleine) een paar basisvragen over het onderwerp gesteld.

• Hoe moeilijk is het om zich aan de richtlijnen te houden?
• Het ziet er op papier gemakkelijk uit, maar zijn er speciale problemen die je hebt gezien of delen die Google niet heeft behandeld?
• Welke invloed had dit op de ontwikkeltijd en -kosten, of helemaal niet?
• Iets verder over het onderwerp dat u wilt delen?

Ik heb geprobeerd de vragen zo neutraal mogelijk te maken, zodat we hier niet op ingaan met wat vooroordeel. Bij twijfel vraag je het aan de mensen die het weten, toch? Ik heb behoorlijk wat programmeerwerk gedaan, maar coderen in Java en het bouwen van Android-apps is heel anders dan het schrijven van code in C of machinecode, of zelfs Perl. Er zijn nuances die ik niet begrijp, zelfs als ik de algemene methoden krijg om een ​​app te bouwen.

Ik stel me voor dat een groot aantal van jullie net als ik zijn en de ingewikkeldheden van het bouwen van Android-apps niet kennen. We zien alleen wat de Android-ontwikkelaars zeggen en ze maken het eenvoudig. Voor hen is het waarschijnlijk - ze schrijven dit soort dingen vanaf 2007 helemaal opnieuw. Laten we eens kijken wat de mensen die hen hebben kunnen volgen, te zeggen hebben.

Joe Simpson (@kennydude) - Boid

Joe is lid van Team Boid en publiceert ook zelfstandig toepassingen. Hij (en de rest van zijn team) zijn een geweldig voorbeeld van onafhankelijke ontwikkelaars met een passie voor Android die een aantal geweldige toepassingen hebben ontwikkeld.

Het volgen van de richtlijnen is vrij moeilijk, vooral als je een slanke app wilt, maar mensen willen back-compatibiliteit. Een van de meest irritante dingen is zien hoe iets eruit ziet op d.android.com/design maar niets over hoe dat daadwerkelijk te doen.

Een zwak punt is verfrissend wanneer je fysiek geen GCM kunt gebruiken vanwege Twitter en je geen PtR wilt gebruiken. Ook maken de apps van Google hun eigen richtlijnen. Neem bijvoorbeeld het schuifvenster, Google+ doet het anders dan YouTube (hoewel ik weet dat de ondersteuningsbibliotheek dit hopelijk gaat regelen).

U kunt ook een punt bereiken en er is geen documentatie over iets (bijvoorbeeld EdgeEffect).

Ik ben een student, dus de kosten zijn iets waar ik er niet uit zie, en ja het kost tijd, maar je gebruikers zullen van je houden. Kortom, de Live-shows (ADiA, App Clinic, Office Hours) zijn een must (helaas), hoewel ze geen feedback kunnen geven over de apps van Google.

Boid gaat binnenkort open-source (ja!), En je kunt de app zelf vinden in Google Play. Je vindt hier ook alle apps van Joe (er zijn een paar juwelen).

Christophe Versieux - BeTrains - NMBS België; HoloEverywhere

Christophe heeft talloze Android-applicaties gebouwd, waaronder BeTrains - NMBS België - een app met een prachtige lay-out die laat zien wat er met een goed gebouwde applicatie kan worden gedaan. Hoewel de meeste in de VS het nooit zullen gebruiken (het is een treinplanningsapp voor Belgische rails), is het de moeite waard om te installeren, alleen om te zien hoe goed het is gedaan. De mensen in West-Europa weten dit zeker.

Daarnaast heeft hij HoloEverywhere mede ontwikkeld, een bibliotheek die andere ontwikkelaars kunnen gebruiken om applicaties in Holo-stijl voor Android 2.1 en hoger te bouwen. Omdat veel telefoons nog steeds Gingerbread gebruiken, is dit een echte traktatie voor ontwikkelaars die hun apps actueel willen houden.

Het is helemaal niet moeilijk. Ernstig. Het moeilijke deel komt wanneer de klant vraagt ​​om weg te komen van die richtlijnen!

Ik herinner me een klant die wilde dat ik tabbladen op de onderkant van het scherm plaatste, overal iPhone-knoppen, iPhone-stijl omschakelen en dit project was echt moeilijk te bereiken en ik verloor er echt veel tijd en geld aan.

Ik was echt boos op hem toen hij al die stomme dingen vroeg, en hij dacht gewoon dat ik een luie ontwikkelaar was.

Ik heb nu veel contact met hem en we herschrijven zijn app volledig, maken geweldige code door al deze nutteloze functies te verwijderen en een 'pure' Android-app te maken. De klanten en bedrijven moeten zich alleen bewust zijn van die richtlijnen, geloof ik sterk.

Bibliotheken zoals ActionBarSherlock, HoloEverywhere (mijn creatie), UnifiedPreferences en SlidingMenu zijn echt gemakkelijk te gebruiken en bieden in een paar regels code een geweldige gebruikerservaring.

Tijd en kosten worden, zoals gezegd, tot een minimum beperkt door de richtlijnen van Google te volgen. Fragmenten en lay-outmappen zijn heel gemakkelijk te gebruiken (en belangrijker om opnieuw te gebruiken): een tablet-app haalt gewoon een stukje code uit de telefoonlay-out en er mag niets worden herschreven. Kleine wijzigingen in de telefoon-app worden onmiddellijk weerspiegeld in de tablet-app, omdat hetzelfde fragment wordt gebruikt.

Sommige geweldige projecten worden gemaakt door de community, niet altijd door Google. Sommige mensen, zeer actief op Google+, zoals Roman Nurik (Google), Reto Meier (Google) Juhani Lehtimäki, Jake Wharton, Taylor Ling,.. (ik ben altijd bang om belangrijke mensen te vergeten) zijn zeer leerzaam. Ontwikkelaars moeten gewoon weten waar ze moeten kijken en Android-ontwikkeling is eenvoudig voor hen!

Je kunt BeTrains vinden op Google Play en je wilt HoloEverywhere eens bekijken als je geïnteresseerd bent in Android-ontwikkeling.

Matthew Runo - Zappos

In tegenstelling tot enkele kleinere onafhankelijke ontwikkelaars met wie we hebben gesproken, hoorden we ook van Matthew op Zappos. Zappos is een webwinkel en heeft waarschijnlijk een specifiek budget voor ontwerp op zowel hun website als hun applicaties. Het is ook een bedrijf waar ik regelmatig bij koop, maar dit had geen invloed en Matthew wist niet dat ik een vaste klant ben toen hij zich aanmeldde.

Omdat we een retailer zijn, moeten we bij Zappos in de eerste plaats bij ons eigen merk blijven. Wacky, leuk en een beetje van de muur. Dat gezegd hebbende, zijn we allebei sterk van mening in de ontwerprichtlijnen van Android - en alles wat we in de gebruikersinterface doen, is ontleend aan de geest van die regels. Een jaar geleden was onze app vooral een iOS-poort van hoe het eruit zag en werkte. Tegenwoordig is het (denk ik) een juweeltje van wat je kunt doen in Android. We houden ons aan de richtlijnen waar mogelijk - en onze ontwerpers werken er vanuit als uitgangspunt.

De ontwerprichtlijnen zijn niet alles - uiteindelijk zijn ze er gewoon om te proberen het ontwerp van Android-apps mee te duwen zodat ze consistenter zijn. We hebben geconstateerd dat de meeste algemene "nieuwe" open source-bibliotheken die we hebben gebruikt, onderdeel zijn geworden van de richtlijnen (schuifmenu, crouton).

De richtlijnen mogen nooit een rem zijn. Bepaalde dingen - algemene navigatie - moeten consistent zijn, zodat uw app 'gewoon werkt'. Al het andere - begin bij de richtlijnen en voer uw ontwerp uit. We willen dat onze app ONZE APP is - dus we kunnen niet alleen het baseline holo-thema doen.

Dit jaar zijn we eigenlijk begonnen met een grondige herschrijving van onze app om met fragmenten te werken. In de afgelopen 6 maanden hebben we hard gewerkt om 7 "tabletondersteuning toe te voegen, en we werken momenteel aan 10" ondersteuning. Het moeilijkste om te doen is testen op apparaten, maar we hebben een geweldig QA-team dat daarbij helpt. We hebben sinds augustus ongeveer 2 mensen fulltime aan onze app gewerkt, daarvoor was het 1 fulltime persoon.

Het komt erop neer dat de ontwerprichtlijnen van Android ons helpen ons proces te stroomlijnen - en daarmee de kosten te verlagen. Laten we eerlijk zijn, de meeste ontwerpers uit iOS - dus het hebben van een geweldige bron zoals design.android.com is een geweldige hulp om ze op weg te helpen in het Android-ecosysteem.

Ik kan zeggen dat de ontwerpkeuzes van Zappos goed werken en mijn vrouw heeft een kast vol kleren, portemonnees en laarzen die mijn claim versterken. Bekijk hun Android-app van Google Play.

Josh Burton - jRemote

Josh heeft verschillende kleine applicaties voor Android geschreven, en zijn jRemote-applicatie (het is een controller voor het populaire jDownloader pc-programma) is een perfect voorbeeld van het gebruik van lay-outs om een ​​app te maken die er geweldig uitziet op zowel de telefoon als een tablet. Het maximaliseert het gebruik van het apparaatscherm en geeft u de informatie die u zoekt, precies zoals u het zou verwachten.

Het volgen van de ontwerprichtlijnen is vrij eenvoudig, als u zich er maar meteen aan houdt. Het ontwikkelen van een hele app en uiteindelijk teruggaan en proberen fragmenten / tabletlay-outs, enz. Te implementeren, wordt verspilling van tijd, moeite en frustratie. Maar als u uw app plant, ontwikkelt met behulp van fragmenten vanaf het begin en uw bronnen voor alle juiste dpi-emmers maakt, wordt het ontwikkelen van een briesje eenvoudiger en hoeft u echt niet veel tijd te besteden aan het nadenken over de richtlijnen. En als u vastloopt, zijn de ontwerpdocumenten slechts één klik verwijderd. Ze zijn een geweldige bron.

Het frustreert me echt dat zoveel apparaten geen tabletindelingen hebben. Als uw app is gebouwd met fragmenten, kunt u binnen 30 minuten een tabletindeling toevoegen. Eerlijk gezegd is het zo gemakkelijk.

Ik denk dat veel ontwikkelaars geen tablets hebben om op te testen en het gebruik van de emulator kan lastig zijn. Maar de nieuwe ADT-tools die net zijn uitgebracht, maken het een stuk eenvoudiger. De multi-configuratieweergave in de lay-outeditor betekent dat u tegelijkertijd kunt zien hoe uw lay-out eruit ziet op 5-6 verschillende schermformaten. En het is snel. Natuurlijk moet je uiteindelijk nog steeds op een emulator / apparaat testen, maar het versnelt zeker de workflow.

jDownloader is een handig programma om op uw bureaublad te gebruiken en jRemote ziet eruit als een prachtige manier om het te bedienen. Als het niets anders is, download het van Google Play en kijk gewoon hoe een app tegelijkertijd eenvoudig en mooi kan zijn.

We hebben van veel andere ontwikkelaars gehoord die vrijwel dezelfde dingen zeggen. We hebben hier net geen ruimte om ze allemaal op te sommen. De kern van dit alles is dat als je vooruit plant, de richtlijnen voor Android-ontwikkelaars in de meeste gevallen echt werken. We zijn blij het te horen en zullen blijven genieten van geweldige apps en ondersteuning van hardwerkende ontwikkelaars.