Almacenar el token de usuario, si el token no es válido: la página de inicio de session actual,

Aprendizaje de la progtwigción de iOS Swift y me gusta saber cómo implementar el process de inicio de session de usuario .

El mecanismo backend-iOS es el siguiente:

  • Inicio de session de usuario con correo electrónico y contraseña,
  • El Servidor devuelve el token de usuario y el ID de usuario
  • En requestes posteriores, el token de usuario y la ID de usuario se envían para search datos / trabajar con la aplicación.

Tengo dudas en la implementación de iOS.

  1. Almacenará el token de usuario y el ID de usuario en los datos centrales. ¿Habrá alguna lentitud si obtengo el token de usuario en cada pantalla de Core Data?
  2. Si el token de inicio de session expira o es inválido en cualquier pantalla, ¿cómo volver a la página de inicio de session? ¿Debería verificarme la salida JSON y tener el código "present login VC" en cada pantalla? ¿Alguna forma aerodinámica para resumir el código a un file táctil Swift o Cocoa?

En realidad, hay muchos enfoques. Todo depende de ti, cómo lo manejarás. Puedo señalarle dos ejemplos, cómo lo gestiono solo.

Usando NSOperation .

Hubo una session increíble sobre WWDC 2015, sobre NSOperations avanzadas. Aquí está.

Básicamente, crea una subclass de NSOperaton y hace que otras operaciones dependan de ella. En su caso, tendrá la operación de inicio de session de usuario, y todas las demás operaciones dependerán del inicio de session del usuario (por supuesto, solo los que lo necesitan). Si tiene éxito, entonces la operación se ejecutará. En la operación de inicio de session del usuario, verificará, si el usuario ya inició session, y tiene un token, si no, presente la pantalla de inicio de session.

También hay una impresionante biblioteca llamada Operations , basada en esa charla de WWDC. Aquí está.

Usando PromiseKit .

Aquí hay otro, usando PromiseKit . No es realmente una gran diferencia de las operaciones, pero, en mi opinión, un poco más simple. Crea una Promise que garantiza que ingresó. Es muy simple hacer una cadena de promises, por lo que promete un inicio de session de usuario y encadenar cualquier otra cosa. Si el inicio de session tiene éxito, la cadena de promises continúa ejecutándose.

Todo se basa en otra impresionante biblioteca, PromiseKit . Aquí está

Es muy potente y muy simple de usar, una vez que entiendes la cosa. Está muy bien documentado y tiene un montón de tutoriales aquí .

Hay muchos otros enfoques, por lo que puede elegir cualquiera de ellos, y combinar uno con el otro como más le guste.

Al hacer tu primera pregunta, la haces asíncrona, por lo que no es tanto lo que importa la lentitud de CoreData como la request web.

1 – bueno, sí, un poco. Pero dudo que note un retraso o cualquier cosa: CoreData es realmente rápido y no requerirá mucho time para search solo un object. Alternativamente, su object CoreData que contiene estos datos (llamémoslo User ) puede ser una propiedad de su subclass de UIApplicationDelegate (llamémoslo MyAppDelegate ). Usted obtendrá este User en - application:didFinishLaunchingWithOptions: y lo actualiza en login / logout / expire / etc. De esta forma, puede acceder a él desde cualquier lugar y no necesita searchlo desde CoreData en cualquier momento que lo necesite.
Además, en lugar de CoreData puedes usar iOS Keychain. (Aquí hay un tutorial que podría ayudar con esto).

2 – de nuevo, puede usar MyAppDelegate . Por ejemplo, puede agregarle un método, que saveá el estado de navigation actual y cambiará el controller raíz de UIWindow a su LoginViewController . O presentará LoginViewController sobre el controller actual. Después de iniciar session con éxito, devolverá la stack de navigation al estado anterior.
También puede mover este código a algún tipo de NavigationController – class que se encargará de esta situación. Tendrá algo así como func checkToken(Dictionary response, UIViewController currentController) -> Bool . Si el token es válido, simplemente devuelve true , y si no, devuelve false y maneja la navigation a LoginViewController , y después de iniciar session – de nuevo a currentController . Este NavigationController puede ser propiedad de MyAppDelegate , puede ser singleton, creado cada vez que lo necesite, o puede pasarlo junto a cada UIViewController que muestre.