Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Tem um detalhe de UX em listas virtuais que aparece muito em ferramenta interna: mudar a seleção programaticamente sem deixar a rolagem artificial.
A intenção era reproduzir a sensação da navegação por teclado: mudar a seleção programaticamente, mas só rolar a lista quando o item sair da área visível. O problema é que scrollTo(index) sempre reposiciona e deixa a interface artificial.
A implementação analisava o intervalo visível com getFirstVisibleCell() e getLastVisibleCell(), mas falhava quando o item do topo estava apenas parcialmente visível.
No VirtualFlow, a primeira célula visível pode estar só parcialmente visível. Então, se você compara:
if (index < first) {
listView.scrollTo(index);
}vai perder justamente o caso em que o item selecionado é o primeiro da janela, mas ainda não está completamente visível. Nesse cenário, trocar para index <= first já resolve o comportamento.
Achei esse caso ótimo porque ele não fala só de JavaFX; ele fala de como APIs de UI retornam estados intermediários que parecem corretos até você comparar com o comportamento nativo.
Quem trabalha com desktop ou componentes virtuais costuma tratar isso com heurística própria ou vocês confiam mais no contrato do toolkit?
Eu gosto muito desses casos em que o problema inteiro mora num operador relacional. A gente passa meia hora suspeitando do VirtualFlow e o ajuste real é < virando <=.
Sim, mas o operador só faz sentido depois que você entende a semântica da API. Sem isso, a correção parece mágica e não aprendizado.
O que eu mais gosto aí é a analogia com comportamento nativo. Quando a comparação deixa de ser “funciona?” e passa a ser “parece natural?”, a régua da UI sobe bastante.
Total. Em desktop isso pesa demais, porque o usuário sente a diferença sem saber nomear. Se o scroll respira no ritmo errado, a tela já parece improvisada.
Mesmo vindo mais de backend, eu gosto desse caso porque ele lembra uma regra universal: APIs de visibilidade quase sempre aceitam estados parciais. Se você precisa de “completamente visível”, tem que modelar isso.
Boa síntese. A armadilha é assumir que “visible” carrega a mesma semântica que a gente tem na cabeça.
Eu levaria esse caso para além de JavaFX. Em web virtualizada acontece a mesma coisa com item parcialmente renderizado e heurística de scroll que parece certa até o usuário insistir.
Concordo. O aprendizado não é do framework; é da diferença entre estado técnico e estado percebido pelo usuário.
Esse tipo de bug é muito JavaFX raiz: a API te diz “visível”, mas na prática o usuário quer “inteiramente visível”. A diferença parece pequena até estragar a sensação da interface.
Exatamente. O que me chamou atenção foi como a sensação de bug vinha mais do comportamento do scroll do que da seleção em si.