Billede 1 af 5
Den nemmeste måde at håndtere dette på er at fortælle din app altid at køre i stående tilstand (eller hvis du foretrækker det, altid i liggende) og aldrig rotere. Du kan gøre dette fra B4A-editorens menuer - bare gå til Project | Orienteringer Understøttet og tag dit valg.
Hvis du gerne vil håndtere tingene mere yndefuldt, kan du dog få din app til at reagere dynamisk på retningsændringer. Hvis du har oprettet et layout i stående tilstand i Designeren, kan du nemt oprette et alternativ i liggende tilstand ved at klikke på "Ny variant" og vælge parametrene for dit nye layout. Du vil se, at du kan oprette så mange varianter, som du vil, for ikke kun at målrette mod forskellige retninger, men også forskellige skærmstørrelser og -former. Det er her det kan betale sig at bruge AVD'er, da du nemt kan samle en samling virtuelle enheder med forskellige skærmstørrelser, som du kan teste dine forskellige layouts på.
Til vores formål vil forudindstillingen "Telefon (landskab)" dog være fin. Vælg det, og klik på OK; du vil se, at der nu er to varianter af dit layout, som du kan skifte mellem. Når du tilføjer, fjerner eller redigerer en visning i én variant, opdateres alle de andre automatisk – men placeringsændringer påvirker kun det aktuelle layout. Dette gør det nemt at skræddersy din grænseflade, så den passer til et væld af forskellige enheder.
Designer scripts
Du kan redigere varianter på en mere dynamisk måde ved at bruge Designerens scripting-evner; fanen i Designer-hovedgrænsefladen lader dig bruge simpel kode til at definere layouts i stedet for manuelt at skulle trække og slippe. Du kan også indstille elementstørrelser i forhold til procenter - for eksempel for at angive, at et panel altid skal fylde 50 % af skærmen, uanset de særlige dimensioner af brugernes enhed. For mere information, se den officielle guide til at komme i gang med scripts.
På dette tidspunkt er det værd at nævne, at ud over forskellige skærmstørrelser og opløsninger har forskellige Android-enheder forskellige pixeltætheder. Nogle, såsom Nexus 7, pakker pixels så tæt, at du knap kan se dem med det blotte øje, mens ældre smartphones har større pixels. Som et resultat, hvis du for eksempel opretter en knap, der er 50 pixels kvadratisk, kan du måske opdage, at det er nemt at trykke på én enhed, men besværligt på en anden.
Android kommer uden om dette ved at lade dig angive størrelser i "densitetsuafhængige pixels", også kendt som dps eller dips. Disse er virtuelle pixels, der skaleres automatisk, så de passer til skærmtætheden på den aktuelle enhed. En knap, der måler 160 x 160 fald, skal altid vises på skærmen på omkring 1 tommer kvadratisk, uanset skærmtype og opløsning.
B4A-designeren måler dimensioner i fald. Hvis du opretter et grænsefladeelement med dimensioner på f.eks. 100 x 100, vil det blive tegnet vha. men mange pixels er nødvendige for at opnå den korrekte virkelige skala på omkring to tredjedele af en tomme. Du kan finde ud af den absolutte størrelse af en visning i pixels ved at læse dens egenskaber for bredde og højde, og det kan du konverter et hvilket som helst antal fald til pixels ved hjælp af funktionen DipToCurrent() og sætter antallet af fald som en parameter i beslag.
Faktisk, hvis du flytter eller opretter elementer i din kode, kan du vælge at glemme pixels helt. Dimensioner og afstande kan angives i fald eller som procenter af aktivitetens vandrette og lodrette dimensioner. For eksempel, hvis du vil placere et 2 tommer firkantet panel halvvejs nede på siden, skal du bruge koden:
Mange programmører anbefaler helt at undgå pixelmålinger og specificere hele dit layout i dips; dette hjælper din app med at klare ikke kun en lang række nuværende skærme, men også uanede fremtidige.
Uanset hvordan du opretter og angiver dem, gemmes alle varianter i den samme layoutfil, og Android vælger automatisk det layout, der matcher bedst brugerens skærmstørrelse og orientering - så når du først har konfigureret dine varianter, er der næsten ikke mere for dig at gør.
