Sto per iniziare a lavorare su un V2 di un'applicazione mobile e mi piacerebbe adottare un approccio più incentrato sugli oggetti. Soprattutto perché penso che sia un codice più gestibile, ma un vantaggio secondario è la facilità di testabilità.
V1 dell'app è piuttosto incentrato sul controller. Login ViewController ha i suoi campi di login e raggiunge il back-end tramite AFNetworking, segnala errori se necessario e riceve un token che viene archiviato in modo sicuro per un uso successivo.
C'è sempre un solo utente. Quando l'utente si disconnette, tutti i dati locali vengono eliminati, quindi in sostanza l'utente corrente è "globale" e può essere nullo (è necessario un accesso) oppure no (non).
La situazione è complicata naturalmente dall'idea di scadenza del token. Sostanzialmente qualsiasi richiesta di rete (GET espliciti o POST asincroni ritardati) può fallire perché il token è scaduto e vogliamo che l'utente effettui nuovamente l'autenticazione.
Il modello V1 di una schermata di accesso all'avvio se non c'è un utente corrente non si estende facilmente a questo modello e, mi sembra, mi manca un oggetto in qualche modo che instrado tutto attraverso. Un Authenticator che fornisce un token o apre la schermata di login se non ne possiede uno.
Quindi potremmo fare qualcosa di simile: quando una richiesta fallisce, cancelliamo il token corrente e riproviamo la richiesta. La richiesta chiede all'autenticatore il token e l'autenticatore chiede all'utente.
O qualcosa.
Come potrebbe essere meglio modellato?
Mi sembra che il codice debba essere centralizzato, ma è difficile visto che le richieste vengono utilizzate in tutte le app. È quasi come un livello filtro necessario per gestire centralmente gli errori di autenticazione, ma altri errori / successi ovunque siano necessari (in un blocco riuscito / non riuscito).