Como testear Interceptores de Retrofit – Android

Hace poco veíamos como testear nuestra API con Retrofit en Android. Quedaron cosas por ver, así que hoy continuamos con más testing en Android.

Retrofit es una excelente librería que nos facilita la labor de llamar a nuestras APIs, a la vez que nos facilita herramientas para que el control sobre los procesos sea absoluto.

Uno de los mecanismos que nos proporciona son los interceptores. Estos son una capa de procesado que, tal como el nombre indica, interceptan las peticiones y las transforman. Pueden capturar tanto a la salida como a la entrada de la petición.

En mi caso, el uso que suelo darle es añadir parámetros de forma genérica a mis peticiones, por ejemplo, el token de usuario. Otro suele ser verificar si mi petición devuelve un código 401 y así intentar hacer un refresco de token.

En nuestra aplicación de ejemplo ya tenemos un interceptor que se encarga de añadir el apiKey necesaria a todas las peticiones, ApiKeyInterceptor, hoy crearemos un test para esta parte.

En un vistazo rápido a nuestra clase, por un lado ya estoy viendo un problema, y es que la clase necesita como parámetro el Context, esto en test unitarios de Android es un problema, ya que nos obligaría a tener tests instrumentados, y es difícil de Mockear. Así que lo que haremos será sustituir a este por algo que sea más sencillo de sustituir.

Siguiendo con la explicación de esta clase, esta implementa Interceptor, y para ello debe sobreescribir el método intercept, que será donde capturaremos la petición y la transformaremos a nuestro gusto. En este caso, añadimos un parámetro queryString a nuestra petición.

Así que, básicamente, esto es lo que testearemos, que dada una petición de entrada, su url de salida debe incluir el parámetro «api_key».

Antes de empezar haremos el cambio del Context. Simplemente en el constructor de ApiKeyInterceptor, lo cambiamos por la clase Configuration, que ya nos da el apiKey. Y sustituimos.

class ApiKeyInterceptor(private val configuration: Configuration): Interceptor {

Y dentro de la clase buscamos la siguiente línea

val apiKey: String = context.resources.getString(R.string.apikey)

Y sustituimos por la siguiente

val apiKey: String = configuration.apiKey

En AppModule, donde se definen las dependencias, debemos añadir Configuration a la hora de crear MovieService, que es quien utiliza nuestro interceptor.

@Singleton @Provides
    fun provideMovieService(@ApplicationContext appContext: Context, configuration: Configuration): MovieService {

....

httpClient.addInterceptor(ApiKeyInterceptor(configuration))
....

A continuación, creamos nuestro archivo de test.

@RunWith(JUnit4::class)
class ApiKeyInterceptorTest {

Y la estrategia para probar en este caso será, al igual que el artículo anterior, crear un servidor Mock, en este caso, también haremos una interface Mock para crear una petición que podamos controlar, y verificar finalmente que la request se forma correctamente.

Así que para no hacer más largo de lo necesario esto, lo que haré será copiar y pegar la parte de la creación del servidor mock de nuestro test anterior.

    private lateinit var mockWebServer: MockWebServer
    private val mainThreadSurrogate = newSingleThreadContext("UI thread")

   
    @Before
    fun createService() {
        Dispatchers.setMain(mainThreadSurrogate)

        mockWebServer = MockWebServer()

        service = Retrofit.Builder()
            .baseUrl(mockWebServer.url("/"))
            .addConverterFactory(GsonConverterFactory.create())
            .addCallAdapterFactory(ApiResponseCallAdapterFactory())
            .build()
            .create(MovieService::class.java)

    }

    @After
    fun stopService() {
        mockWebServer.shutdown()

        Dispatchers.resetMain()
        mainThreadSurrogate.close()
    }

    private fun enqueueResponse(fileName: String) {
        val inputStream = javaClass.classLoader
            ?.getResourceAsStream("api-response/$fileName")?.source()?.buffer()

        mockWebServer.enqueue(
            MockResponse()
                .setBody(inputStream!!.readString(Charsets.UTF_8))
        )
    }

Ahora mismo tiene que fallar, porque service no está definido, e incluso no será de tipo MovieService. Así que vamos a arreglar eso.

Fuera de nuestra clase de test, crearemos una interface TestService, y definimos una petición GET. Devolverá un objeto ApiObjectTest, que también definiremos aquí.

data class ApiObjectTest(val data: String)

interface TestService {
    @GET("test_request")
    suspend fun testRequest(): ApiResponse<ApiObjectTest>
}

Una vez tenemos esto, acabamos de definir nuestro service. Definimos a nivel de clase un testService.

private lateinit var testService: TestService
Y en el método createService corregimos como lo definimos. Cambiamos el nombre y al final, debemos indicarle que nuestras peticiones están definidas en TestService.
testService = Retrofit.Builder()
            .baseUrl(mockWebServer.url("/"))
            .addConverterFactory(GsonConverterFactory.create())
            .addCallAdapterFactory(ApiResponseCallAdapterFactory())
            .build()
            .create(TestService::class.java)

Aquí nos falta otra cosa, que es añadir nuestro interceptor. En los tests anteriores lo eliminamos porque no queríamos que interfirieran en nuestros tests, pero en este caso, queremos ver que efectos tienen.

Así que otra vez más en createService, vamos a instanciar nuestro interceptor y añadirlo a testService. La forma de hacerlo es muy similar a como lo hacemos en AppModule.

        val httpClient = OkHttpClient.Builder()
        
        val interceptor = ApiKeyInterceptor(configuration)
        httpClient.addInterceptor(interceptor)

        testService = Retrofit.Builder()
            .baseUrl(mockWebServer.url("/"))
            .addConverterFactory(GsonConverterFactory.create())
            .addCallAdapterFactory(ApiResponseCallAdapterFactory())
            .client(httpClient.build())
            .build()
            .create(TestService::class.java)

Si tenéis esto ya integrado, os daréis cuenta que falla porque configuration no está definido, vamos a solucionarlo.

Por un lado lo definimos a nivel de clase

private lateinit var configuration: Configuration

Y después, en createService, creamos un mock. Además, le decimos que cuando pidamos el apiKey devuelva el valor que necesitemos. Esto último lo podemos hacer aquí, o si necesitamos valores diferentes en cada test, podemos hacerlo a nivel de cada test.

        configuration = Mockito.mock(Configuration::class.java)
        Mockito.`when`(configuration.apiKey).thenReturn("my_api_key")

Para acabar las preparaciones, vamos a crear un archivo «test.json» dentro de la carpeta api-response de resources.

Y será un json muy sencillo, que debe conformar la estructura de ApiObjectTest.

{
  "data": "Esta es mi respuesta mock"
}

Vale, ahora ya podemos empezar a testear. Creamos nuestro test, y como siempre que tenemos coroutines, lo creamos con runBlocking.

@Test
fun `Check if is added Query Parameter Api Key OK`() = runBlocking(Dispatchers.Main) {
        
} 

En nuestro test, empezamos indicando al servidor que respuesta debe devolver, en este caso, será nuestro archivo test.json

enqueueResponse("test.json")

A continuación, ejecutamos nuestra petición mock con testService.testRequest() y con nuestro servidor mock recogemos el resultado con takeRequest

val data = testService.testRequest()

val request = mockWebServer.takeRequest()

Y por último, verificamos que el path que nos devuelve request, es el correcto, con el parámetro queryString del api Key.

MatcherAssert.assertThat(request.path, CoreMatchers.`is`("/test_request?api_key=my_api_key"))

Y con esto podemos estar seguros de que nuestras peticiones siempre llevarán el parámetro api key.

Por último, voy a hacer rápidamente un segundo test, añadiendo un parámetro queryString a la petición.

En TestService añado una segunda petición

@GET("test_request_param")
    suspend fun testRequestParam(@Query("param1") param1: String): ApiResponse<ApiObjectTest>

Después copio y pego el primer test y hago los cambios necesario para llamar a esta segunda petición, quedando de la siguiente forma.

@Test
    fun `Check if is added Query Parameter With param Api Key OK`() = runBlocking(Dispatchers.Main) {
        enqueueResponse("test.json")

        val data = testService.testRequestParam("custom_param")

        val request = mockWebServer.takeRequest()

        MatcherAssert.assertThat(request.path, CoreMatchers.`is`("/test_request_param?param1=custom_param&api_key=my_api_key"))
    }

Y de esta forma, hemos añadido un caso más, el cual nos dará más seguridad.

Al principio he comentado que uso los interceptores para renovar el access token. Este artículo ya se acaba aquí, pero será algo que abordaremos con total seguridad.

Como testear nuestra API Retrofit en Android

Cuando utilizamos un API nos estamos conectando a un sistema externo. Este puede cambiar en cualquier momento y ser un punto de fricción importante.

Al final un API debería seguir un contrato, en el cual el equipo de desarrollo se compromete a devolver los datos estructurados de una determinada forma.

Hoy veremos como podemos desde el lado de nuestras aplicaciones verificar que dada una respuesta determinada de un API, nuestra aplicación la llama, recibe y procesa de una determinada forma.

https://youtu.be/dY6zRH04meA

Como hasta ahora, seguimos con nuestra aplicación de ejemplo, y antes de empezar a testear, veremos que es lo que queremos testear y como.

Dado que lo que nos interesa testear es como se van a pasar los datos del API a nuestra aplicación, vamos a testear las peticiones a nuestra API. Pero al ser test unitarios, no debemos depender de que nuestra API esté siempre disponible y por eso lo que haremos será simular un servidor que nos de en cada test la respuesta que necesitamos.

Empezamos creando el archivo para nuestro test al que llamaremos MovieServiceTest

En resources, además, crearemos una carpeta api-response, aquí crearemos archivos json que simularán la respuesta que mandaremos desde nuestro servidor mock. He creado un archivo para el listado de películas y otro para el detalle de una película. Y para tener un ejemplo de cada uno, lo que hago es, con Postman o alguna herramienta similar, hago una petición real al listado de películas, copio el json de la respuesta y la pego en el archivo popular_movies.json.
Volviendo a nuestro archivo de test, empezamos creando el servidor mock. Para ello definimos una propiedad en la clase MovieServiceTest para nuestro servidor, además, también creamos otra para la interface que vamos a testear, MovieService.
private lateinit var mockWebServer: MockWebServer
private lateinit var service: MovieService

Y en el Before del test inicializamos el servidor y MovieService. Para el caso de MovieService, se inicializa prácticamente igual que en el caso de uso real, salvo que la url base cambia, y no incluimos los interceptores que podamos tener para que no interfieran en el test (los interceptores los testearemos aparte).

    @Before
    fun createService() {
  

        mockWebServer = MockWebServer()

        service = Retrofit.Builder()
            .baseUrl(mockWebServer.url("/"))
            .addConverterFactory(GsonConverterFactory.create())
            .addCallAdapterFactory(ApiResponseCallAdapterFactory())
            .build()
            .create(MovieService::class.java)

    }

Al acabar el test, en el After, lo que haremos será apagar el servidor.

    @After
    fun stopService() {
        mockWebServer.shutdown()
    }

Para simular nuestras peticiones, haremos un método que lea un archivo dado, y le diga a nuestro servidor mock que lo sirva. Para ello, una vez obtenido el archivo json que queremos, lo devolverá nuestro mockWebServer en el body.

private fun enqueueResponse(fileName: String) {
        val inputStream = javaClass.classLoader
            ?.getResourceAsStream("api-response/$fileName")?.source()?.buffer()

        mockWebServer.enqueue(
            MockResponse()
                .setBody(inputStream!!.readString(Charsets.UTF_8))
        )
    }

Vamos ahora con nuestro test. Para ello creamos un método nuevo en la clase MockServiceTest, y dado que tenemos que probar una función suspendida, debemos ejecutar el test con runBlocking, de este modo.

    @Test
    fun `Load Popular Movies OK`() = runBlocking(Dispatchers.Main) {

Lo siguiente que haremos en nuestro test, es preparar los datos. Lo haremos con nuestra función para mockear respuestas, así que añadimos a nuestro test una llamada a enqueueResponse pasándole por parámetro el nombre del archivo json que necesitamos que se responda, en este caso «popular_movies.json».

    @Test
    fun `Load Popular Movies OK`() = runBlocking(Dispatchers.Main) {
        enqueueResponse("popular_movies.json")

Ahora, ejecutamos la función a testear y obtenemos los datos a verificar. En este caso testeamos el método popularMovies, en data tendremos la respuesta que verificaremos y con mockWebServer.takeRequest tendremos datos sobre la petición.

    @Test
    fun `Load Popular Movies OK`() = runBlocking(Dispatchers.Main) {
        enqueueResponse("popular_movies.json")

        val data = service.popularMovies()

        val request = mockWebServer.takeRequest()

        val result = (data as ApiSuccessResponse).body

Ahora añadimos una comprobación bastante simple, verificar que nuestra petición se hace a través de un método GET. Y ejecutamos el test.

MatcherAssert.assertThat(request.method, CoreMatchers.`is`("GET"))

Al ejecutar este test, veremos que falla, pero no lo hace por el test, si no por que no se está ejecutando en el hilo correcto. Esto va a ser una constante cuando ejecutemos test con coroutines. Para corregir esto necesitamos crear un hilo que se ejecutará en el hilo principal y asignarlo al test.

El hilo lo añadimos como propiedad de la clase.

private val mainThreadSurrogate = newSingleThreadContext("UI thread")

En el método createService, al principio, le decimos que el Main de Dispatchers es nuestro hilo.

    @Before
    fun createService() {
        Dispatchers.setMain(mainThreadSurrogate)

Y en el stopService lo reseteamos.

    @After
    fun stopService() {
        mockWebServer.shutdown()

        Dispatchers.resetMain()
        mainThreadSurrogate.close()
    }

Ahora volvemos a ejecutar el test, y debería pasar a verde. Seguimos añadiendo las comprobaciones que necesitemos al test. Estas son la que he añadido yo.

        MatcherAssert.assertThat(request.path, CoreMatchers.`is`("/3/movie/popular?page=1"))
        MatcherAssert.assertThat(request.method, CoreMatchers.`is`("GET"))

        MatcherAssert.assertThat(result.results!!.size, CoreMatchers.`is`(20))

        val firstMovie: ApiObjectMovie = result.results!![0]
        MatcherAssert.assertThat(firstMovie.id, CoreMatchers.`is`("616037"))
        MatcherAssert.assertThat(firstMovie.imdbId, CoreMatchers.`is`("imdb_test"))
        MatcherAssert.assertThat(firstMovie.originalTitle, CoreMatchers.`is`("Thor: Love and Thunder"))

En la primera parte, verifico que la petición se hizo con método GET y el path de la petición es el correcto. Se podrían verificar más cosas, por ejemplo, que la petición tiene las cabeceras que correspondan.

En la segunda parte de verificaciones, he testeado la respuesta, en concreto que se han serializado correctamente los datos. En especial me interesan datos como imdbId cuyo nombre en el json es imdb_id y en la clase ApiObjectMovie se serializa a imdbId, así:

@SerializedName("imdb_id")
var imdbId: String?

Validando que los datos se serializan correctamente, sobre todo en estos casos, nos evitará sustos en el futuro.

Por otro lado, para obtener los valores en si a validar, debemos revisar, en este caso concreto, el archivo «popular_movies.json». Como siempre, este archivo y los demás, los podréis encontrar en el repositorio.

Nos quedaría testear el método movie de MovieService, pero una vez hemos hecho uno, el resto es seguir el mismo guión.

Aún nos quedan cosas por testear relacionadas con el API, pero por hoy lo dejamos aquí.

Como implementar Inyección de Dependencias en Swift

Hasta ahora nos estábamos preocupando más bien poco sobre un tema que si se hace bien nos puede traer grandes beneficios. Este no es otro que aplicar el principio de Inversión de Dependencias.

Si nos vamos a la Wikipedia, en este artículo se explica en detalle y nos dice esto en concreto:

  1. Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones (p.ej., interfaces).
  2. Las abstracciones no deberían depender de los detalles. Los detalles (implementaciones concretas) deben depender de abstracciones.

Así explicado la mayoría nos quedamos con cara de no entender nada. Pero si lo vemos con un ejemplo se entiende mejor.

En nuestra aplicación de ejemplo, en concreto en nuestro HomeViewModel, instanciamos un clase Configuration y otra ApiRestClient. Cuando empezamos a programar, esto suele ser lo más normal, necesitamos una clase que nos ayuda con un determinado tema, creamos una nueva instancia dentro de la clase que necesitamos y seguimos desarrollando.

Esto nos va a traer algunos problemas que a la larga nos pesarán bastante si nuestro código crece y crece (que lo hará).

  1. Imaginaros que tenemos una clase que almacena un dato concreto. Al principio, para no complicar la app, lo que hacemos es almacenar en UserDefaults, en nuestra clase instanciamos UserDefaults directamente y almacenamos. Además en otras clases que necesitamos leer este dato, vamos instanciando y leyendo el dato. Pasado un tiempo, se decide almacenar en base de datos, porque ahora se escriben más datos y en UserDefaults tantos datos son difíciles de manejar. Ahora, todas esas clases donde se estaba leyendo directamente a UserDefaults están fuertemente acopladas a este Framework.
  2. Por otro lado, si intentáis testear una de estas clases, os daréis cuenta de que es difícil hacerlo. No podremos testear por separado la funcionalidad en si de cada clase, vamos a tener siempre a UserDefaults interfiriendo sobre unos tests que se supone, deberían ser unitarios.

Bien, para solucionar todo este embrollo, llega la Inyección de Dependencias que sería la forma de aplicar el principio de Inversión de Dependencias. Siguiendo con el ejemplo anterior, una forma de solucionarlo sería pasando por constructor a todas las clases donde se lee o escribe una actracción.

Podemos tener una interface o protocol que nos diga que tenemos que implementar un método para leer y otro para escribir, pero esto no nos marca o exige como debemos hacerlo. Por otro lado, nos creamos una clase que implementa esta interface y que lee/escribe de UserDefaults, y se la pasamos por constructor a las clases que necesitamos. Cada una de estas clases ahora ya no tiene, ni que instanciar a UserDefaults, ni saber como se lee de este, y cambiar a otro sistema de almacenamiento sería mucho más sencillo, ya que simplemente se puede cambiar en la clase que maneja ahora la lectura/escritura de UserDefaults.

Bueno, dejando de lado la teoría y volviendo a nuestro proyecto. Estoy viendo que a nuestro proyecto le está pasando esto mismo, estamos instanciando dentro de clases otras, y esto va a suponer un problema a futuro. Para resolver en iOS estoy utilizando Resolver, que es una librería que nos ayudará con esto, pero revisando la documentación, me he dado cuenta que el creador va a deprecar la librería, pero tiene una nueva versión Factory, que se basa en la anterior, y básicamente nos permitirá hacer lo mismo.

Vamos con esta última entonces. Lo primero que tendremos que hacer es añadir la librería. Para ello, en File -> Add Packages y en la ventana que aparece, copiamos la url del repositorio https://github.com/hmlongco/Factory

En mi caso, he tenido problemas al añadir la librería, he tenido que añadir y eliminar 2 o 3 veces hasta que XCode la añadió correctamente y reconoció. Si usáis CocoaPods en vuestro proyecto, las instrucciones para instalar las podéis encontrar en el repositorio del autor de la librería.

Una vez añadida la librería, vamos a identificar aquellas clases que se están llamando dentro de otras.

El primer caso es el que comentamos antes, la clase HomeViewModel. Dentro de esta se está instanciando a la clase Configuration y a ApiRestClient.

Crearemos ahora un archivo nuevo que llamaremos AppInjection, en donde definiremos como instanciar estas clases. En este archivo importamos Factory y creamos una extension de Container (es una clase de nuestra librería).

Empezamos definiendo como instanciar Configuration. Creamos una propiedad configurationService y con la ayuda de Factory le decimos como debe instanciar Configuration. En este caso no necesita nada en el constructor.

Llegamos al caso de ApiRestClient. En este caso, necesitamos pasar en el constructor una instancia de Configuration. En este caso llamamos a nuestra propiedad configurationService.

import Factory


extension Container {
    static let configurationService = Factory(scope: .singleton) {
        Configuration()
    }
    
    static let apiRestClientService = Factory(scope: .singleton) {
        ApiRestClient(configuration: configurationService())
    }
}

Fijaros además que le estamos indicando a Factory en el parámetro scope el valor singleton. Con esto lo que conseguiremos es usar siempre la misma instancia de Configuration o ApiRestClient. El comportamiento por defecto es crear siempre una nueva instancia. Si deseamos otro comportamiento diferente se podría, os recomiendo leer la documentación de la librería.

Una vez tenemos esto listo vamos a ir un paso más allá, y añadiremos a Container también los ViewModels. Dentro de la extension Container añadimos:

static let homeViewModel = Factory() {
        HomeViewModel()
    }
    
    static let movieViewModel = Factory() {
        MovieViewModel()
    }

En este caso, no indicamos el scope, ya que queremos una nueva instancia de nuestros viewModel.

Una vez definido como se instancian nuestras clases, vamos a ver como utilizarlo.

Vamos a ViewModel, y vemos que tenemos algo así:

class HomeViewModel: ObservableObject {
    
    private let apiRestClient: ApiRestClient
    private let configuration: Configuration
    
    init() {
        self.configuration = Configuration()
        self.apiRestClient = ApiRestClient(configuration: configuration)
    }

Como veis, estamos instanciando dentro de nuestra clase Configuration y ApiRestClient. Veamos como librarnos de esto.

@Injected(Container.apiRestClientService) private var apiRestClient: ApiRestClient
    
init() {
        
}

Factory nos proporciona un wrapper @Injected, que nos permitirá obtener una instancia de la clase que necesitamos, y de este modo podremos limpiar el constructor.

En el caso de la vista, en lugar de utilizar @Injected, lo haré de la siguiente forma, ya que he detectado que junto a @ObservedObject la librería no funciona bien.

@ObservedObject var viewModel: HomeViewModel = Container.homeViewModel()

Y de este modo Factory nos dará una instancia del ViewModel que necesitamos. Se podría instanciar directamente el ViewModel en este punto, pero bajemos un momento hasta la preview. Y revisemos como cambia.

#if DEBUG
struct HomeView_Previews: PreviewProvider {
    static var previews: some View {
        let _ = Container.homeViewModel.register { MockHomeViewModel() }
        HomeView()
    }
}
#endif

Antes de esto, estábamos instanciando la vista y el viewModel, y asignando el ViewModel a la vista. Ahora lo que se hace es decirle a nuestro gestor de inyección de dependencias que vamos a cambiar nuestro HomeViewModel por MockHomeViewModel cuando mostremos la preview.

Esta misma técnica la podremos aplicar a la hora de hacer tests (que aún no llegamos, pero lo haremos).

Como conclusión, hemos modificado la forma en la que se asignan Configuration, ApiRestClient o los ViewModel, pero no la funcionalidad, aún así, la potencia que nos dará esto a medida que crezca el código será brutal, además de facilitarnos cambiar en nuestro código una pieza por otra con mucha facilidad. Por último, controlar como se instancia un objeto, a partir de ahora, se hará en un único sitio.

Como guardar configuraciones con Swift y iOS

La siguiente parte que quería abordar era como hacer peticiones a una API con Alamofire, pero cuando empecé me di cuenta que no quería exponer mi Api Key en el repositorio donde estoy subiendo el código de la aplicación.

Así que lo que vamos a hacer antes de llamar a nuestra API, será ver como almacenar correctamente nuestra Api Key de forma segura.

Lo primero que haremos será crear un nuevo archivo de tipo «Configuration Settings File» donde podremos incluir todos los valores sensibles.

Creo una entrada para mi api key, así:

Lo siguiente que haremos será ir a nuestro archivo Info.plist, que para los proyectos nuevos hechos con SwiftUI no existirá. En este caso, tenemos que ir en nuestro proyecto a la pestaña Info, y dentro de «Custom iOS Target Properties» añadir una clave nueva (pulsamos sobre la última y después Enter). Notaremos que después de hacer esto tenemos un nuevo archivo Info.plist.

Tenemos que añadir un nuevo par clave-valor. La key será «API_KEY» y el valor «$(API_KEY). Esta última es la que hace referencia a nuestro archivo de configuración del paso anterior.

Ahora, en nuestro proyecto, le decimos que archivo de configuración debe tomar. Podemos tener uno diferente para cada tipo de compilación si lo queremos. En este caso usaremos el mismo.

¿Cuándo podemos tener varios? Imaginaros que una de las claves fuese una url a un servidor. Para debug podría apuntar a un servidor de desarrollo y para release al de producción.

En nuestro archivo .gitignore debemos añadir una entrada para que no añada los cambios de nuestro archivo de configuración. Este archivo lo abro desde terminal con vim, pero aquí el editor es lo de menos.

Una vez ya tenemos todo configurado, vamos a utilizarlo en nuestra app.

Primero de todo creamos un archivo Configuration.swift. Aquí expondremos una propiedad con el valor de nuestra api key. Esto lo estaremos leyendo de nuestro archivo Info.plist.

class Configuration {
    
    let apiKey: String? = Bundle.main.infoDictionary?["API_KEY"] as? String
    
}

Ahora solo quedará instanciar nuestra clase Configuration donde se necesite este api key.

let configuration = Configuration()
configuration.apiKey

Como veis, es muy sencillo manejar nuestras api keys o cualquier otro parámetro de configuración.

Por supuesto, y por seguridad, no incluyáis claves en vuestra aplicación, en todo caso, si las necesitáis, tenedlas a buen recaudo en un servidor seguro, y solo obtenedlas bajo una conexión segura.

Podéis ver el código completo en el repositorio donde estamos haciendo nuestra aplicación para leer películas https://github.com/3pies/moviesios o podéis ver el proceso completo en mi canal de Youtube.

Como crear nuestro primer MVVM en iOS

Empezar a crear una aplicación desde cero siempre es excitante y a la vez abrumador. Demasiadas cosas que hacer en muy poco tiempo. Así que es importante pararse un momento y reflexionar como queremos hacerlo.

Un buen punto de inicio es pensar en una funcionalidad que nos permita definir a pequeña escala como queremos que sea la arquitectura de nuestra app, y a partir de ahí empezar a contruir.

En nuestro caso, una app que lea un listado y después vea un detalle nos ayudará a comprender y modelar nuestra app a pequeña escala.

Voy a utilizar MVVM como arquitectura, ya que nos ayudará a separar la parte vista del resto de la app. En esta arquitectura tenemos 3 partes, la parte View que es la que muestra la interface de usuario, la parte Model que es la que maneja los datos, y por último, la parte ViewModel, que por un lado se encarga de tratar los datos y por otro lado, pasa estos datos a la vista a través de databinding.

Vamos a empezar, voy a crear una vista muy sencilla, con su viewmodel y datos mock que nos permitirá tener un primer punto de arranque con estas 3 capas. Empecemos!!!

Model

Empezaré creando el modelo de datos, en este caso al tratarse de un listado de películas, haré un entidad llamada Movie, la cual será un struct plano y cuyo único cometido será almacenar los datos a mostrar.

Además, debe implementar el protocolo Identifiable, el cual nos ayudará después a la hora de iterar sobre un listado de Movie.

struct Movie: Identifiable {
    var id: String
    var imdbId: String?
    var title: String
    var overView: String
    var posterPath: String?  
}

Además, dado que no vamos a conectarnos ni con un API ni con base de datos local de momento, crearemos un array de tipo Movie con datos mock. Este nos quedará después para ayudarnos a crear las previews de nuestras vistas.

let moviesTest: [Movie] = [
    Movie(id: "1", imdbId: "imdb01", title: "Regreso al Futuro", overView: "Lorem ipsum", posterPath: nil),
    Movie(id: "2", imdbId: "imdb02", title: "Regreso al Futuro II", overView: "Lorem ipsum", posterPath: nil),
    Movie(id: "3", imdbId: "imdb03", title: "Regreso al Futuro III", overView: "Lorem ipsum", posterPath: nil),
    Movie(id: "4", imdbId: "imdb04", title: "Matrix", overView: "Lorem ipsum", posterPath: nil),
    Movie(id: "5", imdbId: "imdb05", title: "Canta", overView: "Lorem ipsum", posterPath: nil),
    Movie(id: "6", imdbId: "imdb06", title: "Scream", overView: "Lorem ipsum", posterPath: nil),
    Movie(id: "7", imdbId: "imdb07", title: "Spiderman No way home", overView: "Lorem ipsum", posterPath: nil),
]

ViewModel

El siguiente paso será crear nuestro ViewModel, es decir, la parte que se encargará de leer datos y enlazarlos a la vista.

Crearemos un archivo llamado HomeViewModel con lo siguiente:

import SwiftUI

class HomeViewModel: ObservableObject {
    
    @Published var movies: [Movie] = []
    
    func loadMovies() {
        self.movies = moviesTest
    }
    
}

Tenemos 3 puntos a destacar. Por un lado, nuestra clase ViewModel implementa ObservableObject, lo cual permitirá que se observe desde la vista.

Por otro lado, tenemos una propiedad marcada con @Published, el cual es un wrapper que nos permitirá enviar datos y que será observado desde la vista. La vista reaccionará a los cambios que se vayan produciendo desde aquí.

Por último, tenemos un método loadMovies que se encarga de lanzar la lectura de datos. En este caso concreto, simplemente estamos enlazando con nuestros datos mock, pero en futuras publicaciones se complicará esta parte, mientras que la vista permanecerá igual.

Ahora que tenemos 2 de 3 partes, vamos a por la última.

View

Esta es sin duda la más sencilla. De momento tendremos un listado que se nutrirá de los datos que vienen del viewModel.

struct HomeView: View {
    
    @ObservedObject var viewModel: HomeViewModel = HomeViewModel()
    
    var body: some View {
        VStack {
            ForEach(viewModel.movies) { movie in
                Text(movie.title)
            }
        }.onAppear {
            viewModel.loadMovies()
        }
    }
}

Para empezar definimos nuestro viewModel y lo marcamos con @ObservedObject, esto es un wrapper que le dirá a la vista que se va a observar este objeto.

Después, tenemos un VStack, en el cual añadimos un ForEach del viewModel.movies, junto con un Text, donde de momento solo mostraremos el título de nuestra película.

Hasta aquí, de por si, no pasará nada, pero gracias al modificador onAppear llamaremos al método que lee las películas en el momento en el que aparece la vista.

Y con esto ya hemos montado una arquitectura MVVM muy básica. Aunque muy básica ya hemos marcado los cimientos y separado los conceptos para construir nuestra aplicación.

Como siempre, os dejo enlace al repositorio de Github donde tengo el código completo. No olvidéis revisar el vídeo de Youtube asociado, suscribiros y dejar un gran like.

https://github.com/3pies/moviesios