O documento discute boas práticas de desenvolvimento para aplicativos Android em telas grandes, incluindo a importância de se preocupar com a arquitetura, adaptação para diferentes tamanhos de tela e configurações de dispositivo, e formas de garantir a continuidade da experiência do usuário.

1. Desenvolvimento
Moderno de
Aplicações Android
Nelson Glauber
Android GDE
@nglauber

2. em 2018…

3. O que NÃO mudou?

4. Devemos nos preocupar
com a arquitetura
‣ Os mais diversos tipos de negócios são feitos pelo celular. Muitos deles
são mobile
fi
rst.
‣ A complexidade dos aplicativos continua a crescer.
‣ Por isso, o código tem que ser robusto, testável e deve facilitar a
manutenção e a adição de funcionalidades.

5. Arquitetura de um app
‣ Regra Principal: não há regras!
‣ Existem princípios que devem ser seguidos: S.O.L.I.D.
‣ Promove a organização e o desacoplamento do código.
‣ Deve facilitar a manutenção e a adição de funcionalidades.
‣ Deve ser testável!
‣ Ela incrementa a complexidade? Sim!
Vale à pena? Com certeza! 😎
Mas deve ser de conhecimento de toda à equipe.
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

6. UI
Presentation
Domain
Remote Local
Data

7. UI
Presentation
Domain
Remote Local
Data
‣ Use Cases
com regras
de negócio
‣ Plain objects

8. UI
Presentation
Domain
Remote Local
Data
‣ Repositórios
‣ Data Sources
‣ Data Models

9. Screen ViewModel UseCase Repository
Chama funções do
view model
Observa mudanças
nos Flows
expostos pelo
ViewModel
Contém lógica da
tela
Chama o Use Case
e expõe estado da
UI por meio de um
StateFlow
Atua como uma
camada reusável
para os
ViewModels
Contém validação
de negócio
Comunica com os
repositórios
Responsável por
gerenciar os
dados: salvar e
obter dados
Eventos de UI
observa
mudança
de estado
checa as regras de
validação do negócio
atualiza o
estado
salva/obtém
dados
converte e
retorna o
Resultado

10. O que mudou?

11. UI
Presentation
Domain
Remote Local
Data
‣ Jetpack Compose
‣ Navigation Library
‣ ViewModel
‣ Hilt*

12. io.google/2023/program

13. +280 milhões de dispositivos com telas
grandes e foldables ativos

14. Por que telas grandes?
‣ Fazer seu app se destacar em telas grandes apresenta uma grande
oportunidade de negócio.
‣ Quanto mais bem avaliado seu aplicativo for em um dispositivo, mais ele
será recomendado no Google Play em dispositivos da mesma categoria.
‣ Adaptar o seu app para telas grandes melhora signi
fi
cativa nas métricas
centrais de negócios.
‣ Mais usuários ativos, sessões mais longas, médias de avaliação do app
mais altas e aumento do engagamento.

15. Adapte seu app para telas grandes
‣ Mais de 50 aplicativos do Google já
estão otimizados para telas grandes.
‣ Se estiver procurando inspiração para
o seu app, dê uma olhada nos
aplicativos do Google.

16. https://developer.android.com/large-screens/gallery

17. Experiência diferenciada
Feed
List/Detail Supporting Pane

18. Experiência diferenciada
‣ Usuários gostam de ter uma experiência diferenciada em dispositivos
maiores.
‣ Isso signi
fi
ca adotar layouts especí
fi
cos para telas grandes e pensar em
uma UX diferenciada.
‣ Ex: Multi-pane layout, modo multi-window e tabletop feature (em
foldables).

19. Compatibilidade em telas grandes
‣ Os usuários esperam que as aplicações funcionem de forma natural no seu
dispositvo:
‣ Em tablets e alguns ChromeBooks, os usuários esperam utilizar a
aplicação com teclado físico, mouse, trackpad ou stylus.
‣ Em foldables, existem ainda mais oportunidades para explorar as
possibilidades de usar as cameras internas e externas ao mesmo
tempo.
‣ Implementar esses tipos de experiências farão seu app se destacar.

20. Principais problemas…
‣ Restringir o tamanho da tela:
‣ Dando suporte a apenas
uma orientação.
‣ Marcando o aplicativo
como não
redimensionável.
‣ Restringindo o aspect
ratio.

21. Recomendação
‣ Não estabelecer restrições
de orientação ou
redimensionamento de tela.
‣ Adicionar essas restrições
não é a maneira de evitar o
ciclo de vida da aplicação.

22. Modo Compatibilidade
‣ No Android 13, foi introduzido um
modo para deixar seu app funcional
em telas grandes: o modo de
compatibilidade.
‣ A partir do Android 12L, se uma
restrição for aplicada e a
con
fi
guração do dispositivo não for
compatível, o sistema colocar o
aplicativo no modo
compatibilidade, que basicamente
deixará seu app centralizado com
uma tela preta ao fundo.

23. Modo Compatibilidade
‣ Esse modo permite que o app
funcione em todas as orientações e
no modo multi-window, que é uma
funcionalidade essencial em telas
grandes.
‣ As mudanças de con
fi
guração
serão recebidas da mesma forma.
‣ O sistema vai garantir a correta
orientação da câmera independente
de onde ela esteja
fi
sicamente
instalada no aparelho.

24. Checklist de Qualidade para tela grande
‣ Camada 3 - Pronto para tela grande: Usuários podem completar
fl
uxos
críticos com uma experiência menor que a ideal. App não deve estar no modo
de compatibilidade e tem que prover um suporte básico para mouse, teclado
e trackpad.
‣ Camada 2 - Otimizado para tela grande: O app implementa otimizações de
layout para todos os tamanhos de tela e con
fi
gurações de aparelhos, bem
como uma melhoria para teclado, mouse e trackpad.
‣ Camada 1 - Diferenciado para tela grande: Seu app provê uma UX
desenhada para tablets, foldables e Chrome OS. Onde aplicável, o app
suporta multi-tasking, posturas de foldables, drag and drop e suporte a stylus.
https://goo.gle/large-screen-quality

25. Window Size
Classes
goo.gle/windows-size-class-views
goo.gle/windows-size-class-compose
height > 900
480dp ≤ height < 900
height < 480

26. Window Size Classes
Compact Medium Expanded

28. Material You
‣ É a mais recente evolução do Material Design.
‣ Material Design 3 (M3) incorpora o guia de design do Material You.
‣ M3 é um poderoso e
fl
exível design system que permite con
fi
gurar cores,
formas e fontes customizadas.
‣ M3 permite a utilização de cores dinâmicas, tanto para light quanto para dark
mode.
‣ M3 é o design system recomendado para telefones, tablets e foldables.
‣ Inclusive é o design system padrão ao criar um novo projeto Android.

29. Compose Material 3
‣ Novos Componentes 🎉
‣ BottomSheetScaffoldLayout,
ModalBottomSheet
‣ DatePicker, DateRangePicker, TimePicker
‣ CenterAlignedTopAppBar, TopAppBar,
MediumTopAppBar, LargeTopAppBar
‣ NavigationBar, NavigationRail,
ModalNavigationDrawer,
DismissibleNavigationDrawer e
PermanentNavigationDrawer
‣ Tooltips

31. Continuidade em telas grandes

32. Continuidade em telas grandes
‣ Usuários tendem a usar dispositivos de telas grandes em diferentes
orientações, segura-lo dobrado ou desdobrado (foldables), no modo multi-
window, e no modo free-form (Chromebook).
‣ Usuários esperam que a aplicação funcione de forma
fl
uida em todas essas
variações.
‣ Para o desenvolvedor, é preciso tratar mais mudanças do que normalmente
é feito nos telefones tradicionais.
‣ Garantir que a aplicação salva corretamente o seu estado quando essas
mudanças de con
fi
guração ocorre é um fator chave para uma agradável UX.

34. Repitam comigo:
"É impossível evitar TODOS os casos
em que a activity deve ser recriada.”
Algumas con
fi
gurações SEMPRE
recriarão a activity.

35. Sua activity pode ser destruída por…

36. Mudança de con
fi
guração
‣ Quando a aplicação está em execução e ocorre
uma mudança de con
fi
guração, a activity é
recriada com a nova con
fi
guração.
‣ Essas con
fi
gurações podem ser:
‣ Orientação da tela (portrait/landscape)
‣ Redimensionar a janela (Chromebook)
‣ Entrar ou sair do modo multi-window
‣ Alternar entre os modos Light e Dark.
‣ Entre outros…

37. Mudança de con
fi
guração
‣ View Model
‣ Recomendação do Google para manter o estado da UI, pois é o única maneira
suportada (o
fi
cialmente) para que objetos arbitrários sobrevivam às mudanças de
con
fi
guração.
‣ É mantido em memória
‣ Limitado apenas pela quantidade de memória do aparelho
‣ Muito rápido para ler/escrever os dados
‣ A biblioteca de navegação faz o cache dos View Models caso eles estejam na
backstack

38. Sistema precisa de recursos
‣ Quando sua aplicação está em background
e o sistema precisa de recursos.
‣ Quando o sistema está
fi
cando sem
memória, ele fará o possível para manter
seu app em memória, mas isso não é
garantido
‣ O S.O. pode “matar" a aplicação para liberar
memória, tendo em vista que o usuário está
interagindo com outras aplicações.🤷

39. Sistema precisa de recursos
‣ Saved State APIs é baseado na Bundle API e possui opções pra Compose, View system e View
Model
‣ Sobrevive às mudanças de con
fi
guração e quando o sistema necessita de recursos.
‣ Os dados são armazenados em memória, mas caso haja necessidade, são persistidos em arquivo.
‣ Tem um tamanho limitado. A recomendação é não exceder 50Kb
‣ A leitura/escrita pode ser lenta dependendo da complexidade do que está sendo armazenado
‣ Não armazene objetos grandes ou listas! O processo de serialização e deserialização é feito na
main thread!
‣ Armazene dados transientes que dependem da navegação ou input do usuário, como: posição do
scroll, ID do item na tela de detalhes, texto de um input do usuário, etc.

40. Saved State APIs
‣ Jetpack Compose
‣ rememberSaveable
‣ Teste com StateRestorationTester
‣ View system
‣ onSaveInstanceState
‣ Teste com ActivityScenario.recreate()
‣ View Model
‣ SavedStateHandle (a informação só é salva no onStop)

41. Encerramento inesperado
‣ O usuário ou o S.O. pode encerrar a
aplicação abruptamente.
‣ O usuário pode remover a aplicação do
menu de recentes.
‣ Forçar a parada nas con
fi
gurações do
aparelho.
‣ A aplicação pode ter sido atualizada em
background.

42. Encerramento inesperado
‣ Armazenamento persistente sobrevive às três formas de perder estado (mudança
de con
fi
g., necessidade de recursos do sistema e o fechamento inesperado).
‣ Data Store: Para dados simples e pequenos
‣ Room: Para dados mais complexos
‣ Os dados são armazenados “em disco” limitando sua capacidade ao espaço
disponível no dispositivo.
‣ Como necessita realizar operações de I/O, é mais lento
‣ Deve armazenar dados da aplicação, não de UI!

43. Ferramentas de Teste

44. Emuladores
‣ Use o Foldable emulator para testar como sua aplicação funciona ao
dobrar e desdobrar o aparelho.
‣ Use o Freeform/Desktop emulator (Chromebook) para testar o
redimensionamento da janela do aplicativo, minimizar, maximizar, eventos
de mouse (hover, right-click, scroll, scroll-to-zoom) e teclado físico.
‣ Resizable emulator é um "3 em 1": phone, tablet e unfolded foldable

45. Multi Previews for Jetpack Compose
annotation class Preview(
val name: String = "",
val group: String = "",
@IntRange(from = 1) val apiLevel: Int = -1,
val widthDp: Int = -1,
val heightDp: Int = -1,
val locale: String = "",
@FloatRange(from = 0.01) val fontScale: Float = 1f,
val showSystemUi: Boolean = false,
val showBackground: Boolean = false,
val backgroundColor: Long = 0,
@UiMode val uiMode: Int = 0,
@Device val device: String = Devices.DEFAULT,
@Wallpaper val wallpaper: Int = Wallpapers.NONE,
)

46. Multi Previews for Jetpack Compose
@DeviceSizePreviews
@Composable
fun GreetingPreview() {
val (w, h) = with(LocalConfiguration.current) {
screenWidthDp.dp to screenHeightDp.dp
}
MyApp(WindowSizeClass.calculateFromSize(DpSize(w, h)))
}
@Preview(showSystemUi = true, widthDp = 700)
@Preview(showSystemUi = true, device = “spec:width=800dp,height=1280dp,dpi=480")
@Preview(showSystemUi = true, device = "id:pixel_5")
@Preview(showSystemUi = true, device = "id:7.6in Foldable")
@Preview(showSystemUi = true, device = "id:medium_tablet")
@Preview(showSystemUi = true, device = "id:desktop_medium")
annotation class DeviceSizePreviews

48. Automated Testing Tools
‣ É possível usar Gradle Managed Devices para iniciar emuladores com
con
fi
gurações diferentes e rodar a suíte de testes em todos eles.
‣ Diferentes dispositivos necessitam de testes baseado no tamanho da tela.
Mas como de
fi
nir os testes que serão executados em cada device? 🤔

49. Automated Testing Tools

50. Espresso Device API
‣ Permite controlar o emulador diretamente do código de teste. Pode-se usar
telefones, tablets, foldables rodando Android API 24 ou superior.
‣ Com essa API é possível de forma síncrona: rotacionar, dobrar/desdobrar e
redimensionar o dispositivo durante o teste. Garantindo que seu aplicativo
trata as mudanças de con
fi
guração corretamente.
‣ Permite de
fi
nir regras para que não sejam executados testes em
dispositivos onde o teste certamente falhará. Por exemplo: não executar
testes de dobrar/desdobrar em dispositivos que não sejam foldables.

51. Emulador 33.1.10

52. @RunWith(AndroidJUnit4::class)
class ScreenOrientationTest {
@get:Rule(order = 0)
val composeTestRule = createAndroidComposeRule<MainActivity>()
@get:Rule(order = 1)
val screenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)
@Test
@RequiresDeviceMode(DeviceMode.FLAT)
fun screenOrientationShowRightPanel() {
onDevice().setScreenOrientation(ScreenOrientation.PORTRAIT)
composeTestRule.onNodeWithTag("leftPanel").assertIsDisplayed()
onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
composeTestRule.onNodeWithTag("rightPanel").assertIsDisplayed()
}
Activity deve exibir
o conteúdo

53. @Test
@RequiresDeviceMode(DeviceMode.FLAT)
fun foldUnfold() {
onDevice()
.setScreenOrientation(ScreenOrientation.PORTRAIT)
.setClosedMode()
composeTestRule.onNodeWithTag("leftPanel").assertIsDisplayed()
composeTestRule.onNodeWithTag("rightPanel").assertDoesNotExist()
onDevice()
.setScreenOrientation(ScreenOrientation.PORTRAIT)
.setFlatMode()
composeTestRule.onNodeWithTag("leftPanel").assertIsDisplayed()
composeTestRule.onNodeWithTag("rightPanel").assertIsDisplayed()
}
Teste não será
executado em dispositivos
que não suportam o modo
fl
at.
Isso pode ser
de
fi
nido por teste ou
por classe de teste

54. Save Restoration Tester - Compose

55. Save Restoration Tester - Compose
@RunWith(AndroidJUnit4::class)
class SaveRestoreStateTest {
@get:Rule(order = 0)
val composeTestRule = createAndroidComposeRule<ComponentActivity>()
@OptIn(ExperimentalMaterial3WindowSizeClassApi::class)
@Test
fun testDeviceSaveState() {
val stateRestorationTester = StateRestorationTester(composeTestRule)
stateRestorationTester.setContent {
val (w, h) = with(LocalConfiguration.current) { screenWidthDp.dp to screenHeightDp.dp }
MyApp(WindowSizeClass.calculateFromSize(DpSize(w, h)))
}
composeTestRule.onNodeWithText("Counter 0").assertIsDisplayed()
composeTestRule.onNodeWithText("Add").performClick()
composeTestRule.onNodeWithText("Counter 1”).assertIsDisplayed()
stateRestorationTester.emulateSavedInstanceStateRestore()
composeTestRule.onNodeWithText("Counter 1").assertIsDisplayed()
}
}

56. TestHarness – Compose

57. TestHarness – Compose
@RunWith(AndroidJUnit4::class)
class ScreenWithHarness {
@get:Rule
val composeTestRule = createAndroidComposeRule<ComponentActivity>()
@OptIn(ExperimentalMaterial3WindowSizeClassApi::class)
@Test
fun testSpecificScreenSize() {
composeTestRule.setContent {
val size = DpSize(840.dp, 600.dp)
TestHarness(
size = size
) {
MyApp(WindowSizeClass.calculateFromSize(size))
}
}
composeTestRule.onNodeWithTag("leftPanel").assertIsDisplayed()
composeTestRule.onNodeWithTag("rightPanel").assertIsDisplayed()
}
}

58. Screenshot tests
‣ Como feature experimental do Android Gradle Plugin será possível
converter os Previews dos Composables do Android Studio em imagens
de referência para testes de screenshot.
‣ Os screenshots
fi
carão em
Projeto/app/src/screenshotTest
‣ O comando do Gradle gerará as imagens de referência baseado nos
@Preview

60. Misc.

61. Jetpack Glance
• O Jetpack Glance é um framework sobre
o Compose que permite desenvolver e
projetar widgets.
• https://developer.android.com/jetpack/
compose/glance

62. Compose for TV (Alpha)
• Componentes especí
fi
cos pra TV
• TvLazyRow, TvLazyGrid,
TvLazyColumn, SideNavigation,
Content Cards, Carousel,
ImmersiveList, etc.

63. Compose for Wear OS

64. Kotlin DSL for Gradle Builds
‣ KTS é o padrão no Android Studio Giraffe
‣ KTS + Version Catalog é uma opção (experimental)

65. KSP no lugar do KAPT

66. io.google/2023/program

67. Obrigado!
Dúvidas?
Nelson Glauber
Android GDE
@nglauber