Compartilhar via


Resumo do Capítulo 5. Lidar com tamanhos

Observação

Este livro foi publicado na primavera de 2016, e não foi atualizado desde então. Há muito no livro que permanece valioso, mas parte do material está desatualizado, e alguns tópicos não estão mais totalmente corretos ou completos.

Vários tamanhos em Xamarin.Forms foram encontrados até agora:

  • A altura da barra de status do iOS é 20
  • O BoxView tem uma largura e altura padrão de 40
  • O padrão Padding em um Frame é 20
  • O padrão Spacing no StackLayout é 6
  • O Device.GetNamedSize método retorna um tamanho de fonte numérico

Esses tamanhos não são pixels. Em vez disso, são unidades independentes de dispositivos reconhecidas independentemente por cada plataforma.

Pixels, pontos, dps, DIPs e DIUs

No início das histórias do Apple Mac e Microsoft Windows, os programadores trabalhavam em unidades de pixels. No entanto, o advento de monitores de maior resolução exigiu uma abordagem mais virtualizada e abstrata das coordenadas da tela. No mundo Mac, os programadores trabalhavam em unidades de pontos, tradicionalmente de 1/72 polegada, enquanto os desenvolvedores do Windows usavam unidades independentes de dispositivo (DIUs) baseadas em 1/96 polegada.

Os dispositivos móveis, no entanto, são geralmente mantidos muito mais perto do rosto e têm uma resolução mais alta do que as telas de desktop, o que implica que uma maior densidade de pixels pode ser tolerada.

Os programadores voltados para dispositivos Apple iPhone e iPad continuam trabalhando em unidades de pontos, mas há 160 desses pontos para a polegada. Dependendo do dispositivo, pode haver 1, 2 ou 3 pixels no ponto.

O Android é semelhante. Os programadores trabalham em unidades de pixels independentes de densidade (dps), e a relação entre dps e pixels é baseada em 160 dps para a polegada.

Os telefones Windows e dispositivos móveis também estabeleceram fatores de dimensionamento que implicam algo próximo de 160 unidades independentes de dispositivo para a polegada.

Observação

Xamarin.Forms não suporta mais nenhum telefone ou dispositivo móvel baseado no Windows.

Em resumo, um Xamarin.Forms programador direcionado a telefones e tablets pode assumir que todas as unidades de medida são baseadas no seguinte critério:

  • 160 unidades por polegada, equivalente a
  • 64 unidades ao centímetro

As propriedades somente Width leitura e Height definidas por VisualElement têm valores padrão "fictícios" de –1. Somente quando um elemento tiver sido dimensionado e acomodado no layout, essas propriedades refletirão o tamanho real do elemento em unidades independentes de dispositivo. Esse tamanho inclui qualquer Padding conjunto no elemento , mas não o Margin.

Um elemento visual dispara o SizeChanged evento quando seu Width ou Height foi alterado. O exemplo WhatSize usa esse evento para exibir o tamanho da tela do programa.

Tamanhos métricos

O MetricalBoxView usa WidthRequest e HeightRequest para exibir uma polegada de BoxView altura e um centímetro de largura.

Tamanhos de fonte estimados

O exemplo FontSizes mostra como usar a regra de 160 unidades para a polegada para especificar tamanhos de fonte em unidades de pontos. A consistência visual entre as plataformas que utilizam essa técnica é melhor que Device.GetNamedSizea .

Ajustar o texto ao tamanho disponível

É possível ajustar um bloco de texto dentro de um determinado retângulo calculando um FontSize dos Label usando os seguintes critérios:

  • O espaçamento entre linhas é de 120% do tamanho da fonte (130% nas plataformas Windows).
  • A largura média dos caracteres é de 50% do tamanho da fonte.

A amostra EstimatedFontSize demonstra essa técnica. Este programa foi escrito antes da Margin propriedade estar disponível, por isso usa uma ContentView configuração com uma Padding para simular uma margem.

Captura de tela tripla do tamanho estimado da fonte

Um relógio adequado ao tamanho

O exemplo FitToSizeClock demonstra o uso Device.StartTimer para iniciar um temporizador que notifica periodicamente o aplicativo quando é hora de atualizar o relógio. O tamanho da fonte é definido como um sexto da largura da página para tornar a exibição o maior possível.

Problemas de acessibilidade

O programa EstimatedFontSize e o programa FitToSizeClock contêm uma falha sutil: se o usuário alterar as configurações de acessibilidade do telefone no Android ou no Windows 10 Mobile, o programa não poderá mais estimar o tamanho do texto com base no tamanho da fonte. O exemplo AccessibilityTest demonstra esse problema.

Texto empiricamente ajustado

Outra maneira de ajustar o texto a um retângulo é calcular empiricamente o tamanho do texto renderizado e ajustá-lo para cima ou para baixo. O programa no livro chama GetSizeRequest um elemento visual para obter o tamanho desejado do elemento. Esse método foi preterido e, em vez disso, os programas devem chamar Measure.

Para um Label, o primeiro argumento deve ser a largura do contêiner (para permitir o empacotamento), enquanto o segundo argumento deve ser definido para Double.PositiveInfinity tornar a altura irrestrita. A amostra EmpiricalFontSize demonstra essa técnica.