Blog!

Busqueda de información

Uso básico del debugger de Xcode

Ratio: 2 / 5

Inicio activadoInicio activadoInicio desactivadoInicio desactivadoInicio desactivado
 

Una de las etapas más importantes y muchas veces más menospreciado del desarrollo de Software esta relacionada con la detección y corrección de errores en nuestro código.

Cada plataforma contempla herramientas (algunas más eficaces que otras), para apoyarnos con estas tareas, sin embargo no solemos sacar provecho de las mismas y nos limitamos a utilizar las clásicas impresiones a pantalla en los lugares donde consideramos pertinente, que si bien nos resultan de gran utilidad, también propician la generación de códigos sucios que agregan información de debug misma que podría evitarse.

Las herramientas para el desarrollo de móviles no son las excepción y ahora que he estado trabajando con Xcode (herramienta para el desarrollo de Apple), me sorprendí de algunas de las características presentes en la herramienta y que revisaremos a continuación.

La detección y manejo de errores es un tema extremadamente complicado por lo que por ahora solo me enfocaré en la parte de detección de errores asociados con asignación e inicialización de variables, y control de flujo de la aplicación sin entrar al detalle de la detección de memory leaks, medición de los recursos consumidos que son temas más avanzados y que requerirán de sus propios posts.

Al finalizar el desarrollo de un código lo más natural es probarlo (inicialmente en el emulador), la herramienta Xcode inicia de manera automática cuando queremos probar nuestro código una sesión de debug, misma que durará mientras no finalicemos la ejecución de nuestra aplicación. La vista de debug se divide en 3 secciones principales que mostraremos a continuación:

Control de flujo de la aplicación

Al igual que la mayoría de las herramientas de debug, Xcode nos permite controlar el flujo de nuestra aplicación y detenernos en secciones específicas según lo requriamos con la definición de “breakpoints” en los que podremos detenernos para prestar atención a detalles significativos como el estado de las variables en un momento particular o el momento exacto en el que estoy entrando a una sección de código (que cobra gran importancia cuando gran parte de las llamadas ocurren orquestadas por el SO y no necesariamente cuando nosotros esperamos que ocurran).

El área de debug no se presenta normalmente a menos de que ocurra cualquiera de las siguientes tres condiciones:

-       Se solicite mediante el botón  la presentación del mismo

-       Ocurra una salida a la consola definida en código o mediante un breakpoint (más al respecto en posteriormente)

-       La ejecución del código se tope con un breakpoint

Definición de breakpoints y personalización del flujo de debug

Los breakpoints se definen en la canaleta al lado izquierdo del área de código simplemente dando click sobre la línea en la que esperamos se haga una pausa durante la ejecución del código. Estos puntos de quiebre pueden activarse y desactivarse a conveniencia de acuerdo a las secciones que estemos trabajando en uno momento particular, sin embargo una de las características que me pareció más importante es la versatilidad de la definición de los breakpoints en la herramienta que brinda muchas opciones para agilizar el procedimiento de debug dando click derecho sobre el breakpoint y seleccionando la opción “Edit Breakpoint” obtenemos el siguiente menú:

Algunas de las opciones que tenemos son:

-       Ejecución de un AppleScript

-       Capturar un cuadro de OpenGL ES (para aplicaciones con uso de 3D)

-       Ejecutar un comando de debug (como la impresión de valores de memoria de un objeto)

-       Impresión en la consola de un mensaje de log

-       Ejecución de un comando Shell

-       Reproducción de un sonido

Una de las principales ventajas de esto es la capacidad de definir la ejecución de acciones que nos permitan conocer el flujo y valores de los objetos dentro de nuestra aplicación o el paso por segmentos de código sin la necesidad de detener el flujo, aunque como siempre en algunas ocasiones se requiere de un control mucho más fino por lo que también tenemos las clásicas opciones de control de flujo:

Estas herramientas nos permiten realizar las siguientes acciones:

  1. Habilitación global de breakpoints (independiente a la habilitación y deshabilitación específica)
  2. Continuar con el flujo de ejecución normal
  3. Pasar a la siguiente línea de código sin entrar a las llamadas externas
  4. Pasar a la siguiente línea de código entrando a las llamadas externas
  5. Salir de una llamada externa

Las opciones 3 y 4 cuentan además con comportamientos adicionales de acuerdo a teclas modificadoras que se pueden utilizar (control y control + shift), para tener aún mas control cuando tenemos el manejo de múltiples threads.

Valores de variables en tiempo e ejecución

Otro de los problemas tradicionales a los que nos enfrentamos cuando estamos buscando errores dentro de una aplicación es el conocimiento de los valores que tienen nuestros objetos durante la ejecución. Existen tres formas de conocer la información de las variables sin necesidad de llenar nuestro código de NSLogs, y son las siguientes:

  • Sobre nuestro código haciendo click sobre una variable con contexto activo mientras presionamos la tecla opt nos aparece un menú contextual indicando información relevante del objeto (incluyendo su clase y dirección de memoria), incluyendo además dos opciones adicionales que nos permiten ver una representación gráfica o una representación tipo consola con la información más relevante del objeto:

Represetanción gráfica:

Representación consola:

  • Interactuando directamente sobre el área de debug que cuenta con una consola interactiva podemos también solicitar la impresión de un objeto relevante en el contexto en que se encuentra nuestra aplicación:

  • Combinando las opciones que vimos anteriormente de configuración de breakpoint podemos lograr un efecto similar:

            Lo cual nos da un resultado como sigue:

Personalización de comportamientos

Finalmente y como cualquier herramienta que se respete Xcode nos permite configurar ciertos aspectos de su comportamiento para adaptarse lo mejor posible a nuestra forma particular de trabajo, en el caso de Xcode esto se logra a través de una característica conocida como Behaviors (o comportamientos en español). La herramienta ya esta configurada con algunos comportamientos. Los referentes a las opciones de debug los podemos encontrar en:

Xcode >> Preferences >> Behaviors

En la sección running, sin embargo nosotros podemos crear y modificar nuestros propios comportamientos para adaptarse a nuestro modo de trabajo y funcionando mediante atajos del teclado permitiéndonos agilizar no solo las tareas de limpieza de código sino de todo el ciclo de desarrollo.

Log in