Responsividade para Telas Grandes

Conjunto de adaptações da interface para tablets e janelas largas (split-screen, desdobrável). A régua usada em todo lugar é a largura medida da tela/janela (LocalConfiguration.screenWidthDp), não o tipo de dispositivo — o mesmo celular em split-screen ou o mesmo tablet girado entre retrato e paisagem reage em tempo real, sem precisar reiniciar a tela.

Duas ideias centrais guiam todas as decisões abaixo:

  1. Celular nunca muda de comportamento. Toda adaptação só entra em ação a partir de um limiar de largura — abaixo dele, o app se comporta exatamente como antes de qualquer um desses ajustes.
  2. Nada de automatismo que tire controle do usuário. Nenhuma dessas mudanças liga automaticamente uma preferência que deveria ser escolha manual (ex.: modo de página dupla no leitor continua 100% manual, mesmo em tablet grande e na horizontal — foi um pedido explícito).

Dois limiares de largura, não um só

  • 600dp — o suficiente pra uma rail lateral fina (88dp) caber sem espremer o conteúdo.
  • 840dp ("expanded", termo do Material) — usado só onde o conteúdo precisa de espaço de verdade pra duas colunas confortáveis, não apenas um ícone. Um tablet de 8-10" em retrato tipicamente cai entre 600 e 840dp: cabe a rail, mas não um painel lista+detalhe decente. Usar o mesmo limiar de 600dp pros dois já causou um bug real (painel de Configurações espremido em retrato) — por isso os dois limiares são deliberadamente separados (isWideScreenLayout() vs isExpandedScreenLayout(), em ui/theme/InterfacePreferences.kt).

Navegação: rail lateral

A partir de 600dp, a barra de navegação inferior (BottomNavBar) some e dá lugar a uma rail fixa na lateral esquerda (InkNavigationRail, em ui/components/BottomNavBar.kt) — mesmas abas, mesma lógica de seleção, só o eixo muda. A troca acontece em InkNavGraph.kt e SnapshotNavGraph.kt (bibliotecas salvas têm a mesma adaptação).

Ainda básica de propósito: sem insets de sistema tratados, sem destaque visual diferente do simples realce de cor do ícone ativo, sem atalhos extras (cogitou-se adicionar Busca/Downloads como itens secundários abaixo de um divisor, mas ficou fora de escopo por enquanto).

Configurações: lista + detalhe

A partir de 840dp (isExpandedScreenLayout()), a tela de Configurações deixa de substituir a tela inteira a cada navegação e passa a mostrar o Hub fixo à esquerda (400dp de largura) com o conteúdo da categoria selecionada à direita — implementado em ConfiguracoesScreen.kt. Abaixo de 840dp (celular e tablet em retrato), continua substituindo a tela inteira, como sempre foi.

Quando nenhuma categoria foi selecionada (voltar até a raiz da navegação interna), o painel direito mostra um estado vazio genérico em vez de duplicar o Hub nos dois painéis.

Teto de largura de conteúdo

Vários lugares limitam a largura do conteúdo e o centralizam, em vez de deixar esticar de ponta a ponta numa tela larga — o fundo/superfície continua ocupando a tela toda, só o conteúdo em si fica com um teto:

OndeTetoArquivo
Barras do leitor (HQ/PDF e EPUB)760dpTelaLeituraScreen.kt, EpubLeituraScreen.kt
Diálogo de correção de cor do leitor480dpColorCorrectionDialog.kt
Sub-telas de Configurações (todas, via SubScreen), Hub, Histórico, Marcadores, Estatísticas680dpSettingsShared.kt, HubSettingsScreen.kt, HistoricoScreen.kt, MarcadoresScreen.kt, EstatisticasScreen.kt

Diálogos padrão (AlertDialog do Material 3) e o ModalBottomSheet de marcadores do leitor já vinham protegidos por padrão pela própria versão do Compose usada no projeto (560dp e 640dp de teto, respectivamente) — não precisaram de nenhuma mudança. Só um diálogo customizado (ColorCorrectionDialog, que desliga esse comportamento padrão de propósito) precisava do teto manual.

A faixa de miniaturas do leitor fica de fora do teto — mais miniaturas visíveis é aproveitar bem o espaço extra, não um problema a corrigir.

Banner em destaque da Início

Só em paisagem/tablet largo (mesmo limiar de 840dp): o carrossel em destaque (FeaturedHeroCarousel, em InicioScreen.kt) usa a tela toda (sem teto de largura), com o card atual alinhado à esquerda e ~metade do próximo espiando à direita — em vez do espia simétrico pequeno usado em celular/retrato. A altura do card também deixa de ser um valor fixo: é calculada a partir da largura medida (proporção 1.5:1), pra não voltar a ficar esticada nem espremida em nenhum tamanho de tela dentro dessa faixa.

"Tamanho dos cards" afeta o app inteiro, não só o Acervo

A preferência de tamanho de card (InkCardSize, em ui/theme/InterfacePreferences.kt) tem 5 opções — Muito pequenos, Menores, Médios (padrão), Grandes, Muito grandes — que controlam ao mesmo tempo:

  • quantas colunas a Biblioteca usa por linha (1 a 5, ver LibraryRepository.SETTING_COLUMNS);
  • a largura dos cards na Início (prateleiras "Continuar lendo" e "Favoritos") — ali não existe "colunas por linha" porque é um carrossel horizontal, então a preferência só controla o tamanho físico do card. O banner em destaque fica de fora dessa conta, por enquanto.

Em qualquer tela maior que a referência (~360dp úteis), a quantidade de colunas da Biblioteca cresce sozinha além do que a opção escolhida sugere (adaptiveGridColumns, mesmo arquivo) — a opção do usuário continua valendo como proporção de tamanho, só ganha mais colunas em telas largas em vez de esticar cada card.

Ver também

  • Aparência — onde a preferência de tamanho dos cards é exposta.
  • Tela Inicial — comportamento do carrossel em destaque e das prateleiras.