2.1 Interfaz de línea de comandos

La interfaz de línea de comandos o interfaz de línea de órdenes (en inglés: command-line interface, CLI) es un tipo de interfaz de usuario de ordenador que permite a los usuarios dar instrucciones a algún programa informático o al sistema operativo por medio de una línea de texto simple.

Las CLI pueden emplearse interactivamente, escribiendo instrucciones en alguna especie de entrada de texto, o pueden utilizarse de una forma mucho más automatizada (archivo batch), leyendo órdenes desde un archivo de scripts.

Esta interfaz existe casi desde los comienzos de la computación, superada en antigüedad solo por las tarjetas perforadas y mecanismos similares. Los ordenadores tenían conectadas “terminales tontas” que permitían enviar comandos al ordenador.

Hoy en día la línea de comandos se utiliza a través de programas denominados “emulador de terminales” que ejecutan un intérprete de comandos (llamado “shell”). Estos intérpretes, dependiendo del sistema operativo se pueden elegir, por ejemplo:

• En Windows se puede hacer uso del antiguo cmd o el más nuevo y mejorado PowerShell. También se puede utilizar otros, pero no vienen de serie instalados (como bash)

• En sistemas GNU/Linux el intérprete más utilizado y que está instalado en la gran mayoría de distribuciones es bash. En los últimos años ha ganado mucho mercado zsh gracias al framework Oh-my-zsh.

• En sistemas MacOS el intérprete por defecto es zsh.

Los conceptos de CLI, shell y emulador de terminal no son lo mismo ya que CLI se refiere al paradigma, mientras que un shell o un emulador de terminal son programas informáticos específicos, que usualmente en conjunto implementan la CLI. Sin embargo, los tres suelen utilizarse como sinónimos.

2.2 Interfaz gráfica de usuario

La interfaz gráfica de usuario, conocida también como GUI (del inglés graphical user interface), es un programa informático que actúa de interfaz de usuario, en la que hoy en día utilizando un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz.

Su función principal es proporcionar un entorno visual sencillo para permitir la comunicación con el sistema operativo de un ordenador.

2.2.1 Interfaz en modo texto

Las interfaces gráficas no nacen con los escritorios, si no que ya en pasos anteriores existen librerías que simulan ventanas o entornos haciendo uso de caracteres de texto y colores.

Hay que tener en cuenta que estos interfaces se solían utilizar en máquinas con muy pocos recursos y con sistemas operativos en los que no existía un interfaz gráfica.

2.2.2 Primeras investigaciones y desarrollos

El proyecto de “Aumento del Intelecto Humano” de Doug Engelbart en el Stanford Research Institute (en Menlo Park, EE. UU.) en la década de los 60 desarrolló el oN-Line System, que incorporaba un cursor manejado con un ratón y múltiples ventanas usadas para trabajar con hipertexto.

Mucha de la investigación inicial estuvo basada en como los niños pequeños aprenden. Por lo que el diseño se basó en las primitivas infantiles de coordinación mano-ojo, en lugar de usar lenguajes de comandos.

El GUI fue inicialmente desarrollado en Xerox PARC (Palo Alto Research Center) por Alan Kay, Larry Tesler, Dan Ingalls y algunos investigadores más. Usaba ventanas, iconos y menús, incluyendo el primer menú desplegable fijo, para dar soporte a comandos como abrir ficheros, borrar y mover ficheros, etc.

En 1981 Xerox presentó un producto innovador, el Star, incorporando muchas de las innovaciones de PARC. Aunque no fue un éxito comercial, el Star influenció de manera importante los futuros desarrollos, por ejemplo en Apple, Microsoft y Sun Microsystems.

En 1979, el equipo encabezado por Steve Wozniak, Steve Jobs y Jef Raskin (junto con antiguos trabajadores de Xerox) continuaron con las ideas vistas en Xerox PARC para lanzar en 1983 el ordenador “Apple Lisa”, el primer ordenador con interfaz gráfico. No fue un éxito en ventas, pero inició la era de lo que se podrían denominar “los sistemas operativos con escritorio”.

En 1984 Apple lanzó el Macintosh, el cual presentó una evolución del sistema operativo de Lisa, llamado “System”, en el que se puede apreciar partes que apenas han cambiado desde entonces.

Al año siguiente Microsoft sacaría Windows 1.0, que era un GUI para su sistema operativo MS-DOS, pero no sería hasta la versión de Windows 3.0 de 1990 en la que su popularidad explotó.

2.3 Uso masivo del escritorio

Con la llegada de la década de 1990, en la que los ordenadores personales (PC, del inglés personal computer) se popularizan y empiezan a llegar a las casas y negocios, hizo que se creara un mercado de usuarios sin conocimientos avanzados que requerían de facilidades de uso.

El “boom” comenzó con el Windows 3.11, pero sobre todo con Windows 95, que consiguió ocultar el núcleo del sistema operativo subyacente (MS-DOS) para mostrar directamente el interfaz gráfico desde el inicio.

Apple compra a NeXT (empresa fundada por Steve Jobs) y utiliza su sistema operativo como los cimientos de Mac OS 8. Posteriormente cambiarían la arquitectura del sistema operativo para ser de estilo UNIX y así presentar Mac OS X en 2001.

Durante estos años y principios de los 2000, los interfaces de usuario van evolucionando a medida que evoluciona la potencia de los ordenadores, pero siguiendo la misma tónica de simular un escritorio real en el ordenador.

Se anuncian entornos de escritorio libres como Gnome y KDE, que evolucionan en paralelo dentro de mundo de GNU/Linux llegando a crearse casi una guerra entre ellos y entre los usuarios (Enlace 1, Enlace 2).

Cada sistema operativo y cada sistema de escritorio realizaba sus propias evoluciones que si tenían calado eran “copiadas” en los otros, generando también ciertas “modas” en colores, iconos o efectos de ventanas.

2.4 Interfaces web

Entre finales de los 90 y principios de los 2000, el auge de internet en todo el mundo hace que los portales web también sufran una gran evolución en sus interfaces.

También hay que tener en cuenta que las versiones HTML y CSS de la época no era tan avanzado como lo son hoy, y que las posibilidades de ejecución de javascript tampoco era tan potente como lo es hoy en día. Las interfaces pueden verse limitadas por la propia tecnología

Por otro lado, es habitual que la imagen de la compañía cambie, ya sea por cambios de logotipo, colores corporativos, moda en el tono de los colores... y todo eso también hace que los interfaces sufran modificaciones.

2.5 Interfaces móviles

En el caso de los teléfonos móviles, debido a que no existía un sistema estándar de visualización, cada fabricante iba creando su propio interfaz a medida que las pantallas iban creciendo en tamaño, resolución, colores...

Los primeros móviles carecían de pantalla, posteriormente comenzaron a tener pequeñas pantallas LCD monocromas, en algunos casos con una única línea de texto.

Posteriormente comenzaron a tener pantallas a color y cada compañía crea su propio sistema operativo. Existe un intento de crear un sistema operativo entre varias compañías llamado Symbian, pero al final es Nokia la desarrolladora y la que más uso le da.

Durante los primeros años de la década de los 2000 también se ponen de moda las PDA (personal digital assistant, asistente digital personal u ordenadores de bolsillo), que normalmente hacían uso de un lapiz para hacer funcionar la pantalla táctil (resistiva) que tenían.

Todo cambió con la llegada del iPhone en el 2007 y los primeros smartphones, donde las pantallas táctiles capacitativas (se manejan con el dedo) cobran protagonismo. Estas pantallas aparte de ser táctiles también permiten gestos con varios dedos, dando lugar a nuevos efectos de interactuar con el interfaz.

Apple se decanta por un único botón mientras que los sistemas operativos Android (como el HTC Desire del 2009) tienen al menos cuatro para manejar ciertas tareas del sistema y de la aplicación que se está usando en el momento.

Con estos cambios, los sistemas operativos y las interfaces sufren un cambio radical, donde buscan la facilidad del usuario y aparecen los “gestos” como nueva manera de interactuar con el interfaz:

• Tap: tocar la pantalla (similar al “click” con el ratón)

• Double tap: doble toque, que dependiendo de la aplicación puede hacer un zoom específico.

• Scroll: presionando con el dedo y subiendo para arriba o para abajo se hace scroll sobre el interfaz.

• Flick: si se hace un gesto rápido hacía arriba o hacia abajo se hace scroll, mientras que si es a izquierda o derecha el movimiento dependerá de si hay más pantalla.

• Pinch in: hacer zoom acercando lo que se quiere ver.

• Pinch out: hacer zoom alejando el objeto.

Con todo ello, surge un nuevo “problema” que hasta este momento no se había planteado en los interfaces, que es la rotación del dispositivo. Esta rotación debe hacer que la aplicación que se está ejecutando se adapte a la nueva posición del terminal, pasando de vertical a horizontal o viceversa.

Como evolución de estos dispositivos surgen las tablets en donde se sigue la misma filosofía de gestos, pero las pantallas táctiles de mayor tamaño permiten tener más espacio para información. En lugar de usar los interfaces de escritorio, evolucionan los interfaces de los móviles.

Al tener más espacio, no se utilizan las aplicaciones de móviles y se “escalan”, si no que surgen nuevas posibilidades para que los interfaces dispongan de nuevos menús o lugares donde añadir más información.

2.6 Realidad virtual y realidad aumentada

El siguiente paso en el desarrollo de interfaces se encuentra en la conocida como realidad aumentada y en la realidad virtual. Aunque puedan parecer términos que están ahora de moda, su estudio y evolución lleva décadas fraguándose.

Los primeros pasos que se dieron en este sentido son los denominados “head-up display”, que son pantallas transparentes que presentan información al usuario dejando ver lo que está en la parte trasera de la pantalla. De esta manera, el usuario no tiene que girar la cabeza para obtener la información.

En algunos casos esta pantalla puede estar entre el usuario y el salpicadero, integrada en el salpicadero o también como una pantalla puesta en el casco del piloto y cerca del ojo.

Por otro lado, tenemos la realidad virtual, que es un entorno simulado que da una sensación de inmersión al usuario ofreciéndole la posibilidad de moverse en él, y en algunos casos interactuar con elementos del entorno.

Para ello, suele ser habitual contar con unas gafas que nos mostrarán el entorno virtual, y también dispondremos de unos mandos para poder interactuar con el entorno.

Para poder movernos por el entorno, algunos de estos sistemas hacen uso de trackers, de esta manera nos podremos desplazar por el entorno virtual sin tener que usar los mandos.

El siguiente paso es la conocida como realidad aumentada, en el que se trata de integrar elementos virtuales en la vida real. No es algo nuevo, ya que lleva años existiendo en juegos y aplicaciones.

Cn la idea de que la realidad aumentada sea de uso cotidiano han empezado a evolucionar los sistemas para que poco a poco esto vaya fraguando, aunque el coste todavía sigue siendo elevado. A día de hoy, tampoco está claro cuál será el beneficio y el rendimiento que tendrá.

En el caso de las Apple Vision Pro prometen una experiencia de realidad aumentada utilizando únicamente gestos de las manos para moverse a través de su interfaz.

4.1 Diferencias entre ambos modelos

A la hora de elegir qué sistema elegir, dependerá de los conocimientos que tengamos en ambos, pero a continuación se muestra una pequeña tabla comparativa:

• XML:
  • Ventajas:
    • Separación de conceptos: La vista se diferencia cláramente de la lógica
    • Editor WYSIWYG: Android Studio incorpora un editor visual que nos permite colocar los componentes de la vista. Puede ser más intuitivo para algunos desarrolladores
    • Reciclaje: Se pueden generar plantillas/layouts XML que pueden ser utilizados en distintos activities.
  • Desventajas:
    • Limitado: A la hora de generar interfaces complejos, el formato XML tiene limitaciones que tienen que ser subsanado con código Java/Kotlin.
    • Verbosity: Los ficheros XML pueden ser complejos y tener redundancias. Esto puede hacer que se complique a la hora de mantener vistas complejas.
• Jetpack Compose
  • Ventajas:
    • Sintaxis declarativa que facilita la creación de UI complejas
    • Tipado seguro: Como es código Kotlin, se reduce la posibilidad de cometer errores de tipado y que haya errores durante la ejecución.
    • Modularidad: Jetpack Compose promueve la creación de componentes de interfaz que se puedan reutilizar. Esto facilita el mantenimiento de la aplicación y la escalabilidad.
    • Vista previa “en vivo”: Se puede ver una vista previa a medida que se va generando la vista en código.
  • Desventajas:
    • La curva de aprendizaje puede ser pronunciada al inicio.
    • Compatibilidad: A día de hoy no debería ser un problema, pero sólo se puede usar con Android 5.0 (API level 21) o superior.
    • Sólo se puede usar con Kotlin.

5.1 Creando nuestro primer proyecto

Una vez abierto Android Studio vamos a crear un nuevo proyecto y vamos a elegir “Empty Views Activity”, de esta manera el proyecto que nos va a generar va a tener una primera vista con un texto centrado

En el siguiente paso elegimos el nombre del proyecto, la ruta, el lenguaje de programación y el SDK que vamos a utilizar. Con las opciones elegidas, se empezará a generar el proyecto y los ficheros necesarios para poder hacer funcionar la aplicación.

Si desplegamos en el menú de la izquierda (con la opción “Android” seleccionada) hasta llegar a la ruta app/res/layout, veremos que tenemos un fichero que se llama activity_main.xml, que al hacer click obtendremos una vista similar a esta:

5.2 Vista “diseño”, “blueprint” y código

A la hora de interactuar con las vistas tendremos tres opciones:

• Vista diseño: Es lo más cercano a lo que el usuario final va a ver. De esta manera podremos ver los distintos elementos que tiene la interfaz y con el contenido que se le haya dado.

• Vista blueprint: También conocida como “cianotipo” o vista de plano. Simula los planos de ingeniería y en esta vista sólo veremos de qué tipo es cada elemento. Esta vista es adecuada para abstraernos del contenido y centrarnos en el diseño.

• Código XML: Es el contenido del fichero XML de la propia vista. Podremos realizar modificaciones cambiando el texto. Esta vista es la idónea si queremos cambiar algún parámetro concreto que ya está prefijado y queremos ir a tiro hecho.

5.3 Componentes en el interfaz

5.4 Layouts y constraints

Con la vista inicial, si seleccionamos el texto “Hello World!” veremos que tiene una configuración en el apartado Layout como el siguiente:

De esta manera, cada parte del componente tendrá un constraint que estará asociado, en este caso, a una parte del layout padre que lo contiene. Si miramos el código fuente del fichero XML, se puede apreciar cómo cada uno de estos aparece escrito:

<TextView
    android:id="@+id/textView"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Hello World!"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toTopOf="parent" />

Si añadimos al interfaz un botón, en la parte baja de la pantalla, centrado y en la posición que nos interese en la vista vertical, veremos que a la hora de ejecutar la vista en el simulador deja de aparecer en la posición que lo hemos indicado.

Es por eso, que para cada componente que queramos añadir a la vista deberá tener sus constraints haciendo referencia a otros componentes o al layout que lo contiene. En caso de que no hayamos añadido uno, o algo en la vista no sea correcto, nos aparecerá en el interfaz:

Los componentes pueden estar asociados a otros componentes, pero no tienen por qué estar asociados entre ellos. Por ejemplo, la siguiente vista tiene a nivel horizontal podemos apreciar lo siguiente:

5.5 Vista vertical y horizontal

Nuestros dispositivos pueden rotar de posición, y por tanto los componentes que aparecen en pantalla deberían poder ajustarse a la nueva posición de la misma.

Por eso, a la hora de diseñar el interfaz, deberemos pensar qué hacer con la posición de los componentes: si se desplazan de posición, si se ocultan de alguna manera, si se convierten en un menú desplegable...

Por defecto, al rotar el dispositivo, los componentes se moverán teniendo en cuenta el layout y los constraints que tienen configurados. En la vista creada al crear el proyecto, al rotar el dispositivo sucederá lo siguiente:

Tal como se puede ver, el texto “Hello World!” permanece centrado respecto a la vista debido a que el texto tiene asociados unos constraints contra el resto del interfaz, haciendo que siempre esté centrado.

5.6 Dando funcionalidad al interfaz

Aunque no se va a ahondar en cómo programar para Android, se va a añadir un pequeño ejemplo para entender cómo funciona un botón y un texto y cómo interactuar entre sí.

La idea es:

• Crear un interfaz con un botón y un TextView.

• Al pulsar el botón, el texto original del TextView desaparece y se incrementa en 1 para saber el número de pulsaciones que se han realizado.

Teniendo esto en cuenta, el código del fichero MainActivity.kt debería quedar de la siguiente manera:

//... imports previos
import android.widget.Button
import android.widget.TextView

class MainActivity : AppCompatActivity() {

    var contador:Int = 0

    override fun onCreate(savedInstanceState: Bundle?) {
        //... código ya existente

        val button:Button = findViewById(R.id.button)
        val text:TextView = findViewById(R.id.textView)

        button.setOnClickListener {
            contador = contador+1
            text.text= (contador).toString()
        }
    }
}

6.1 Entendiendo la vista por defecto

La vista que nos ha generado el proyecto cuenta con una serie de apartados que hay que entender para poder realizar modificaciones y también saber qué está sucediendo en la vista previa.

@Composable
fun Greeting(name: String, modifier: Modifier = Modifier) {
    Text(
        text = "Hello $name!",
        modifier = modifier
    )
}

@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
    JetpackTheme {
        Greeting("Android")
    }
}

@Preview(showBackground = true, showSystemUi = true, 
    uiMode = Configuration.UI_MODE_NIGHT_YES)
@Preview(showBackground = true, showSystemUi = true,
    device = "id:pixel_fold")
@Preview(showBackground = true, showSystemUi = true,
    device = "spec:width=411dp,height=891dp,orientation=landscape")

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent {
            JetpackTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
                    Greeting(
                        name = "Android",
                        modifier = Modifier.padding(innerPadding)
                    )
                }
            }
        }
    }
}

6.2 Disposición de elementos

A la hora de crear nuestro interfaz debemos pensar en la composición/disposición (layout en inglés) de los distintos elementos. En la documentación oficial hay un ejemplo similar al que se va a explicar aquí, por lo que es recomendable echar un vistazo.

Vamos a suponer el siguiente interfaz básico, donde a la izquierda aparece cómo quedaría el interfaz final, mientras que la disposición de los distintos elementos aparecen resaltados en la imagen de la derecha.

Mirando la disposición diseñada, a la hora de convertirlo a programación declarativa debemos entender los distintos apartados que hemos creado y cómo se van a colocar los distintos componentes.

Una primera iteración en programación con Composer quedaría de la siguiente manera, donde se han colocado los componentes con contenido hardcodeado, por lo que la función creada siempre mostrará el mismo contenido:

@Composable
fun Post() {
    Column {
        Column {
            Text("title")
            Text("subtitle")
        }
        Image(
            painter = painterResource(R.drawable.dragon),
            contentDescription = null
        )
        Text("Lorem ipsum dolor sit amet, conse...")
        Row {
            Column {
                Image(
                    painter = painterResource(R.drawable.goku),
                    contentDescription = null
                )
            }
            Column {
                Text("Author")
                Text("2024-09-01")
            }
        }
    }
}

Tal como se puede ver en el código, se han utilizado las siguientes funciones para colocar los elementos:

• Column: pone todos los componentes hijos en una secuencia vertical.
• Row: para colocar los componentes hijos en una secuencia horizontal.

6.3 Modificadores de los elementos

La función creada previamente coloca los distintos elementos haciendo uso de las funciones de Composer, pero para tener una interfaz amigable y con el resultado final, debemos hacer uso de los modificadores para cada elemento. Este será el punto en el que decidiremos “cómo poner bonito” el interfaz.

Los modificadores se pueden añadir a nivel de bloque o a nivel de elemento, por lo que habrá que tener cuidado con el tipo de sentencias que utilizamos, ya que algunas prevalecen sobre otras por tener mayor prioridad.

Añadiendo distintos modificadores, el código quedaría:

@Composable
fun Post() {
    Column (
        modifier = Modifier // FALTA CÓDIGO
    ) {
        Column (
            horizontalAlignment = Alignment.CenterHorizontally,
            modifier = Modifier
                .padding(10.dp)
                .fillMaxWidth()
                // FALTA CÓDIGO
        ) {
            Text(
                text = "title",
                modifier = Modifier.padding(bottom = 15.dp)
            )
            Text("subtitle")
        }
        Image(
            painter = painterResource(R.drawable.dragon),
            contentDescription = null
        )
        Text(
            text = "Lorem ipsum dolor sit amet, conse...",
            modifier = Modifier // FALTA CÓDIGO
        )
        Row (
            verticalAlignment = Alignment.CenterVertically,
            modifier = Modifier // FALTA CÓDIGO
        ){
            Column {
                Image(
                    painter = painterResource(R.drawable.goku),
                    contentDescription = null,
                    modifier = Modifier
                        .clip(CircleShape)
                        .background(color = Color.LightGray)
                        .size(100.dp)
                        .padding(5.dp)
                )
            }
            Column (
                Modifier.padding(start = 10.dp)
            ) {
                Text("Author")
                Text("2024-09-01")
            }
        }
    }
}

Se han añadido distintos modificadores tanto a nivel de columna/fila como a nivel de componente final. Tal como se puede ver, el código es bastante auto-explicativo. El código de ejemplo no está completo, se han añadido comentarios donde falta código para dibujar los bordes en algunos modificadores. Los bordes facilitan ver la disposición de cada conjunto de elementos

6.4 Vista vertical y horizontal

Si giramos el dispositivo con el ejemplo que hemos creado hasta ahora, veremos que la disposición de los elementos se mantiene de manera correcta, salvo por el hecho de que no tenemos scroll. El componente Column no tiene scroll por defecto, por lo que deberemos añadirlo al modificador principal:

@Composable
fun Post() {
    Column (
        modifier = Modifier // FALTA CÓDIGO
            .verticalScroll(rememberScrollState())
    ) {
        //...
    }
}

De esta manera, en la vista horizontal nuestra aplicación tendrá scroll al haberle dado esa característica a la columna principal.

Por otro lado, si queremos diferenciar cómo generar la composición de la vista dependiendo de si el dispositivo está en vertical u horizontal, podemos hacer lo siguiente:

// Cogemos la configuración actual
val configuration = LocalConfiguration.current

// Hacemos una composición diferente según estado
when (configuration.orientation) {
    Configuration.ORIENTATION_LANDSCAPE -> {
        LandscapeScreenComposition()
    }
    else -> {
        VerticalScreenComposition()
    }
}

6.5 Crear temas personalizados

A la hora de crear nuestra aplicación puede ser interesante tener un “tema” (en inglés theme) personalizado. Estos “temas” suelen hacer referencia a los colores de la aplicación, la tipografía, … Y este tema será diferente dependiendo de si tenemos el dispositivo en modo “claro” u “oscuro”.

Al crear nuestro proyecto veremos que existe un directorio llamado ui/theme dentro de la misma ruta donde se encuentra el fichero MainActivity.kt. En ese directorio nos encontraremos con tres ficheros, que es recomendable abrir para ver su contenido:

• Color.kt: Contiene unas variables con los colores que van a ser utilizados en la aplicación. Los colores se pueden definir de distintas maneras y pueden tener un rango “Alpha” que es la opacidad. Podemos generar nuestro propio sistema de colores y existen distintos roles que podemos utilizar en nuestra aplicación.

• Type.kt: En este fichero se hace referencia a las tipografías, la fuente de letra a utilizar, tipo, tamaño, … Por defecto existen tres escalas (“Large”, “Medium” y “Small”) para los siguientes roles:
  • Display: El texto más grande de la pantalla, reservado para textos cortos o numéricos. Funcionan mejor en pantallas grandes. Se suelen usar fuentes “expresivas”, de tipo manuscritas.
  • Headline: Adecuados para textos breves en pantallas más pequeñas. Útiles para marcar pasajes de un texto o partes importantes de un contenido.
  • Title: Se deben usar para textos de énfasis medio que sean relativamente cortos.
  • Body: Se usa para textos largos. Hay que tratar de evitar fuentes muy expresivas o decorativas, porque pueden ser más difíciles de leer.
  • Label: Se utiliza para el texto dentro de componentes. Por ejemplo, los botones usan el estilo LabelLarge.
  Se puede ver la explicación de cada tipo de fuente en la explicación de los estilos y un ejemplo de distintas tipografías en el siguiente enlace a un proyecto de ejemplo en Github.
• Theme.kt: Es el fichero principal del tema, y en el que se conjuga y utiliza lo especificado en los ficheros nombrados anteriormente. Si miramos el fichero de un proyecto recién creado, contiene lo siguiente:

package com.example.jetpack.ui.theme    
//... 
private val DarkColorScheme = darkColorScheme(
    primary = Purple80,
    secondary = PurpleGrey80,
    tertiary = Pink80
)

private val LightColorScheme = lightColorScheme(
    primary = Purple40,
    secondary = PurpleGrey40,
    tertiary = Pink40
)

@Composable
fun JetpackTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    // Dynamic color is available on Android 12+
    dynamicColor: Boolean = true,
    content: @Composable () -> Unit
) {
    val colorScheme = when {
        dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
            val context = LocalContext.current
            if (darkTheme) 
                dynamicDarkColorScheme(context) 
            else
                dynamicLightColorScheme(context)
        }
        darkTheme -> DarkColorScheme
        else -> LightColorScheme
    }

    MaterialTheme(
        colorScheme = colorScheme,
        typography = Typography,
        content = content
    )
}

• Shapes.kt: En un proyecto recién creado no se crea este fichero, pero en este ejemplo se puede ver su contenido. En este fichero se pueden modificar las formas que podemos utilizar en nuestra aplicación.

6.6 Eventos en Compose

Tal como dice la documentación oficial, Compose es declarativo y, por lo tanto, la única manera de actualizarlo es llamar al mismo elemento que admite composición con argumentos nuevos. Estos argumentos son representaciones del estado de la IU. Cada vez que se actualiza un estado, se produce una recomposición.

• Composición: Es una descripción de la IU que compila Jetpack Compose cuando ejecuta elementos de componibilidad.

• Composición inicial: Es la creación de una composición con la primera ejecución de elementos componibles.

• Recomposición: Es la nueva ejecución de los elementos de componibilidad a los fines de actualizar la composición cuando los datos cambian.

Compose necesita saber de qué estado se debe hacer un seguimiento a fin de que, cuando reciba una actualización, pueda programar la recomposición. Compose solo realizará la recomponsición de las funciones que deben cambiar. Para ello usaremos los tipos State y MutableState de Compose para que Compose pueda observar el estado. La función Mutablestate puede actualizar su value para actualizar el estado.

Vamos a realizar el ejemplo del contador, cuya función sería la siguiente:

@Composable
fun Contador(modifier: Modifier = Modifier) {
    var contador: MutableState<Int> = remember { mutableStateOf(0) }

    Surface(modifier = Modifier.fillMaxSize()) {
        Column(
            horizontalAlignment = Alignment.CenterHorizontally
        ) {
            Text("${contador.value}")
            Button(
                onClick = {
                    contador.value++
                }
            ) {
                Text("Suma!")
            }
        }
    }
}

La variable “contador” es de tipo “MutableState”, que se actualiza al pulsar el botón, y Compose al detectar que se ha actualizado su “value”, recompone esa parte de la vista, mostrando el nuevo valor.

7.1 Mantener los estados con XML

Una vez sabemos cómo actúa las distintas transiciones de estados de las vistas, es momento de poder guardar el estado para poder recuperar la información al crear el Activity de nuevo. Para ello se van a usar dos funciones:

• onSaveInstanceState : Se llamará cuando vaya a destruirse el Activity.

• onRestoreInstanceState: Se llamará justo después de llamar al método onCreate.

Siguiendo con el ejemplo previo, donde queremos guardar el número de veces que se ha pulsado el botón, deberíamos añadir algo como lo siguiente:

override fun onResume(){
    super.onResume()
    Log.d("Debug","onResume")
    val text:TextView = findViewById(R.id.textView)
    text.text = contador.toString()
}

override fun onSaveInstanceState(outState: Bundle) {
    // Save the user's current game state.
    outState?.run {
        putInt("contador", contador)
    }
    // Always call the superclass so it can save the view hierarchy.
    super.onSaveInstanceState(outState)
}

override fun onRestoreInstanceState(savedInstanceState: Bundle) {
    // Always call the superclass so it can restore the view hierarchy.
    super.onRestoreInstanceState(savedInstanceState)
    // Restore state members from saved instance.
    savedInstanceState?.run {
        contador = savedInstanceState.getInt("contador")
    }
}

7.2 Mantener los estados con Compose

El ciclo de vida de los elementos componibles es diferente en Jetpack Compose, ya que la recomposición se realiza a nivel de componente en lugar de a vista completa.

Para guardar el estado de la variable entre recomposiciones, haremos uso del tipo “rememberSaveable”. Esto nos permitirá rotar el dispositivo y mantener el valor de la variable:

@Composable
fun Contador(modifier: Modifier = Modifier) {
    var contador: MutableState<Int> = rememberSaveable { mutableStateOf(0) }
    // ...
}

Al hacer uso de “rememberSaveable” nos permite guardar el estado durante la recomposición, pero dado que el ciclo de vida de la actividad puede contener otros estados, no siempre será funcional.

Para hacer uso más complejo de los estados, en cómo guardar estados de la IU y en estado y Jetpack Compose hay más documentación sobre ello.

Desarrollo de aplicaciones

9.1 Diseño de interacción

Tal como nos dice la wikipedia, el diseño de interacción (abreviado como IxD), está definido como “la práctica de diseñar productos digitales interactivos, entornos, sistemas, y servicios”. Esta definición no sólo afecta a entornos digitales, ya que también es aplicable al mundo real.

Podríamos resumirlo como:

• Cuáles son las acciones que el usuario tiene que realizar para llevar a cabo su objetivo al utilizar la aplicación.
• Cómo debe realizar dichas acciones.

Es importante diseñar sistemas que sean efectivos, eficientes y sencillos a la hora de utilizarlos, ya que por el contrario, por muy buena que sea nuestra aplicación, los usuarios pueden decidir no utilizarla.

El objetivo debe ser minimizar los errores que los usuarios pueden realizar, incrementar la satisfacción del usuario, disminuir la frustración y, en definitiva, hacer más productivas las tareas que rodean a las personas y la aplicación.

9.2 Usabilidad

Usabilidad es un neologismo (del inglés usability, facilidad de uso) que se refiere a la facilidad con que las personas pueden utilizar una herramienta u objeto. En el mundo de la informática es aplicable a una aplicación, página web, máquina, proceso…

La usabilidad también se refiere al estudio de esas herramientas, normalmente previo o durante al desarrollo, para tratar de determinar cuál será el grado de usabilidad de las mismas. Para ello se realizarán pruebas empíricas y relativas:

• Empírica porque no se basa en opiniones o sensaciones, sino en pruebas de usabilidad realizadas en laboratorio u observadas mediante trabajo de campo (por ejemplo, con usuarios).
• Relativa porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas o de una comparación con otros sistemas similares.

Jakob Nielsen, en su libro Usability Engineering (1993), define los cinco componentes de calidad de sus “Objetivos de Usabilidad”:

• Capacidad de aprendizaje: ¿Cómo de fácil es para los usuarios realizar tareas básicas la primera vez que conocen el diseño?
• Eficiencia: Una vez que los usuarios han aprendido el diseño, ¿con qué rapidez pueden realizar tareas?
• Memorabilidad: Cuando los usuarios vuelven al diseño después de un período sin usarlo, ¿con qué facilidad pueden recuperar la competencia?
• Errores: ¿Cuántos errores cometen los usuarios, cómo de graves son estos errores y con qué facilidad pueden recuperarse de ellos?
• Satisfacción: ¿Cómo de agradable es utilizar el diseño?

9.3 Experiencia de usuario

La experiencia del usuario (UX) es el conjunto de factores y elementos relativos a la interacción del usuario con un entorno o dispositivo concretos, dando como resultado una percepción positiva o negativa de dicho servicio, producto o dispositivo.

La experiencia de usuario es un concepto subjetivo, ya que junto con la interacción del usuario también pueden ir acompañadas de aspectos relativos como las emociones, los sentimientos y la transmisión de la marca…

Inicialmente la experiencia de usuario se le empezó a dar importancia en la informática durante el auge de internet y el desarrollo páginas web.

Para diseñar una buena experiencia de usuario, debemos partir de un diseño de interacción adecuado y de un buen diseño de interfaz.

Por otro lado, la experiencia de usuario también puede verse alterada por la predisposición del usuario y su propia experiencia: tratar de utilizar una aplicación como otra parecida,

9.4 Interfaz de usuario

La interfaz de usuario (en inglés user interface, UI) es la capa que se sitúa entre el usuario y el propio producto (da igual que sea una aplicación o algo físico).

En esta interfaz de usuario aparecerán todos los elementos con los que el usuario interactuará de manera directa. Estos elementos generarán eventos o realizarán algún tipo de actividad en el producto, que normalmente generará una salida/respuesta.

10.1 Obtención de los requisitos

Tal como se ha dicho previamente, la obtención de requisitos se realiza al inicio del proyecto, antes de realizar ningún tipo de programación. Las maneras más habituales de obtener los requisitos son:

• Entrevistas con el cliente.
• Entrevistas con los usuarios que van a usar la aplicación.
• Conocer y analizar el estado actual (si lo tienen) de la metodología de trabajo. Ya que con la finalización del proyecto, esta metodología se deberá adaptar.

También es importante que el analista y jefe de proyecto se pongan en la piel del cliente, para poder hacer las preguntas oportunas y poder entender qué se quiere realizar.

10.2 Análisis de requisitos

Una vez obtenida la información por parte del cliente, se debe realizar un análisis de los requisitos, de esta manera, pueden surgir dudas, y en ese caso, volver al paso anterior.

Diferenciar los tipos de requisitos nos ayudará a entender el alcance de cada uno de ellos para así poder gestionar distintos apartados de la aplicación.

A la hora de analizar los requisitos, se suele crear una tabla donde se indicará:

• Tipo de requisito.
• Categoría, para poder separarlos entre los distintos tipos.
• Prioridad, para poder ordenarlos en base a lo prioritoario que son, y cuándo se deben abordar.
• Dependencias, ya que hay requisitos que pueden depender de otros. Por lo tanto, antes de poder realizar el requisito, deben terminarse las dependencias.
• Título descriptivo que resuma el requisito.
• Descripción del requisito, donde habrá que dar toda la información que sea necesaria para posteriormente poder desarrollarla.
• Razón del requisito, para poder entender mejor por qué debe realizarse.

A la hora de escribir los requisitos, podemos crear una tabla para cada uno de ellos de la siguiente forma:

En este caso, en el apartado “Dependencias” no se ha añadido nada ya que es el primer requisito de la aplicación.

11.1 Diseño conceptual de datos

Para la realización del diseño conceptual de datos, lo más habitual suele ser utilizar el conocido “modelo Entidad-Relación” que es utilizado para posteriormente realizar el diseño lógico, y finalmente el diseño físico de base de datos. Esto siempre que necesitemos un sistema de base de datos relacional.

El modelo de datos suele ser la parte fundamental de muchos tipos de aplicaciones, por lo que la toma de requisitos debe de haber sido correcta, y la creación del diseño del modelo de datos también.

11.2 Diagramas de caso de uso

Los diagramas de caso de uso describen una funcionalidad, que combina la interacción entre un usuario y un sistema, formando una secuencia de eventos.

La descripción del caso de uso se centra en qué se va a realizar, pero no en la manera en la que se va a hacer a nivel técnico. Debe usarse expresiones precisas, para evitar confusión, por lo que se busca sencillez y claridad.

Por ejemplo, a continuación dos ejemplos de cómo se podría representar el registro de un usuario y la autenticación en un sistema, haciendo uso de diagramas de caso de uso:

Tal como se puede ver, son diagramas abstractos que muestran de forma sencilla la acción a realizar.

11.3 Mapa de navegación

Teniendo en cuenta los distintos diagramas de comportamiento e interacción que hayamos obtenido, el siguiente paso es el de realizar la topología de la aplicación y los caminos entre las distintas funcionalidades que tendrá. El resultado obtenido será el del mapa de navegación de la aplicación.

El mapa de navegación de una aplicación, o una web, nos debe proporcionar una descripción general, y condensada, de los enlaces entre las principales áreas de contenido.

11.4 Prototipos

A medida que los pasos anteriores se van realizando, en paralelo se puede ir realizando el análisis de cómo queremos que sea la aplicación, en lo que se refiere al aspecto visual y el diseño del interfaz.

En los primeros pasos, se pueden realizar bocetos en papel o en aplicaciones, sin demasiado detalle, para acompañar a los distintos diseños que se han visto previamente. Estos bocetos pueden empezar a formar una idea genérica de cómo será la aplicación.

Para realizar modelos más concretos, y más cercanos a la realidad, se hace uso de sistemas de prototipos, que son un modelo (representación, demostración o simulación) fácilmente ampliable y modificable. Las características que suelen tener:

• Suelen contar con interfaz de usuario.
• Pueden tener funcionalidad de entrada y salida, así como de navegación.
• Existen distintas herramientas con las que realizarlos.
• Pueden tener distinto nivel de detalle.
• El cliente es capaz de entender lo que ve, por lo que es una manera de obtener feedback de manera rápida.
• Nos puede mostrar aspectos imprevistos no analizados en etapas anteriores. Por lo tanto, ayuda a mejorar y concretar las especificaciones de requisitos.