Android krijgt 'fill to screen'-optie voor apps die niet schalen

Google heeft voor Android Honeycomb een nieuwe functie ontwikkeld waarmee applicaties die niet voor grote schermen zijn gemaakt, fullscreen kunnen draaien. De functie wordt deel van een nog te verschijnen versie van het besturingssysteem.

De ontwikkelaars van het tabletbesturingssysteem deden de nieuwe feature op hun blog uit de doeken. Applicaties die volledig volgens de door Google opgestelde designregels zijn gemaakt, draaien zonder problemen op tablets, maar er zijn ook apps die in hun originele resolutie worden getoond met rondom zwarte ruimte.

Om dat tegen te gaan, krijgt Android Honeycomb in de toekomst de mogelijkheid om die applicaties op te rekken, zodat ze het volledige scherm vullen, net zoals bij de iPad gebeurt. Het nadeel van deze methode is dat er pixelation optreedt, vanwege de lage oorspronkelijke resolutie van de app. Daarom blijft Google ontwikkelaars aanraden om de interface van hun applicaties volgens de officiële standaarden te ontwikkelen. Zelfs applicaties zonder speciale tablet-lay-out kunnen dan fullscreen weergegeven worden zonder scherpteverlies.

Reacties (80)

[Eli3l]

Je zou toch denken dat je als dev toch meteen begint met ontwerpen volgens de designregels van google? Bespaart je een hoop moeite...

[Anoniem: 80466]

Misschien zijn die designregels bij de introducite van een tablet versie van androd nogal veranderd?

[Finraziel]

Nee, veel devs zijn gewoon gewend om met pixels te werken en willen niet overschakelen naar schaalbaar werken. Komt ook doordat veel apps nou niet echt door professionals gebouwd zijn (niks ten nadele daarvan, maar je merkt het in dit soort dingen). Als je in je apps alles hardcode op aantallen pixels, ja dan werkt het niet meer goed als de resolutie verandert, maar dat is dus niet de aanbevolen methode.

[Stukfruit]

Klopt deels. De aanbevolen methode is het gebruik van layouts of, wanneer dit niet mogelijk is (bv. in een spelletje of eigen views) het gebruik van punten ipv pixels. Dit staat ook allemaal netjes omschreven in de documentatie.

Voor degenen onder ons die dat TL;DR vinden: een punt is beter dan een pixel omdat een punt meeschaalt met het scherm. Zo is een punt op een iPhone4 bijvoorbeeld 4 pixels groot (2px breed en hoog), tegenover 1 pixel op het scherm van een iPhone3(gs).

Ik gebruik hier de iPhone als voorbeeld vanwege de hardware, maar op bijvoorbeeld een HTC Desire gaat dit ook op. Een punt is op de schermen van deze apparaten 1.5 pixel breed en hoog.

Door punten ipv pixels te gebruiken zijn er drie grote voordelen:

• het is redelijk simpel in gebruik
• het schaalt mee met de grootte van het scherm
• het zorgt dat je nog steeds in "pixels" kan hardcoden

[killingdjef]

Een aantal tips voor android developers:

Gebruik bij:
pixels: dip i.p.v px
font: sp i.p.v p

Maak veelvuldig gebruik van fill_parent waarbij je bij de verschillende componenten speelt met de layout weight

Probeer tekst altijd zelf te genereren. In mijn game Titan Turret programmeer ik zelf een stroke i.p.v. dat ik tekstuele images gebruik met stroke .

Op 9 van de 10 schermen komt mijn layout goed uit de verf. De allerkleinste willen nog wel eens falen (320x200 .. oh come on!)


Je moet het trucje ff doorhebben maar dan valt het best mee om een layout te maken voor verschillende toestellen

[Anoniem: 37864]

Dat is leuk, maar door de grote verscheidenheid aan schermpjes op Android apparaten, is de afmeting in punten ook nog eens verschillend, dus als je alles in punten hardcoded, dan gaat het alsnog niet werken.

Het idee achter punten is dat als een letter 'a' bijvoorbeeld in 5 punten hoogte wordt opgegeven, hij op alle apparaten even groot is. Punten compenseren dus voor de pixeldichtheid van de schermen, niet voor de afmetingen.

[Stukfruit]

Klopt, het is beter bruikbaar voor objecten in oa. spellen en veel dingen in views (zoals ik al aangaf in de vorige reactie) dan voor dingen die altijd dezelfde fysieke grootte moeten hebben, zoals letters idd. Met Android kan je daarvoor altijd nog DisplayMetrics.scaledDensity gebruiken zodat letters in ieder geval meeschalen tot het niveau waarop de gebruiker (of fabrikant) dat wenst.

Als je custom views maakt moet je sowieso niet alleen maar afhankelijk zijn van punten trouwens. Een combinatie van punten en automatisch schalende layouts geeft imho de beste en netste resultaten.

[PrisonerOfPain]

Alleen is in de geschiedenis al gebleken dat dit idee compleet voorbij gaat aan developers. Visual Basic 6 en lager hadden het concept van Twips wat ook haast niemand correct gebruikte.

[Benjamin-]

De iPhone heeft daarin wel een groot voordeel tegenover Android, dat is doordat de iPhone 4 gewoon 4x de resolutie heeft als de voorgangers. Vergroten in dat geval is dan ook eigenlijk gewoon alles x4 doen.

Bij Android is dit enorm lastig, niet alleen zijn de resoluties erg verschillend, maar ook de aspect ratio's zijn niet vast, dit alles maakt het nou niet bepaald makkelijk.

Ik moet ook zeggen dat als ik Google had geweest dat ik 2 'eisen' in Android had gebouwd, 1 vaste aspect ratio en minimum systeem eisen waardoor een aantal van de enorm slechte toestellen nooit had kunnen uitkomen.

[Stukfruit]

Alles x4 doen is niet zo slim omdat je het dan tweedubbel zo groot maakt als op de 3GS
2x2 pixels == 4 pixels, maar niet langs de hele breedte of hoogte.

Sowieso is het niet zo verstandig om aan te nemen dat dit altijd hetzelfde blijft. Daarom zou je (afaik!) onder iOS eigenlijk ook de contentScaleFactor moeten gebruiken ipv aannemen dat het dubbel zo groot is omdat je op een iPhone4 zit en "retina" hebt (wat niet meer is dan marketingpraat).

Verschillende aspect ratio's is imho niet echt een probleem. Stel dat er bijvoorbeeld een deel van je interface is waar tekst in staat: die kan je verticaal laten uitrekken (qua grootte) waardoor je op langere beeldschermen iets meer van de tekst zal zien dan op kortere.
Je moet hierbij uiteraard wel de UI ontwerpen voor een korter scherm.

Het is niet zo moeilijk zodra je er een beetje je weg in hebt gevonden En daarom zei ik ook dat voor veel situaties een combi van punten en layouts de beste oplossing is.

[Reactie gewijzigd door Stukfruit op 24 juli 2024 19:01]

[Anoniem: 295700]

Het probleem is helaas niet zo simpel. Je wil vaak dat controls netjes onder elkaar blijven staan ook als de breedte varieert vanwege andere talen. Je hebt dan meer nodig dan een control die zijn eigen breedte aanpast; je moet controls kunnen groeperen en dan de groep als geheel schalen. Dat is wel even andere koek. En dan zijn er ook nog controls die standaard breedtes/hoogtes hebben zoals scroll-bars. Dan schaalt de ruimte die je voor de controls hebt niet lineair mee met de grootte van het scherm.

[Anoniem: 96523]

Hoewel het mogelijk is dat de designregels zijn gewijzigd (al zou ik niet weten welke), is het altijd verstandig geweest voor Android devs om geschaald te werken ipv met vaste maten.

Omdat Android op meerdere toestellen werkt, met verschillende schermgrootten (in tegenstelling tot iOS, welke er maar 2 heeft), moet je er altijd al rekening mee houden.

Veel devs hadden hier geen zin in, en maakte voor een aantal vaste maten hun app op, en eindigden dus met vaste pixels welke op tablets niet meer (goed) werken.

Google heeft vanaf het begin geadviseerd om met percentages te werken ipv pixels, juist om dit soort problemen te voorkomen.

[Sluuz]

iOS heeft er 3 (iPhone 3GS en eerder, iPhone 4 en iPad).

[johnbetonschaar]

Ja en nee. Er zijn inderdaad 3 resoluties, maar de oude iPhone resolutie (320x480) is forwards-compatible met die van de iPhone 4 (exact het dubbele), wat zoveel wil zeggen als: elke applicatie gemaakt voor de oude iPhone resolutie werkt zonder enige aanpassing ook op de iPhone 4, en ziet er dan ook precies hetzelfde uit als op bijvoorbeeld een 3GS (met uitzondering van fonts, en andere schaalbare elementen, die zijn scherper).

[Anoniem: 96523]

Sorry, je hebt gelijk (althans daar ga ik vanuit, want ik weet niet niet).

Maar Android heeft native support voor 24 verschillende scherm configuraties: http://developer.android....eens_support.html#testing

Iets meer dan iOS

[Mellow Jack]

Nope ik denk vooral dat het gewoon luiheid is geweest... Zonder die regels te volgen is het natuurlijk veel makkelijke om het resultaat te leveren wat de opdrachtgever wilt hebben. Het probleem ziet de klant pas wanneer je afwijkende resoluties gaat gebruiken (in het geval van tablets gebruik je ze vaak landscapped itt de portait op je telefoon) dus daar denken ze nu nog niet over na

[Eli3l]

De design guidelines zijn sinds android 2.x amper veranderd. Als je je app goed hebt ontworpen dan heb je enkel een paar kleine aanpassingen nodig om het goed te laten werken op tablets met een hogere res dan de telefoons.

[Katsunami]

Nee, blijkbaar niet.

Als alle applicaties onder Windows zich aan de designregels zouden houden, dan hadden we al ruim 10 jaar lang kunnen genieten van het goed opschalen van applicaties bij verschillende dpi-instellingen.

Als het om programmeurs gaat, dan lijkt het erop dat de meeste zeggen: "Oh, dat zijn de standaarden. Mooi. Dan gaan wij het anders doen." Dat lijkt dus wel voor elk platform te gelden.

[Reactie gewijzigd door Katsunami op 24 juli 2024 19:01]

[Roland684]

Vergeet ook designers niet. Die hebben graag dat hun ontwerp er precies uitziet zoals zij het designen en nadenken over hoe iets zou moeen schalen is alleen maar lastig.

Ondanks dat HTML helemaal geweldig schaalt en de richlijnen duidelijk stellen dat je het layouten aan de browser van de gebruiker over moet laten, barst het van de websites die een vaste breedte hebben. Op een groot scherm krijg je dan leegte, op een klein scherm (of als je je browser niet full-screen zet) moet je scrollen. Voor usability moet je op de mobiele sites zijn, daar heeft men tenminste na moeten denken over hoe het er op een andere monitor dan die van de designer uit ziet.

Of neem PDF: Schaalt voor geen meter, maar het ziet er wel precies zo uit als de designer wilde. Dat je daar als gebruiker de nadelen van ondervindt zal de designer wordt wezen, zolang het maar is wat hij/zij wil. (mijn scherm is bijvoorbeeld breder dan hoog en mijn printer print op A4, terwijl PDF vrijwel altijd Letter formaat is, dat het past nooit lekker.) PDF zou uitgebannen moeten worden, het is oud, achterhaald en ongebruiksvriendelijk, maar er zijn mensen die het heerlijk vinden omdat het precies doet wat zij willen, ook al zijn zij zelf niet de gebruiker.

[Hiub]

Ondanks dat HTML helemaal geweldig schaalt en de richlijnen duidelijk stellen dat je het layouten aan de browser van de gebruiker over moet laten, barst het van de websites die een vaste breedte hebben.

Bij de laatste website die ik heb gemaakt heb ik dit ook gedaan, echter wel een maximumbreedte, zodat het tekstgedeelte bijvoorbeeld op een mobiele browser ook schaalt naar de schermbreedte. Op een groot scherm heb je dan leegte, maar hele lange regels lezen nou eenmaal niet lekker, in LaTeX is hier bijvoorbeeld ook rekening mee gehouden (al vind ik daar de standaard tekstbreedte wel erg smal). Je zou dit ook wel kunnen oplossen met 2 kolommen, wat ik op die site ook deels heb gedaan.

PDF zou uitgebannen moeten worden, het is oud, achterhaald en ongebruiksvriendelijk, maar er zijn mensen die het heerlijk vinden omdat het precies doet wat zij willen, ook al zijn zij zelf niet de gebruiker.

Kom jij PDF dan zo vaak tegen als het puur is bedoeld om van het scherm te lezen? Ik eigenlijk zelden. De meeste PDF documenten die ik tegenkom zijn van handleidingen en allerhande documenten die bedoeld zijn om te printen en daar is het m.i. juist ideaal voor, dan weet je tenminste zeker dat het er bij iedereen nagenoeg hetzelfde uitziet.

Dan vind ik het ergerlijker mensen word-documenten versturen, terwijl die helemaal niet bedoeld zijn om te lezen of printen. Regelmatig is de lay-out dan helemaal vernaggeld als je geen word of word viewer op je computer hebt staan, zodat tabellen bijvoorbeeld niet meer leesbaar zijn e.d.

[mrdemc]

Als je in PDF formaat exporteert kun je gewoon je eigen formaat opgeven
Dat het dus vrijwel altijd op letter formaat is ligt aan de documenten die jij opent, en niet aan het PDF principe. Zo heb je ook PDF bladzijdes op dia/powerpoint formaat of gewoon A4 etc.
Dus wat jij nu zegt gaat niet helemaal op. Waarschijnlijk is het in Letter formaat omdat dat een veel gebruikt formaat is in de VS.

[MartijnGP]

Bespaart je een hoop moeite ben ik het nog niet zo mee eens. De design regels en best practices zijn nogal overwelmend en het kan allemaal veel sneller. Ik kan me prima voorstellen dat met name beginnende devs het niet zien zitten om met die fragments aan de gang te gaan. Dat is echt enorm ingewikkeld.

[Martijntj]

Dit is dus het grote nadeel van de tientallen verschillende mogelijke resoluties.
Als App-ontwikkelaar kost het zeeën van tijd en geld om je app compatible te houden met alle devices.

Hier zit een duidelijk voordeel binnen iOS.

[Zapato]

Niet helemaal mee eens. Ook hier heb je twee versies, iPhone en iPad. Apps met resolutie iPhone kun je 2x upscalen, maar dat ziet er naar mijn idee niet uit.

[Martijntj]

Maar het is allemaal wel exact 2x, en niet sóms 1,7 of 3,2 keer. Je hebt dus gewoon nu twee smaken.

[watercoolertje]

Allemaal exact 2x? Nee dit gaat over telefoon app naar tablet, en dat scheelt bij iOS helemaal niet precies 2x (wel bij de oude iPhone naar de nieuwe, maar daar gaat het nu helemaal niet om)

960*640 is het dubbele van 480*320, maar niet de helft van 1024*768 wat de resolutie van de tablet is...

iPad is 1.0666667x hoger/breeder dan een iPhone 4

Dus je app moet 6,66667% uitrekken....

[Reactie gewijzigd door watercoolertje op 24 juli 2024 19:01]

[vgroenewold]

Dat is dan nog niet bepaald rampzalig want het blijven 2 verschillende resoluties, niet 10 en zeker niet 1.5 tot 2x verschillend met alle mogelijke combinaties. Voor een developer is dat dus nog steeds veel makkelijker, maar dat lijkt me verder ook geen discussie, dat is zo duidelijk als wat. Dat Android er nu iets aan probeert te verbeteren is een goede stap, hoewel ik het een beetje een pleister blijf vinden op een probleem wat gewoon inherent aan het systeem is... wat dan wel weer andere voordelen heeft.

[Mellow Jack]

Die developer houd toch wel rekening met het feit dat de Ipad3 een iets andere resolutie zal gebruiken? Of wilt de developer liever de applicatie op dat moment aanpassen zodat ze nog wat centjes krijgen van de opdrachtgever?

[watercoolertje]

Voor een developer is dat dus nog steeds veel makkelijker, maar dat lijkt me verder ook geen discussie, dat is zo duidelijk als wat.

Je bedoelt dat het duidelijk is dat als je je aan de designregels houdt dat het geen flikker uit maakt of er 2 of 10miljard verschillende resoluties zijn

Je doet alsof het een probleem is dat er tig resoluties zijn maar dat is juist geen probleem als je je maar aan de daarvoor bedachte regels/standaarden houd die gemaakt zijn om juist te schalen naar een in theorie oneindig aantal resoluties

[vgroenewold]

Ok, dat is dan wellicht correct (ik develop er niet voor), maar dan nog is het een probleem want developers houden zich niet aan regels. En dat is ook inherent aan het systeem. Voor de gebruiker is de uitkomst hetzelfde. Verder is schalen leuk, maar is het bijv. op de iPhone en iPad ingebakken dat je als developer in 1 app 2 totaal verschillende UI's voor beide platforms kan maken, ook iets wat ik onder Android nauwelijks tot eigenlijk niet zie.

[Reactie gewijzigd door vgroenewold op 24 juli 2024 19:01]

[Mellow Jack]

Kan je het niet afdwingen?

Ik snap inderdaad dat ontwikkelaars liever niet willen veranderen (elk mens is anti verandering) en snap ook dat het financieel beter is om 2 of zelfs 3 apps te verkopen (kunnen ze de mensen met een iphone en ipad lekker oplichten.)

Als je dit afdwingt dan zal je in het begin wel flinke tegenstand krijgen maar zullen de ontwikkelaars het niet uiteindelijk accepteren en dr blij mee zijn?

Het is maar een voorstel hoor want hoe krijg je anders ontwikkelaars die eens zo gaan werken zoals het bedoeld is? De consument is natuurlijk het uitgangspunt en het is voor de consument gewoon beter om 1 app op de phone en tablet te kunnen gebruiken (beter zelfs dat het ook nog eens op de desktop gebruik zou kunnen worden)

[Mellow Jack]

Een amateur kan daar inderdaad niet mee omgaan. Een professional werkt met percentages ed en volgt gewoon netjes de regels. Je moest eens weten hoeveel apps ik windowed kreeg op mijn ipad in de begin periode (oftewel die ontwikkelaars waren ook te lui om de regels te volgen)

[Mellow Jack]

Bullshit het is helemaal niet lastig om rekening te houden met verschillende resoluties. Kijk naar websites, die doen hetzelfde

Dit is puur en alleen vanwege de startup periode van Honeycomb... Netzoals bij de iPAD1 heb je ook bij Honeycomb last van het feit dat dit de eerste lichting echt bruikbare tablets zijn. De apps moeten dus nog volgen. De Ipad heeft exact dezelfde problemen gehad

Dit komt dus puur vanwege het feit dat de ontwikkelaars zich liever de moeite besparen om de regels te volgen want degene die de regels hebben gevolgd hebben geen probleem (los van het feit dat het niet altijd even mooi eruit ziet)

[Xthemes.us]

Nou om eerlijk te zijn.. een hoop websites doen hetzelfde als wat android nou met deze update voorkomt. Namelijk een hoop witruimte weergeven, tweakers.net heeft bijvoorbeeld 2 grijze balken aan de zijkant op mijn monitor (1920x1200) waar helemaal niks op staat.

Dat komt omdat een 'fixed width' design is. Fluide ontwerpen die netjes gebruik maken van alle breedte die een site bied zie je niet zo vaak, dit is moeilijk te realiseren bij de meer complexe ontwerpen.

Maar inderdaad, als je op android gewoon gebruik kan maken van de layouts die je ook op andere platformen terugvind dan zijn de ontwikkelaars gewoon vreemd bezig geweest.

[Mellow Jack]

Ja klopt! Ik had even een voorbeeld website moeten opgeven want je hebt helemaal gelijk dat lang niet iedereen het gebruikt Op mijn monitor zijn me standaard sites automatisch ingezoomed dus ik merk dr weinig van (op het gemis in scherpte bij bijv afbeeldingen.)

Edit: Kijk even naar Gmail... Deze schaalt automatisch naar je resolutie, bij het schalen naar beneden zal hij zo ver gaan tot op het moment dat hij zijn informatie nog net goed kan presenteren, daarna krijg je scrol balken (in de praktijk zal dat het moment zijn dat je de mobiele site voor je neus krijgt.)

[Reactie gewijzigd door Mellow Jack op 24 juli 2024 19:01]

[humbug]

En de vraag is of je dat wilt. Op allerlei plekken scrollbalken in de interface werkt niet prettig. Wat je wilt is dat er informatie toegevoegd wordt als er ruimte voor is en weggelaten wordt als die ruimte er niet is. Zo zie je dat veel iPad applicaties een andere interface hebben dan hun smartphone broertje en geen grote hoeveelheden lege ruimte of extreem grote fonts op de ipad of scrollbalken op de iPhone.

Android ondersteund verschillende interfaces in 1 applicatie en dat is uiteindelijk de weg die grote ontwikkelaars zullen volgen. Bouw een interface voor grote en kleine schermen en laat die interface enigszins schalen om op verschillende apparaten goed over te komen. Enkel een beetje schalen is niet de manier om met totaal verschillende resoluties om te gaan. Een product wordt op een PC anders gebruikt dan op een tablet of smartphone. Dat zul je in je interface ontwerp moeten meenemen.

[Mellow Jack]

Ik hoopte dat ik iets duidelijker was maar dat blijkt niet zo...

Hoe ik het zeg heb je dus geen scrollbalken in de interface (zoals je ziet meld ik ook de praktijk situatie icm de switch naar de mobiele app)

Zie het zo:

Je bouwt 3 interfaces voor je (in dit geval) Applicatie.

Eerste interface wordt gebruikt wanneer je een bijv 16:9 indeling met een useragent van een normale desktop (hier geldt dus al de resoluties met een minimale resolutie van bijv 800X600, ga je nog lager krijg je helaas scrolbalken maar lager dan 800X600 is niet echt realistisch meer tegenwoordig) Voorbeeld: Zie Gmail, daar zal je ook bijna nooit schrollbalken zien wanneer je met een standaard resolutie werkt (bijv 1024X768)

Tweede interface wordt ook gebruikt bij een 16:9 indeling maar wel wanneer de useragent aangeeft dat het een tablet is. Hier past hij dus automatisch de interface voor de tablets toe. Ook in dit geval werkt dit prima met al de resoluties omdat je met percentages kan werken (en een automatisch schalende font). Hier komt het scollen vanzelf bij kijken maar dat is nu al het geval met tablet apps en dat werkt prima (zie bijv de nu.nl app op de ipad)

Derde interface wordt gebruikt bij een bijv 9:16 indeling. Dit is dus je smartphone.
Hier krijg je de interface die wij nu allen kennen op de iphone en android apps, dit is ook onafhankelijk van de resolutie aangezien je weer met percentages werkt.

Al zou je dus een cross platform taal hebben/gebruiken dan kan je in 1 slag een Applicatie maken die werkt op Desktop computers, tablets en smartphones. Hierdoor kan je een ultieme ervaring garanderen die is toegespitst op het apparaat waarop je het gebruikt.

Note: Ik noem de useragent omdat dit een bekende term is binnen de web ontwikkeling

Note2: Ik ben geen ontwikkelaar, ik weet dus ook niet of de door mij voorgestelde methode werkbaar is... Ik denk dat je sowieso een financieel probleempje hebt aangezien verkopers liever 3 losse apps hebben ipv 1 app die overal op werkt. Het gaat mij dus ook meer om de theorie dan om de praktische toepasbaarheid

[Reactie gewijzigd door Mellow Jack op 24 juli 2024 19:01]

[UmbraDei]

Het hele punt van de standaardisatie bij android development is dat android het normaal gezien vanzelf rescaled naar hogere resoluties:

" Daarom blijft Google ontwikkelaars aanraden om de interface van hun applicaties volgens de officiële standaarden te ontwikkelen. Zelfs applicaties zonder speciale tablet-lay-out kunnen dan fullscreen weergegeven worden zonder scherpteverlies. "

Je kan heel je layout gewoon procentueel uitdrukken. Zie het als bij CSS: daar kan je ook simpelweg zeggen: gebruikt 100% breedte, maar er zijn nog steeds web designers die spijtig genoeg vast blijven hangen aan die '800px' wat op een 2560x1600 scherm gewoon belachelijk overkomt.

[t_captain]

Daarvoor heeft Android ook de DIP (Device Independent Pixel) in z'n GUI API's

[watercoolertje]

Dit heeft helemaal niks met de 1001 resoluties te maken, maar met 2 verschillende schermtype, kleine en grote

Als je je gewoon aan de duidelijke designregels houdt dan is het ook goed Als je dat moeilijk vindt ligt dat aan jouw, niet aan Android

Ik ben zelf webdeveloper en totaal geen moeite met het designen voor nog 100x meer resoluties dan Android heeft, sterker nog websites die ik maak zien er goed uit op je PC maar ook op je tablet, en ook op je mobiel (nee niet op een nokia 3310)...

Schalen kan prima gaan, maar dan moet je je nou eenmaal wel aan een aantal regels houden, doe je dat niet is het niet gek dat het niet perfect schaalt...

[Reactie gewijzigd door watercoolertje op 24 juli 2024 19:01]

[Anoniem: 320277]

Helemaal niet. Er zijn gewoon officiële standaarden van Google, die je gewoon zou moeten gebruiken. Als je dat niet doet, is dat je eigen probleem als ontwikkelaar.

[Ponzi]

Nu heb ik nog nooit een app gemaakt voor Android of iOs, maar het lijkt mij dat als je je als ontwikkelaar aan de standaard houdt die Google je aanbiedt, dat je applicatie dan perfect wordt weergegeven op alle telefoons.

Ik heb zelf een GSM met Gingerbread en een tablet met Honeycomb en ik ben nog geen enkele app tegengekomen die niet mooi wordt weergegeven op de tablet. Toegegeven, het is niet optimized voor de tablet, maar het werkt wel en alles ziet er scherp en duidelijk uit.

Volgens mij doet Google deze update gewoon om de apps van ontwikkelaars die zich niet aan de standaard houden toch een beetje deftig weer te geven op tablets. Als je als ontwikkelaar dus meteen deftig begint, dan heb geen enkele moeite om je applicatie op alle devices compatible te houden !

Edit: wauw, ik type veel te traag... wat zij allemaal zeggen !

[Reactie gewijzigd door Ponzi op 24 juli 2024 19:01]

[Finraziel]

Tientallen?
Hmm... qvga, hvga, wvga, 852x480, 1024x600, 1280x720...
6 resoluties, welke vergeet ik volgens jou? Iphone iOS heeft 3 verschillende resoluties, inderdaad minder maar nou ook weer niet zo'n enorm groot verschil als jij nu suggereert. Bovendien als je voor android code en je daarbij houdt aan de designadviezen van google dan wordt je app over het algemeen prima naar elke resolutie geschaald. Je zult alleen misschien wat verschillende graphics willen leveren voor de uitersten in resoluties, dat is mooier, maar hoeft niet eens per se.

edit: Ok... iOS Als je puur naar android telefoons kijkt zijn het ook minder resoluties.

[Reactie gewijzigd door Finraziel op 24 juli 2024 19:01]

[Finraziel]

Ben benieuwd, als de gpu bv ingezet kan worden dan hoeft die pixelation helemaal niet zo erg te zijn.

[Anoniem: 135756]

Dat blijft aan de orde hoor...
Als de interface bitmap graphics als bron heeft, dan kan je enkel met filters de pixelvorming wat verzachten, hetgeen er nog steeds niet mooi uit ziet overigens.

Of bedoel je GPU inzetten om juist vector-based interfaces te maken? (vector GFX zijn intensief, dus iets wat je zou willen versnellen)
Want dan zit je uberhaupt niet aan dimensies vast.

[Finraziel]

Nee ik dacht inderdaad aan die filters... Of je dat acceptabel vindt of niet dat is persoonlijk natuurlijk. Ik heb er zelf meestal niet zo'n moeite mee, als ik een gescaled plaatje er lelijkt uit vind zien dan komt dat meestal doordat het scaler algoritme bagger is.

[Mellow Jack]

Kan ik dat vergelijken met het bekijken van websites op een 21" scherm waarbij de site vrijwel altijd is ingezoomd op 200 of 300%? Of vat ik het idee helemaal verkeerd op?

[Finraziel]

Inderdaad. Of op een 42" TV, dat doe ik in de huiskamer
Nou bestaat een webpagina wel veel uit tekst en dat laat zich natuurlijk uitstekend schalen door het font gewoon iets aan te passen. De plaatjes worden natuurlijk wel op dezelfde manier geschaald. Bij een app zal het er vanaf hangen, hopelijk zal android tekst kunnen scalen door het font aan te passen (verwacht ik wel) maar als je bv een app hebt met tekst die niet met een font werkt maar zelf intern tekst als plaatjes laat zien, ja dat wordt wat minder...

[Mellow Jack]

Oei dat is nogal een groot verschil natuurlijk! Mijn desktop op 300% ingezoomd is echt een ramp (qua kwaliteit) terwijl een ingezoomde website heel netjes is (fonts en dergelijk passen zich dan wel aan.)

[Anoniem: 335608]

De lage resolutie/pixelation is niet het enige probleem. Het grootste probleem is dat apps niet geoptimaliseerd worden voor het grote scherm.
Draai maar eens de facebook iPhone app fullscreen op een iPad. De interface slaat dan gewoon nergens op.
Oprekken is dus geen optie. Biedt het gewoon niet aan, dan worden developers gedwongen hun apps voor tablets te optimaliseren. Phone apps gebruik je toch niet op een tablet.

[gnu]

Dat is dus iets wat als je de regels van Android goed volgt automatisch wordt opgelost, wat dus stukken beter is dan de iOS optie van alles verdubbelen. 90% van de Android apps die ik op Honeycomb gebruik zijn eigenlijk gewone (mobile Android) apps. Maar door het fluide gebruik van de interface (wat Google in z'n guidelines aanmoedigt) ziet het er toch goed uit, niks graphics die worden opgerekt!

[Anoniem: 335608]

Ik doel dus ook op de inrichting van de interface en niet op de al dan niet aanwezige pixelation.

[Mavamaarten]

Let maar op of apple heeft er zogezegd weer een patent op, terwijl het idee nog zo logisch is.
Het enige dat ik jammer vind is dat google zich de laatste tijd alleen maar lijkt te focussen op tablets. Het zijn misschien leuke gadgets, maar ik vind tablets onnuttig en moet er dan ook geen hebben. Google zou zich beter wat meer bezighouden met nieuwe functies voor android-telefoons, en daarmee bedoel ik dan ondersteuning voor ad-hoc netwerken, ...

[gnu]

Het is algemeen bekend dat Android Ice Scream er voor gaat zorgen dat alle Android versies (telefoon, tablet en google tv) weer op dezelfde versie draaien.

Dit brengt veel verbeteringen met zich mee, o.a. Android toestellen die geen knoppen (home, menu, back, search) meer nodig hebben. Waardoor het eerstvolgende nexus toestel waarschijnlijk een (nagenoeg) edge-to-edge scherm gaat hebben.

[Ethelind]

Ik vind niet dat ze veel bezig zijn met tablets, niet veel meer dan met smartphones.
wat ze juist doen is alles samen smelten, tablets en smartphones. aangezien ze de zelfde specs hebben is dat ook het beste wat je kan doen.
Laat google maar op schieten met Android IceCream Sandwich!
Ik hoop dat het snel komt, dan kan ik eindelijk mijn android 4.0 tablet ophalen en de ipad2 de deur uit doen, gesloten onding wat het is

[Mellow Jack]

Lol ik heb een Android 3.0 tablet en moet eerlijk zeggen dat de (imo) tablet veel beter is dan de ipad2 Het enige gemis is een shitload aan apps (je moet iets beter zoeken atm) maar dat had je in het begin van de ipad ook.

[hardcoresmurf]

Dit vind ik op zich wel handig als je bijvoorbeeld apps voor smartphones draait ,die niet op fullscreen kunnen toch op fullscreen kan gebruiken

[Chris7]

Lijkt me mooi voor Honeycomb, zo komen er sneller meer tabletapps beschikbaar. Dat komt namelijk in alle reviews van Android Honeycomb-tablets naar voren: Er zijn maar zeer weinig tablet-apps. Ik denk dat dit een stap in de goede richting is, en het is natuurlijk ook gewoon een kwestie van tijd.
Dit lijkt me trouwens ook voorbereiding op Ice Cream Sandwich, want dan kan je dus één app maken die op verschillende schermgroottes draait.

[Snake]

Apple zou dat ook moeten doen. Het is niet normaal dat ik apps op mijn iPad, gemaakt voor retina graphics maar op 480*320 kan weergeven, eventueel verdubbeld in pixels. Maar mooi weergeven op de hoge resolutie doen ze niet ...

[Anoniem: 96523]

iOS kan dat toch al?
Althans volgens het artikel wel:

[..] de mogelijkheid om die applicaties op te rekken, zodat ze het volledige scherm vullen, net zoals bij de iPad gebeurt.

[Mellow Jack]

Nee dat klopt niet... Ook bij Apple gelden regels

Bij de Iphone klopt het wel (resolutie van de IP4 is 2x die van de 3) maar bij de iPad krijg je je applicatie in een window wanneer hij gebruikt maakt van hardcoded afmetingen... Wanneer de Iphone app goed is ontwikkeld dan schaalt hij gewoon netjes mee (net zoals bij Android dat al lang het geval is)

[Reactie gewijzigd door Mellow Jack op 24 juli 2024 19:01]

[ZpAz]

Je hebt het over een iPhone app op de iPad? Dan is er rechtsonder namelijk een knop 'maak groter'. (2x).

Niet dat ik veel geef om 'schalende iPhone apps' geef mij maar een app met een iPad interface op mijn iPad, stukken beter.

[Mellow Jack]

Zelfs nadat je op de knop "maak groter" drukt dan is hij alsnog Windowed En zoals ik zeg al had die app goed ontwikkeld geweest dan had hij zichzelf geschaald en had je dus niet hoeven te "vergroten"

Het inzoomen van de ipad op bepaalde apps is natuurlijk niet gelijk aan het automatisch schalen van de applicaties... Bij het automatisch schalen blijft bijv je font heerlijk scherp itt het inzoomen. Ik heb zelf een ipad gehad en gebruikte zeker wat apps die zichzelf schalen maar elke app die van de door jou genoemde zoom functie gebruikt maakt heb ik gelijk verwijderd omdat alles dr gewoon NIET UIT ZIET

Zoals M1lamb3r hierboven zegt, vergelijk eens een website die 300% is ingezoomd en een vergrootglas op je desktop die 300% inzoomt.... Bij het vergroot glas zie je alles lelijk worden (zelfde als de vergroot functie op de ipad) terwijl je bij een ingezoomde website alleen de plaatjes iets lelijker zie worden

[iFajar]

Dat komt door het verschil in de schermratio van de iPad/iPhone

[lonegunner]

En nu maar weer wachten op apple voor claim dat hun daar weer patent op hebben.
Wel fijn zit op de nieuwe galaxy tab te wachten dus alle vooruitgang is mooi.

[LemonC200]

Dit is een goeie oplssing voor mensen die de tablet versie van android gebruiken omdat er veel apps zijn die niet tablet optimized zijn.

[Reactie gewijzigd door LemonC200 op 24 juli 2024 19:01]