Driver — Viagem Ativa

Módulo exclusivo para usuários com papel motorista. Exibe a viagem ativa com navegação assistida, botões de gerenciamento (iniciar, pausar, finalizar) e rastreamento de localização em tempo real.

Fragmentos do Módulo

Viagem Ativa

O motorista visualiza apenas a viagem atribuída a ele. Os dados são buscados via GET /v1/trips?driver_id=... ou a viagem específica quando há uma em andamento. O fragment usa o DriverTripViewModel para gerenciar o estado.

Gerenciamento de Viagem

Rastreamento de Localização

Para usuários com papel motorista, o HomeFragment.onResume() solicita permissões de localização em foreground e background. A posição GPS é enviada ao backend periodicamente via serviço de background (FusedLocationProviderClient).

// Verificação de papel no onResume
if (userRole == "motorista") {
    requestForegroundLocationPermission()
    requestBackgroundLocationPermission()
}

Navegação Turn-by-Turn (NavigationManager1)

O NavigationManager1 conduz a navegação assistida no mapa (OSMDroid) com instruções faladas via TextToSpeech. Cada instrução é um NavigationInstruction, montado a partir de rotogram_instruction da API. A rota e as alternativas vêm do endpoint consolidado GET /v1/rotograms/trip/{tripId}?_detail=true (ver Mapa). O campo type_id mapeia o ícone/voz da manobra:

As coordenadas da instrução vêm como [lng, lat] (ordem GeoJSON) — latitude = coordinates[1], longitude = coordinates[0].

Cache Offline da Sessão (DriverSessionCache)

O DriverSessionCache é o equivalente Android do DriverCacheManager do iOS: guarda, num único blob por tripId_routeId, tudo que o motorista precisa para continuar a viagem sem rede.

Cada save* persiste o blob inteiro (mesmo padrão do iOS), então a sessão no disco é sempre consistente. A chave (driver_session_{tripId}_{routeId}, prefs driver_session_cache) é por viagem + rota para não misturar dados entre viagens que reusem a mesma rota. load() retorna false se não há cache para a viagem/rota.

Helpers relacionados desta entrega: TripCacheCleaner (limpeza de cache de viagens) e NavigationManager1 (consome as instruções cacheadas para navegar offline).

Comprovação de Entregas (canhotos)

Fluxo em que o motorista anexa o canhoto (comprovante) de cada entrega da rota. O backend é real: os canhotos enviados ficam no array delivery_receipts de cada entrega (deliveries[]) retornado pelo endpoint consolidado GET /v1/trip/{id}; o envio é um POST multipart. Existem três pontos de entrada para o mesmo conjunto de telas/render.

Pontos de entrada

Telas e render compartilhado

Endpoints

Campos de delivery_receipts[]

Câmera do canhoto (in-app)

Ao tocar em "Adicionar mais"/"Anexar Canhoto", o motorista escolhe num bottom sheet entre câmera e galeria. A opção câmera não usa mais o app de câmera do sistema: abre a câmera custom in-app CanhotoCameraActivity (CameraX), com helpers/CameraOverlayView.kt desenhando um overlay estilo scanner — a tela escurece (~65%) e abre uma moldura deitada (proporção de canhoto) centralizada, para o motorista enquadrar o documento. A galeria continua via GetContent.

Substituir e Remover Canhoto

Substituir: com ≥1 canhoto já enviado, o botão do detalhe vira "Substituir Canhoto". O toque abre um diálogo de confirmação (dialog_replace_doc.xml via DeliveryProofUi.confirmReplace) avisando que o canhoto atual permanece no histórico; ao confirmar, oculta os canhotos antigos e abre o seletor câmera/galeria. Lista de canhotos vazia = entrega pendente, botão "Anexar Canhoto".

Remover: cada canhoto enviado aparece numa lista com data/hora e uma lixeira. A lixeira (hideReceipt) apenas remove da lista visual — a imagem permanece salva no sistema (banco); o ocultamento é persistido localmente (hiddenPaths) para não reaparecer ao recarregar. O controle é gated pela flag SHOW_REMOVE em DeliveryDetailFragment (hoje false, aguardando a inativação/ocultação de documento no backend).

ViewModels e Arquitetura

SharedPreferences relevantes