Fluxo de carga do perfil e das roles (carga normal)
Cenário: usuário já logado (ex.: perfis Visitante e Membro), abre o app e depois abre o diálogo de perfil.
1. Carga inicial (Home)
| Ordem | Ação | Onde | HTTP / efeito |
|---|---|---|---|
| 1 | initState() | HomePage | — |
| 2 | _loadMyProfile() inicia | HomePage | — |
| 3 | setState(_isLoadingProfile = true) | HomePage | UI mostra "Consultando perfil..." |
| 4 | await service.loadProfile() | UserProfileService → ProfileRepository | 1 GET myProfileHttp (perfil do backend) |
| 5 | Perfil em memória (profileNotifier), setState() | HomePage | UI mostra nome, avatar, etc. |
| 6 | _preloadRoleCatalog() (sem await) | HomePage | Dispara em background |
| 7 | ensureFullCatalogLoaded() | RoleCatalogService | 1 POST userGatewayHttp action USER_ROLES_AVAILABLE_LIST com fullCatalog: true (em background) |
| 8 | setState(_isLoadingProfile = false) | HomePage | Fim do loading do perfil |
O preload do catálogo completo (7) não bloqueia a tela; quando termina, o cache "full" fica preenchido para uso no diálogo.
2. Usuário abre o diálogo de perfil
| Ordem | Ação | Onde | HTTP / efeito |
|---|---|---|---|
| 1 | Diálogo abre com widget.profile | ProfileDialog | Perfil já vem da Home (em memória) |
| 2 | _applyProfileState(widget.profile) | ProfileDialog | Preenche campos e estado local (síncrono) |
| 3 | postFrameCallback dispara | ProfileDialog | — |
| 4 | _loadChurchOptions() inicia (async) | ProfileDialog | — |
| 5 | _loadAvailableRoles() inicia (async) | ProfileDialog | — |
As duas cargas (igrejas e roles) rodam em paralelo.
3. _loadChurchOptions() (em paralelo com roles)
| Ordem | Ação | HTTP / efeito |
|---|---|---|
| 1 | setState(_loadingChurchOptions = true) | UI pode mostrar loading de igrejas |
| 2 | await getSignupChurchOptions.execute() | 1 chamada (HTTP/use case) para lista de igrejas |
| 3 | setState(_churchOptions = ...) | Dropdown de igreja preenchido |
| 4 | _loadAvailableRoles() chamado de novo | Ver fluxo de roles abaixo (pode ser segunda execução) |
| 5 | setState(_loadingChurchOptions = false) | — |
4. _loadAvailableRoles() (origem do atraso na aba “Perfil na EBD”)
| Ordem | Ação | HTTP / efeito |
|---|---|---|
| 1 | setState(_loadingRoleCatalog = true) | UI mostra "Carregando papéis habilitados..." na aba Perfil na EBD |
| 2 | await ensureFullCatalogLoaded() | 0 ou 1 POST: 0 se o preload da Home já encheu o cache "full"; 1 se ainda não (action USER_ROLES_AVAILABLE_LIST, fullCatalog: true) |
| 3 | await getAvailableRoleCatalog(unitId, requesterRole) | 1 POST USER_ROLES_AVAILABLE_LIST (lista eligível para unitId + requesterRole, ex.: Visitante/Membro) |
| 4 | setState(_availableRoleCatalog = catalog, ...) | Dropdown "Cargo desejado" e rótulos (incl. "Cargo atual") preenchidos |
| 5 | setState(_loadingRoleCatalog = false) | Fim do loading de roles |
As duas chamadas (catálogo completo e lista eligível) rodam em paralelo (Future.wait), então o tempo de espera é o máximo dos dois, não a soma.
Observação: _loadAvailableRoles() pode ser chamada duas vezes (uma no postFrameCallback e outra ao terminar _loadChurchOptions()). A segunda execução reutiliza cache quando possível.
5. Onde está o atraso
- Perfil: atraso só na Home até o primeiro
loadProfile()terminar (um GET). O diálogo não faz nova carga de perfil; usa o que já está em memória. - Roles: o atraso visível é na aba “Perfil na EBD”:
- Enquanto
_loadingRoleCatalog == trueaparece "Carregando papéis habilitados...". - Isso dura pelo menos:
ensureFullCatalogLoaded()(se precisar de 1 POST) +getAvailableRoleCatalog()(1 POST), em série.
- Enquanto
- Para usuário Visitante ou Membro, o backend usa
unitIderequesterRole(ex.: VISITOR ou MEMBER) para filtrar a lista eligível; o catálogo completo é usado para ter todos os rótulos (ex.: "Visitante", "Membro") em memória sem atraso depois que o cache está cheio.
6. Otimização aplicada
As duas cargas de roles no diálogo passam a rodar em paralelo:
ensureFullCatalogLoaded()egetAvailableRoleCatalog(unitId, requesterRole)são disparadas juntas (ex.:Future.waitou equivalente).- A UI só sai de "Carregando papéis habilitados..." quando as duas tiverem terminado, mas o tempo de espera fica próximo do máximo dos dois tempos (em geral um único RTT de rede), em vez da soma dos dois.
Assim, o fluxo de carga do perfil continua o mesmo; o fluxo de roles no diálogo fica mais rápido e o atraso na tela diminui.