Elegir tu Ruta con la API 2.0

La entrada que encontrarás a continuación se corresponde con la traducción al Español de una entrada original de Geoff Perlman (CEO de Xojo) publicada originalmente en inglés en el Blog de Xojo. En ella encontrarás los diferentes caminos que puedes tomar a la hora de migrar proyectos hacia la nueva API 2.0 disponible a partir de Xojo 2019r2.

Para que algo resulte fácil de aprender y de usar ha de ser lo más intuitivo y consistente posible. Sobre los más de 20 años pasados se han añadido varias API en Xojo que no eran especialmente intuitivas o consistentes. Si bien los usuarios más veteranos se han ido acostumbrando a ellas, estas pueden resultar más difíciles de adoptar para los nuevos usuarios. La API 2.0 es nuestra solución.

Lo hemos hecho creando un significativo conjunto de guías sobre el modo en el que se utilizan los nombres en la API, y aplicando dichas reglas a las API ya existentes. Las API que seguían dichas reglas se han dejado tal cual; en aquellas en las que no era así, las hemos cambiado para que se ajusten a estas reglas. En restrospectiva, como suele decirse, es un 20/20. Mirando hacia atrás, hubiese sido genial el haber establecido dichas relgas en 1998 antes de que hubiésemos publicado la v1.0, pero el hecho es que no lo hicimos y el hecho de que no lo hubiésemos hecho entonces no es motivo para evitar el hacerlo ahora. Siempre realizamos nuestra planificación a largo plazo, y por tanto hemos de realizar cambios para que dicho futuro sea posible. El hecho de que aun continuemos aquí más de 20 años después sugiere que algo estamos haciendo bien.

Si eres uno de estos usuarios veteranos que se han habituado a las inconsistencias corregidas por la API 2.0, puede que te estés preguntando si hay algún tipo de valor para ti en su uso. ¡La respuesta es un sí sin paliativos! Mientras que te llevará muy poco tiempo acostumbrarte a las nuevas API, lo que encontrarás es que comenzarás a ser incrementalmente más productivo debido a que estas son realmente consistentes. Lo que encontrarás (tal y como yo mismo he comprobado) es que imaginarás cuál es el nombre en la API y muy probablemente estés en lo cierto. He realizado personalmente el 95% de las actualizaciones en la Referencia del Lenguaje para la API 2.0. La wiki de la documentación carece de autocompletado lo que significa que he tenido que realizar una doble comprobación de todo el código que estaba actualizando. En poco tiempo he encontrado que raramente cometía algún error, gracias a que la API 2.0 es realmente consistente. Verás absolutamente mejoras en la producitividad una vez que te acosumbres, algo que ocurrirá en realmente un corto periodo de tiempo.

Mientras que la API 2.0 es un avance importante para Xojo en términos de consistencia y que resulta más intuititva, para aquellos de vosotros a cargo de proyectos de gran tamaño, podéis sentiros como si la migración es una tarea pesada. Dependiendo del tamaño, puede que te encuentres desde pocas a miles de advertencias de deprecaciones con las que has de lidiar, cada una de las cuales puede corresponderse con la necesidad de realizar un cambio.

Puede que pienses o estés asumiendo que has de realizar una actualización de tus proyectos, pero este no es necesariamente el caso. El porcentaje de actualización de un proyecto y el cuándo hacerlo depende significativamente de cuan importante sea para ti actualizar tus proyectos actuales a la API 2.0.

En primer lugar, es importante comprender que la mayoría de las API deprecadas estarán disponibles por una cantidad de tiempo realmente elevada. Es posible (quizá lo más probable) que estas continúen existiendo por toda la vida de tu proyecto de software. Puede que decidas no actualizar una porción de tu proyecto o bien actualizar sólo pequeñas porciones que lo requieran cuando sea sólo estrictamente necesario.

Muchas de las API deprecadas comparten su implementación con la API que las sustituyen. Un buen ejemplo es RecordSet.MoveNext y RowSet.MovenToNextRow. Si un bug se soluciona en MoveToNextRow este también quedará corregido muy probablemente y de forma automática en RecordSet.MoveNext, incluso aunque dicho método esté deprecado.

En el caso de que encuentres un bug en una API deprecada que aun estés utilizando, prueba en primer lugar la nueva API que la sustituye y observa si el bug ya no es reproducible. Si es así, tienes una solución inmediata: sólo has de actualizar dicho uso de la clase deprecada con la nueva.

Si el bug aun continúa existiendo en la nueva clase, por favor informa del bug utilizando Feedback. Una vez esté solucionado es más que probable que este también esté solucionado en la clase deprecada, asumiendo que comparta la implementación subyacente con la clase deprecada lo cual, nuevamente, es así en muchos casos.

Cuando decidas que hacer sobre la API 2.0 en un proyecto concreto, tus opciones son:

• No Actualizar. Puedes optar por no actualizar un proyecto existente a la API 2.0. A continuación puedes actualizar solo aquellas partes estrictamente necesarias debido a la corrección de un bug o la introducción de nuevas características.
• Actualizar de forma Incremental. Otra opción consiste en actualizar tu código de forma incremental como paso adicional antes de refactorizar o añadir nuevo código a una parte concreta del proyecto. Este es el camino que hemos elegido para el IDE de Xojo dado que se trata de un proyecto realmente grande cuya actualización llevaría una buena cantidad de meses si quisiéramos hacer toda la actualización a la vez.
• Actualizar todo a la vez. Por último, puedes decidir ir allá y actualizar todo tu proyecto de una vez. Esto tiene la ventaja de que te permite enfocarte exclusivamente en las nuevas API y no tener que cambiar entre lo anterior y lo nuevo, así como ir y volver entre antiguos proyectos y nuevos proyectos.

Si escoges no actualizaar un antiguo proyecto o bien hacerlo de forma incremental y encuentras que resulta intrusivo o bien te distrae el ver de forma constante las advertencias de deprecación cuando utilizas la característica Analyze Project (Analizar Proyecto), entonces puedes desactivar estas advertencias seleccionando Project > Analysis Warnings.

La API 2.0 se ha introducido para proyectos de escritorio, pero también llegará para los proyectos web con el Framework Web 2.0, y más adelante para dispositivos móviles en Android y posteriormente para iOS. Como resultado será importante utilizar las nuevas API pero, para muchos de vosotros, puede tener sentido utilizarlas sólo con nuevos proyectos y/o de forma esporádica con antiguos proyectos.

La API 2.0 es un gran cambio y el cambio a veces puede ser difícil. Ciertamente se está más cómodo cuando se está en lo que resulta familiar. Aun así, el cambio es necesario algunas veces para seguir avanzando. Afortunadamente, en el caso de la API 2.0, la hemos diseñado para que sea tremendamente flexible sobre las opciones entre las que puedes elegir para tus proyectos actuales.

Lee más entradas del blog sobre esta transición.