martes, 23 de mayo de 2017

La Guía Vital Para Contratar Excelentes Desarrolladores Freelance View


La Guía Vital Para Contratar Excelentes Desarrolladores Freelance

View


Técnicamente, contratar desarrolladores freelance nunca ha sido tan fácil como ahora, pero no te engañes cayendo en un falso sentido de seguridad. El número de plataformas freelance y desarrolladores dotados en el mercado está creciendo, sin embargo también crecen los desafíos asociados a encontrar, probar y seleccionar un candidato verdaderamente excelente.
Entonces, ¿Cómo hacemos esto? Bueno, hay muchos freelancers de donde escoger; muchos son buenos pero no todos. Mientras más grande sea el mercado, más grande será el riesgo. Con más candidatos de donde escoger, revisar referencias y hacer un filtro de cada candidato a escoger puede ser problemático, en especial si publicas un anuncio en una plataforma freelance importante y recibes cientos de aplicaciones.
Entonces ¿Cuál es la forma más segura y rápida de contratar desarrolladores freelance? Si piensas que estoy a punto de decir Toptal, te equivocas. Llámame anticuado, pero todavía creo en la información que se pasa de boca en boca y recomendaciones personales. En cualquier momento, puedo contactar a algunas personas con quien trabajé anteriormente y pedirles que me recomienden a un programador o diseñador freelance. Sin embargo, esto no funciona para todo el mundo; he pasado muchos años en el mundo de la tecnología y conozco muchas personas en quienes confío.
Obviamente, la confianza es un pre-requisito para cualquier compromiso serio en cualquier negocio y relación personal. Pero ¿qué pasa cuando no conoces a las personas indicadas y tienes que dirigirte a un enorme mercado freelance para buscar talento? Después de ver unas cuantas docenas de solicitudes, la gente empezará a dudar de su propio buen juicio, y será igualmente difícil confiar en extraños y sus promesas. La confianza es buena, la confianza vende.
Toptal está, en parte, construido sobre ese concepto – por esto es que nuestros desarrolladores pasan por un proceso de selección y por lo que podemos garantizar calidad, algo que otras plataformas freelance no hacen (y no pueden). Como verás, simplemente sacamos un par de desconocidos de la ecuación, permitiéndoles a los clientes que se enfoquen en lo realmente importante de un candidato, y así se reduce la exposición a cualquier tipo de riesgos.
Entonces ¿Qué es realmente importante? Echemos un vistazo a algunos aciertos y desaciertos al momento de contratar trabajadores freelance.

No Te Apresures

Esta es obvia; si quieres contratar desarrolladores freelance, debes tomarte tu tiempo y no lo puedes evitar. Por supuesto, esto se aplica a cualquier industria, pero en una industria de ritmo acelerado como la nuestra, no es tan fácil como parece. La competencia es brutal, las fechas de entrega son precisas, sin embargo gran parte del trabajo se puede hacer de manera remota. Contratar rápidamente a un par de desarrolladores freelance para acelerar el desarrollo, o unirse a un nuevo proyecto con una fecha de entrega precisa, suena muy tentador. Sin embargo, normalmente no es una buena idea.
Si es posible, deberías tratar de trabajar con el desarrollador antes de tomar la decisión final. La prueba puede involucrar un pequeño proyecto, o solo un número de pruebas. El período de evaluación no tiene que ser tan largo, siempre y cuando sea bien pensado. También es buena idea involucrar al resto de equipo; después de todo, ellos estarán trabajando con el nuevo desarrollador y puede que sean ellos quienes puedan identificar algunos problemas, que pueden pasar desapercibidos. Escucha sus opiniones, pídeles sus observaciones y no tomes la decisión solo.
Aun así, una evaluación puede que no funcione en todas las situaciones que se presenten. Si tu candidato es un desarrollador cualificado y con mucha experiencia, podría tomarse esto, un poco como un insulto profesional. Depende de su ego, sin embargo, no quieres tener prima donnas en tu equipo, ¿cierto?
Un candidato razonable debería estar dispuesto a hacer todo lo posible y estar de acuerdo con al menos algún tipo de evaluación. Si no, esto debe ser una señal de advertencia para ti; normalmente significa que el candidato no se toma el trabajo muy en serio y no quiere comprometer mucho de su tiempo y esfuerzo. Otra explicación puede ser la confianza, ej., los candidatos que asumen que están sobre-calificados para el trabajo y no tienen que demostrar nada. No hay nada de malo en un poco de arrogancia y competitividad, pero mucho de esto puede crear una fricción entre los miembros del equipo.

No Es Solo Sobre La Tecnología

Entonces, estás buscando un desarrollador freelance y tu enfoque está en sus capacidades de codificación más que cualquier otra cosa. Por supuesto, las habilidades técnicas son una prioridad, pero antes de llegar a eso, echemos un vistazo al lado humano de todo. ¿Cómo es la cultura de tu compañía? ¿Qué piensa tu equipo del nuevo desarrollador? ¿Qué piensa el candidato de ti?
¿Es el candidato una buena opción?
A pesar de que esto suena como una buena pregunta, los empleadores normalmente pasan por alto el aspecto cultural debido a su enfoque en las habilidades técnicas. Ahora, si estás apurado y necesitas un par de freelancers que te ayuden a cumplir con una fecha precisa en un mes o dos, el énfasis, claramente, debería estar en habilidad y ejecución. Sin embargo, si estás buscando personas que se comprometan por meses o años, que se puedan convertir en miembros del equipo a largo plazo y eventualmente, liderar sus propios equipos, es muy importante considerar el aspecto humano. De igual modo, los desarrolladores freelance pueden evolucionar rápidamente y llegar a ser miembros vitales del equipo y eventualmente líderes de éste. Si contratas un buen freelancer y todo funciona bien, en un año o dos podrías estar compartiendo una oficina con esa persona.
La tecnología cambia y evoluciona, así que los desarrolladores tienen que adaptarse y aprender nuevas habilidades mientras avanzan. La gente también puede cambiar, pero no es algo con lo que puedes contar. Con eso en mente, a veces es mejor escoger un candidato dispuesto a aprender nuevas habilidades y ser parte del equipo, y no un buen programador quien causa fricción en el equipo.
Hay un millón de programadores cada uno con su propia personalidad y cada compañía también es diferente, así que no hay una regla universal cuando se trata de compatibilidad cultural; esto depende de ti.
La mayoría de las habilidades técnicas se vuelven obsoletas en cuestión de años, pero el trato personal, profesionalismo y dedicación, no envejecen. Un desarrollador dispuesto a adaptarse a tendencias de una nueva industria y dominar nuevas habilidades, puede llegar a ser más valioso que un desarrollador que es excelente en un área en particular. Un proceso de entrevistas bien hecho debería hacer referencia a estos problemas.
Dependiendo de dónde estés y qué tipo de negocio diriges, puede ser una buena idea consultar con alguien acostumbrado a lidiar con desarrolladores freelance; en especial si no has tenido oportunidad de hacerlo tú mismo antes. Un número de fallas legales y de impuestos podría afectar negocios en ciertas jurisdicciones, así que si estás pensando en contratar a tu primer freelancer, asegúrate de consultar a tu contador (y hasta a tu abogado). Por suerte, en la mayor parte del mundo no te deberías ver afectado por leyes de trabajo desactualizadas o códigos de impuestos escritos en la era de la computación de tubos vacíos.

Abastecimiento, Preselección, Plan

Poniendo de lado las habilidades humanas, la aptitud técnica es la preocupación primaria para los empleadores. El número de tecnologías usadas en el desarrollo crece constantemente, al igual que la necesidad de hacer un filtro rápido y eficiente para los candidatos que no cumplen con lo requerido. Esto puede ser más difícil de lo que parece, en especial si necesitas candidatos capaces de trabajar en par de frameworks diferentes al igual que con idiomas. Hay mucho que cubrir.
Llevar a cabo una entrevista exhaustiva toma tiempo y esfuerzo. También requiere preparación, ya que necesitas formular tus preguntas cuidadosamente. Por suerte, Toptal te puede ayudar con una gran variedad de guías de contratación, las cuales cubren varios temas. Ya sea que estés buscando un trabajo o quieres contratar un desarrollador freelance, deberías revisar algunas de nuestras fuentes.
Vamos a dar un paso atrás y veamos un proceso de contratación típico. Una vez que ya has identificado tus necesidades y hayas empezado a prepararte para el proceso de abastecimiento, distintos métodos de encontrar candidatos indicados se hacen disponibles – abastecimiento interno, anuncios de trabajo tradicionales y las confiables recomendaciones personales.
Sin importar el método que escojas, tendrás que escribir un buen resumen del proyecto y una descripción del trabajo. Puedes usar las descripciones de trabajo de Toptal como un buen punto de partida; por ejemplo revisa nuestras descripciones de trabajo para desarrollador en front-end y back-end. Recuerda, si quieres desarrolladores talentosos, personas que puedan obtener un nuevo trabajo con pocos días de anticipo, debes hacer un poco de marketing. Esto no significa que tengas que vender exageradamente el proyecto, pero sí necesitas comercializarlo apropiadamente para atraer personas de calidad. Pregúntate si ¿tú mismo responderías a tu anuncio si fueses un desarrollador freelance de calidad?
Una vez empiecen a llegar las solicitudes, es muy probable que termines con mucha data sin procesar que necesita pasar por este proceso antes de empezar con la preselección de candidatos. Algunos candidatos simplemente no cumplirán con los requisitos y serán rechazados en esta primera etapa, otros serán preseleccionados, mientras que otros serán considerados candidatos de segundo nivel – candidatos que pueden realizar el trabajo, pero les resta atención aquellos con más talento. Es buena idea mantener en la mira a estos candidatos, en caso de que los necesites más adelante.

Las Entrevistas Necesitan Cubrir Aptitudes Técnicas y Mucho Más

Ahora que has reducido el campo de posibles candidatos, es hora de organizar algunas entrevistas. Esto no es solo hacer muchas preguntas de cultura general en tecnología a las personas, mientras tratas de descifrar si son una buena adición para tu equipo; éste es un proceso serio y necesita estar basado en mucha investigación y preguntas bien seleccionadas, diseñadas para sacar lo mejor (o peor) de cada candidato.
Obtener respuestas excelentes a preguntas técnicas incorrectas no te lleva a ninguna parte.
Aquí hay un par de puntos a tomar en cuenta cuando hagas preguntas técnicas:
  • No hagas preguntas de cultura general que tienen que ver más con la historia de la tecnología que con el trabajo como tal.
  • Trata de evitar preguntas encontradas comúnmente en guías de contratación; si es online, cualquiera que se haya preparado para la entrevista podría saberla.
  • Haz preguntas prácticas y abiertas, estas le dan al candidato un grado de libertad creativa.
  • Revisa algunos de los proyectos previos del candidato y haz algunas preguntas relevantes sobre estos.
  • Trata de aprender sobre los hábitos y habilidades profesionales del candidato, ej., ¿cada cuánto aprenden habilidades nuevas y pulen las que ya tienen?
Ahora, veamos cómo se vería esto en el mundo real, usando la guía de contratación PHP de Toptal. Por ejemplo, en vez de hacer preguntas de cultura/históricas como, “¿Cuándo se llegó al mainstream PHP 5?”, o “¿Por qué la función array_merge() causó problemas de compatibilidad al ejecutar el código heredado PHP4?”, deberías intentar hacer preguntas que vayan con los criterios expuestos arriba.
Aquí hay un buen ejemplo de nuestra guía PHP: “¿Qué son los traits? Da un ejemplo de un traitde declaración y una clase que use traitsmúltiples.”
Esta pregunta te ayudará a saber mucho más sobre el candidato, a diferencia de preguntas de cultura general. Los traits fueron introducidos en PHP 5.4, lo cual quiere decir que el candidato ha adquirido algunas de las últimas herramientas. Si quieres probar de verdad al entrevistado, revisa las notas de lanzamiento de PHP y enriquece la pregunta con unas adiciones aún más nuevas del registro de cambios de PHP 5.5.x y 5.6.x. Esta pregunta relativamente simple y directa, te dejará saber si el programador quiere o no adoptarse a los últimos avances y usar las mejores prácticas.
Por supuesto, el mismo principio se aplica a casi todo nicho, no solo PHP.
Otra buena idea es indagar más la trayectoria del candidato, al igual que sus proyectos completados. Cuando se solicita un trabajo, todo el mundo muestra su mejor trabajo, lo cual puede o no representar la calidad verdadera del candidato. ¿Qué tal si el candidato olvidó mencionar los trabajos de los que no se siente muy orgulloso? ¿Hay grandes vacíos en el currículo? ¿El desarrollador completo proyectos de cinco estrellas en cinco años, sin mencionar una docena de estos que fueron baratos y descuidados, pero que pagaban el alquiler? Estos vacíos deberían ser una advertencia, aunque no son necesariamente un factor de descualificación, mientras haya una explicación razonable para esto.
Ya no estamos en territorio técnico, esto nos trae a la personalidad del candidato y su integridad, la cual puede ser más difícil de juzgar que cualquier proeza de codificación.

Mantén A Tu Equipo En El Círculo Para Asegurar Una Buena Adición

En la mayoría de los casos, el nuevo desarrollador se unirá a un equipo ya existente, así que es vital informar al equipo e involucrarlos, en algún momento, del proceso de contratación. El equipo puede ofrecer opiniones invaluables sobre algunos aspectos del proyecto, ayudarte en la preparación de la entrevista y hacer preguntas relevantes (o hasta preguntas “atrevidas”), y, obviamente, ellos tienen un interés establecido en conseguir al candidato más adecuado. Después de todo, esta es la persona con quien tendrán que lidiar todos los días, tal vez por meses o años.
Ningún equipo quiere un colega incompetente. Usa esto para tu beneficio y usa a tu equipo para un beneficio adicional. No encontrarás una ausencia de interés.
Tu equipo también se puede asegurarse de que el “tipo nuevo” encaje bien. La personalidad ayuda mucho y, a veces, puede ser más importante que habilidades de codificación aburridas. ¿De qué vale contratar un desarrollador excepcional si no se lleva bien con el equipo? ¿Y si contratas a un desarrollador estrella que no está dispuesto a compartir su conocimiento con el resto del equipo?
Desafortunadamente, siempre existe la posibilidad de que tu contratado soñado se convierta en una decepción, un egocéntrico arrogante que todos odian, pero esa es otra razón importante por la cual debes consultar a tu equipo: “No me culpes, tú también lo aprobaste.”
Hablando en serio, un equipo armonioso es una máquina a todo vapor, y todo eslabón funciona perfectamente. Es bueno para la moral y para el negocio. ¿Qué pasa si agregas un desarrollador estrella de Android a tu equipo con la esperanza de que mejore la producción? Los grandes desarrolladores les gusta trabajar con sus compañeros, así que si tienes muchos desarrolladores sin experiencia a bordo, el nuevo talento puede que no sea la solución.
Sí, los desarrolladores que aprueban todas laspruebas Android y las preguntas en la entrevistaque les lanzas, sabrán exactamente qué hacer, pero ¿qué pasa si el resto del equipo no puede mantenerse a flote? ¿Esperas que tu nuevo desarrollador estrella le explique, a diario, cada punto a algunos desarrolladores “verdes”? ¿Esperas que el nuevo desarrollador esté contento con esto? ¿Qué va a pensar el resto del equipo – si contratas a alguien superior a ellos, a pesar de su antigüedad?
Volvamos a la analogía steampunk - un solo eslabón de titanio no hará al resto de la máquina tan fuerte como debería. Un gran desarrollador con ganas de tomar la iniciativa y compartir conocimiento puede ayudar a un par de compañeros, pero no a todos.
Para tener la seguridad de que no haya fricciones innecesarias, solo tienes que consultar a tu equipo, no hay otra salida.

Se Realista y Directo

Todos quieren contratar al mejor desarrollador, y todo desarrollador quiere conseguir el trabajo soñado, pero seamos realistas; todos deben operar dentro de un presupuesto restringido, así que el dinero tiende a ser un factor limitante. La gente buena cuesta un buen dinero, así que muchas organizaciones simplemente no pueden costear a los mejores desarrolladores.
Los empleadores usualmente quieren al mejor desarrollador que puedan costear, y en muchos casos en realidad no necesitan al mejor desarrollador en el mercado, porque el proyecto en el que están trabajando no requiere habilidades innovadoras. Los desarrolladores por su parte, quieren una buena compensación por sus esfuerzos, quieren trabajar en proyectos interesantes, con compañeros especializados.
Sin embargo, el dinero no lo es todo.
Si logras encontrar un desarrollador que comparta tu visión y crea en lo que haces, puede que recibas más de lo pediste. Si el desarrollador cree que están trabajando en un buen proyecto con mucho potencial a largo plazo, es muy probable que quieran hacer un trabajo excepcional y llevar a cabo sus tareas mucho mejor de lo esperado. El proyecto puede ser una buena oportunidad por los próximos años, y se puede ver muy bien en sus currículos.
Si por el contrario, el desarrollador se queda solo por el cheque y no cree que el proyecto es excepcional y promete, es muy poco probable que obtengas el mismo nivel de compromiso o lealtad.
El punto es: No puedes esperar milagros, no puedes esperar contratar al mejor freelancer, en especial si tienes un presupuesto corto y no estás trabajando en un proyecto de alta categoría. Debes enfocarte en conseguir el mejor desarrollador que puedas, no el mejor desarrollador del mundo.
El enlace original del articulo lo puede ver en la siguiente direccion:

miércoles, 10 de mayo de 2017

Introducción a Kotlin: Programación de Android Para Seres Humanos

Introducción a Kotlin: Programación de Android Para Seres Humanos



En el perfecto mundo de Android, el idioma principal de Java es realmente moderno, claro y elegante, puedes escribir menos haciendo más y cada vez que aparezca una nueva función, los desarrolladores pueden usarla aumentando la versión en Gradle. Al crear una aplicación agradable, la función parece totalmente comprobable, extensible y mantenible. Nuestras actividades no son demasiado grandes y complicadas, podemos cambiar las fuentes de datos de la base de datos a la web sin demasiadas diferencias y así sucesivamente. Suena bien, ¿verdad? Desafortunadamente, en el mundo de Android no es este ideal. Google sigue luchando por la perfección, pero todos sabemos que los mundos ideales no existen. Por lo tanto, tenemos que ayudarnos a nosotros mismos en ese gran viaje en el mundo de Android.
Can Kotlin replace Java?
Kotlin es un jugador importante en el mundo de Android. Pero, ¿podrá reemplazar a Java?

¿Qué es Kotlin, y Por Qué Deberías Usarlo?

Así que, el primer idioma. Creo que Java no es el maestro de la elegancia o la claridad y no es ni moderno ni expresivo (y supongo que estás de acuerdo). La desventaja es que por debajo de Android N, todavía estamos limitados a Java 6 (incluyendo algunas pequeñas partes de Java 7). Los desarrolladores también pueden adjuntarRetroLambda para utilizar expresiones lambda en el código, lo cual es muy útil al usar RxJava. Por encima de Android N, podemos usar algunas de las nuevas funcionalidades de Java 8, pero sigue siendo el viejo y pesado Java. Muy a menudo oigo a [desarrolladores de Android] (https://www.toptal.com/android) decir “Me gustaría que Android apoyara un lenguaje más agradable, como el iOS lo hace con Swift”. ¿Y si te dijera que puedes usar un lenguaje muy agradable y sencillo, con seguridad nula, lambdas, y muchas otras nuevas características? Bienvenido a Kotlin.

¿Qué es Kotlin?

Kotlin es un nuevo idioma (a veces conocido como Swift para Android), desarrollado por el equipo de JetBrains y ahora está en su versión 1.0.2. Lo que lo hace útil en el desarrollo de Android es que compila a bytecode JVM, y también se puede compilar con JavaScript. Es totalmente compatible con Java y el código de Kotlin puede ser simplemente convertido a código Java y viceversa (hay un plugin de JetBrains). Esto significa que Kotlin puede usar cualquier marco, biblioteca, etc., escrito en Java. En Android, se integra por Gradle. Si tienes una aplicación Android existente y quieres implementar una nueva función en Kotlin sin volver a escribir la aplicación completa, solo empieza a escribir en Kotlin y funcionará.
Pero, ¿cuáles son las “grandes nuevas características”? Permíteme enumerar algunas:

Parámetros de Funciones Denominadas y Opcionales

Fecha de crear Diversión(day: Int, month: Int, year: Int, hour: Int = 0, minute: Int = 0, second: Int = 0) {
  print("TEST", "$day-$month-$year $hour:$minute:$second")
}

Podemos Llamar Al Método Fechacreación De Distintas Maneras

 
Fechacreación(1,2,2016) prints:  ‘1-2-2016 0:0:0’
Fechacreación(1,2,2016, 12) prints: ‘1-2-2016 12:0:0’
Fechacreación(1,2,2016, minute = 30) prints: ‘1-2-2016 0:30:0’

Seguridad Nula

Si una variable puede ser nula, el código no compilará a menos que los obliguemos a hacerlo. El siguiente código tendrá un error:nullable Var puede ser nulo:
var nullableVar: String? = “”;
nullableVar.length;
Para compilar, debemos de verificar si es nulo o no:
if(nullableVar){
         nullableVar.length
}
O inclusive más corto:
nullableVar?.length
De esta manera, si el nullableVar es nulo, no pasa nada. De lo contrario, podemos marcar la variable como no anulable, sin un signo de interrogación después de tipo:
var nonNullableVar: String = “”;
nonNullableVar.length;
Este código se compila y si queremos asignar nulo al no-NullableVar, el compilador mostrará un error.
También es muy útil el operador de Elvis:
var stringLength = nullableVar?.length ?: 0
Entonces, cuando nullableVar es nulo (así nullableVar?.length resulta en nulo), stringLength tendrá valor 0.

Variables Mutables e Inmutables

En el ejemplo anterior, utilizo var cuando se define una variable. Esto es mutable, podemos reasignarlo cuando queramos. Si queremos que esta variable sea inmutable (en muchos casos deberíamos), usamos val (como valor, no variable):
val immutable: Int = 1
Después de eso, el compilador no nos permitirá reasignar a inmutable.

Lambdas

Todos sabemos lo que es un lambda, así que aquí voy a mostrar cómo podemos usarlo en Kotlin:
button.setOnClickListener({ view -> Log.d("Kotlin","Click")})
O si la función es el único o el último argumento:
button.setOnClickListener { Log.d("Kotlin","Click")}

Extenciones

Las extensiones son una característica de lenguaje muy útil, gracias a la cual podemos “extender” las clases existentes, incluso cuando son finales o no tenemos acceso a su código fuente.
Por ejemplo, para obtener un valor de cadena de texto de edición, en lugar de escribir cada vez editText.text.toString () podemos escribir la función:
fun EditText.textValue(): String{
  return text.toString()
 
}
O inclusive más corta:
fun EditText.textValue() = text.toString()
Y ahora, con cada instancia de EditText:
editText.textValue()
O, podemos agregar una propiedad que devuelve lo mismo:
var EditText.textValue: String
  get() = text.toString()
  set(v) {setText(v)}

Sobrecarga del Operador

A veces es útil si queremos agregar, multiplicar o comparar objetos. Kotlin permite la sobrecarga de: operadores binarios (más, menos, plusAssign, rango, etc.), operadores de matriz (get, set, get range, set range) y de operaciones iguales y de unarios (+ a, -a, etc.).

Clase de Datos

¿Cuántas líneas de código necesita para implementar una clase de usuario en Java con tres propiedades: copiar, igual, hashCode ytoString? En Kotlin sólo necesitas una línea:
Usuario de Clase de Datos(nombre del val: String, apellido del val: String, edad del val: Int)
Esta clase de datos proporciona métodos iguales (), hashCode () y copiar (), y tambiéntoString (), que imprime al Usuario como:
Usuario(nombre=John, apellido=Doe, edad=23)
Las clases de datos también proporcionan algunas otras funciones y propiedades útiles que se pueden ver en la documentación de Kotlin.

Extensiones de Anko

Utiliza Butterknife o extensiones de Android, ¿no? ¿Qué pasa si no necesitas ni siquiera usar esta biblioteca y después de declarar las vistas en XML simplemente lo usas desde el código por su ID (como con XAML en C #):
loginBtn.setOnClickListener{}
Kotlin tiene muy útiles [extensiones de Anko] (https://github.com/Kotlin/anko) y con esto no necesitas decirle a su actividad lo que esloginBtn, lo sabe simplemente “importando” xml:
import kotlinx.android.synthetic.main.activity_main.*
Hay muchas otras cosas útiles en Anko, incluyendo actividades de inicio, actividades medias y así sucesivamente. Este no es el objetivo principal de Anko - está diseñado para crear diseños de código fácilmente. Así que si necesitas crear un diseño de programación, esta es la mejor manera.
Esta es sólo una visión corta de Kotlin. Recomiendo leer el blog de Antonio Leiva y su libro - Kotlin for Android Developers, y por supuesto el sitio oficial de Kotlin.

¿Qué Es MVP y Por Qué?

Un lenguaje agradable, potente y claro no es suficiente. Es muy fácil escribir aplicaciones desordenadas con todos los idiomas sin una buena arquitectura. Los desarrolladores de Android (principalmente los que están empezando, pero también los más avanzados) a menudo dan a la Actividad la responsabilidad de todo lo que les rodea. La actividad (o Fragmento, u otra vista) descarga datos, guarda para enviar, los presenta, responde a interacciones de usuarios, edita datos y administra todas las vistas de niños. . . Y muchas veces mucho más. Es demasiado para objetos tan inestables como Actividades o Fragmentos (basta con rotar la pantalla y la Actividad dice ‘Adiós …’).
Una muy buena idea es aislar las responsabilidades de las opiniones y hacerlas tan estúpidas como sea posible. Las vistas (actividades, fragmentos, vistas personalizadas o lo que sea que presente datos en la pantalla) deberían ser responsables únicamente de la gestión de sus subvistas. Las vistas deben tener presentadores, que se comuniquen con el modelo y decirles lo que deben hacer. Esto en resumen, es el patrón Model-View-Presenter(para mí, debe ser nombrado Model-Presenter-View para mostrar las conexiones entre capas).
MVC vs MVP
“¡Hey, yo sé de algo así, y se llama MVC!” - ¿no crees? No, MVP no es lo mismo que MVC. En el patrón MVC, tu vista puede comunicarse con el modelo. Mientras utilizas MVP, no permites ninguna comunicación entre estas dos capas, la única forma en que View puede comunicarse con Model es a través de Presenter. Lo único que View sabe sobre Model puede ser la estructura de datos. View sabe cómo, por ejemplo, mostrar al Usuario, pero no sabe cuándo. Aquí hay un ejemplo sencillo:
La vista sabe que “soy actividad, tengo dosEditTexts y un botón. Cuando alguien hace clic en el botón, debo decírselo a mi presentador, y le paso los valores de EditTexts. Y eso es todo, puedo dormir hasta el siguiente clic o el presentador me dice qué hacer”.
Presenter sabe que en algún lugar es una vista y sabe qué operaciones puede realizar esta vista. También sabe que cuando recibe dos cadenas, debe crear el usuario a partir de estas dos cadenas y enviar datos al modelo para guardar, y si se guarda con éxito, decirle a la vista “Muestra información de éxito”.
El modelo sólo sabe dónde están los datos, dónde deben guardarse y qué operaciones deben realizarse en los datos.
Las aplicaciones escritas en MVP son fáciles de probar, mantener y reutilizar. Un presentador puro no debe saber nada sobre la plataforma Android. Debe ser puro clase de (o Kotlin, en nuestro caso) Java. Gracias a esto podemos reutilizar a nuestro presentador en otros proyectos. También podemos escribir fácilmente pruebas de unidad, probando por separado ModelView y Presenter.
El patrón MVP conduce a una base de código mejor y menos compleja al mantener la interfaz de usuario y la lógica de negocio verdaderamente separadas..
Una pequeña digresión: el MVP debe ser una parte de Uncle Bob’s Clean Architecture para hacer aplicaciones aún más flexibles y bien diseñadas. Voy a tratar de escribir sobre eso la próxima vez.

Aplicación De Ejemplo Con MVP Y Kotlin

Esto es suficiente teoría, ¡vamos a ver algunos códigos! Bueno, intentemos crear una aplicación sencilla. El objetivo principal de esta aplicación es crear un usuario. La primera pantalla tendrá dos EditTexts (nombre y apellido) y un botón (Save). Después de introducir el nombre y el apellido y hacer clic en “Guardar”, la aplicación debe mostrar “Usuario se guarda” y pasar a la siguiente pantalla, donde se muestra el nombre y apellido guardados. Cuando el nombre o apellido está vacío, la aplicación no debe guardar al usuario y entonces muestra un error que indica lo que está mal.
Lo primero que se debe hacer después de crear el proyecto Android Studio es configurar Kotlin. Deberías instalar el complemento Kotlin y después de reiniciar, en Herramientas > Kotlin puedes hacer clic en ‘Configurar Kotlin en Proyecto’. IDE agregará dependencias de Kotlin a Gradle. Si tienes algún código existente, puedes convertirlo fácilmente en Kotlin (Ctrl + Mayús + Alt + K o Codificar & gt; Convertir archivo de Java en Kotlin). Si algo no funciona y el proyecto no se compila, o Gradle no ve Kotlin, puedes comprobar el código de la aplicación disponible en GitHub.
Kotlin no sólo interopera bien con los marcos de Java y las bibliotecas, sino que le permite seguir utilizando la mayoría de las mismas herramientas con lasque ya estás familiarizado.
Ahora que tenemos un proyecto, comencemos creando nuestra primera vista: Create User View. Esta vista debe tener las funcionalidades mencionadas anteriormente, por lo que podemos escribir una interfaz para eso:
interface CreateUserView
: View {
  fun
showEmptyNameError() /* show error when name is empty */
  fun
showEmptySurnameError() /* show error when surname is empty */
  fun
showUserSaved() /* show user saved info */
  fun
showUserDetails(user: User) /* show user details */
}
Como se puede ver, Kotlin es similar a Java en declarar funciones. Todas son funciones que no devuelven nada y las últimas tienen un parámetro. Esta es la diferencia, el tipo de parámetro viene después del nombre. La interfaz de View no es de Android: es nuestra interfaz simple y vacía:
interface View
La interfaz de Presenter básica debe tener una propiedad del tipo vista, y al menos en el método (onDestroy por ejemplo), donde esta propiedad se establecerá como nula:
interface Presenter {
   var view: T?

   fun onDestroy(){
       view = null
   }
}
Aquí puede ver otra característica de Kotlin: puedes declarar propiedades en interfaces y también implementar métodos allí.
Nuestro CreateUserView necesita comunicarse con CreateUserPresenter. La única función adicional que necesita este presentador essaveUser con dos argumentos de cadena:
interface CreateUserPresenter: Presenter {
   fun saveUser(name: String, surname: String)
}
También necesitamos una definición de Modelo – es mencionado con anterioridad en el tipo de clase:
data class User(val name: String, val surname: String)
Después de declarar todas las interfaces, podemos empezar a implementar.
CreateUserPresenter será implementado enCreateUserPresenterImpl:
class
CreateUserPresenterImpl(override var view: CreateUserView?):
CreateUserPresenter {
 
  override fun
saveUser(name: String, surname: String) {
  }
}
La primera línea, con definición de clase:
CreateUserPresenterImpl(override
var view: CreateUserView?)
Es un constructor, lo utilizamos para asignar la propiedad de vista, definida en la interfaz.
MainActivity, which is our CreateUserViewimplementation, needs a reference toCreateUserPresenter:
class MainActivity :
AppCompatActivity(), CreateUserView {
 
  private val
presenter: CreateUserPresenter by lazy {
      CreateUserPresenterImpl(this)
  }
 
  override fun
onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      setContentView(R.layout.activity_main)
 
      saveUserBtn.setOnClickListener{
          presenter.saveUser(userName.textValue(),
userSurname.textValue()) /*use of textValue() extension, mentioned earlier */
 
      }
  }
 
 
 
  override fun
showEmptyNameError() {
      userName.error
= getString(R.string.name_empty_error) /* it's equal to userName.setError() -
Kotlin allows us to use property */
 
  }
 
  override fun
showEmptySurnameError() {
      userSurname.error
= getString(R.string.surname_empty_error)
  }
 
  override fun
showUserSaved() {
      toast(R.string.user_saved)
/* anko extension - equal to Toast.makeText(this, R.string.user_saved,
Toast.LENGTH_LONG) */
 
  }
 
  override fun
showUserDetails(user: User) {
     
  }
 
override fun onDestroy()
{
  presenter.onDestroy()
}
}
Al principio del ejemplo, definimos nuestro presentador:
private val presenter:
CreateUserPresenter by lazy {
      CreateUserPresenterImpl(this)
}
Se define como inmutable (val), y es creado por delegado perezoso, que se asignará la primera vez que sea necesario. Por otra parte, estamos seguros de que no será nulo (sin signo de interrogación después de la definición).
Cuando el usuario hace clic en el botón Guardar, View envía la información al Presenter con valores EditTexts. Cuando esto sucede, el usuario debe ser guardado, por lo que tenemos que implementar el método saveUser en Presenter (y algunas de las funciones del modelo):
override fun
saveUser(name: String, surname: String) {
  val user =
User(name, surname)
  when(UserValidator.validateUser(user)){
      UserError.EMPTY_NAME
-> view?.showEmptyNameError()
      UserError.EMPTY_SURNAME
-> view?.showEmptySurnameError()
      UserError.NO_ERROR
-> {
          UserStore.saveUser(user)
view?.showUserSaved()
          view?.showUserDetails(user)
      }
  }
}
Cuando se crea un usuario, se envía aUserValidator para comprobar su validez. Entonces, según el resultado de la validación, se llama el método apropiado. La construcción cuando () {} es igual que switch / case en Java. Pero es más potente - Kotlin permite el uso no sólo de enum o int en ‘case’, sino también de rangos, cadenas o tipos de objetos. Debes contener todas las posibilidades o tener una expresión. A continuación, cubre todos los valores UserError.
Al usar view? .showEmptyNameError () (con un signo de interrogación después del View), nos protegemos del NullPointer La vista puede anularse en el método onDestroy, y con esta construcción, no sucederá nada.
Cuando un modelo de usuario no tiene errores, le dice al UserStore que lo guarde y luego le indica al View que muestre el éxito y muestre los detalles.
Como se mencionó anteriormente, tenemos que implementar algunas cosas esenciales:
enum class UserError {
  EMPTY_NAME,
  EMPTY_SURNAME,
  NO_ERROR
}
 
object UserStore {
  fun
saveUser(user: User){
      //Save
user somewhere: Database, SharedPreferences, send to web...
  }
}
 
object UserValidator {
 
  fun
validateUser(user: User): UserError {
      with(user){
          if(name.isNullOrEmpty())
return UserError.EMPTY_NAME
          if(surname.isNullOrEmpty())
return UserError.EMPTY_SURNAME
      }
 
      return
UserError.NO_ERROR
  }
}
 
Lo más interesante aquí es *UserValidator.* Mediante el uso de la palabra objeto, podemos crear una clase *Singleton*, sin preocupaciones de hilos, constructores privados y así sucesivamente.
 
Adicionalmente: en el método validateUser (usuario), existe con (usuario) {} expresión. El código dentro de dicho bloque se ejecuta en contexto de objeto, se pasa con el nombre y el apellido son las propiedades del Usuario.
 
También hay otra pequeña cosa. Todo el código anterior, de enum a *UserValidator*, la definición se coloca en un archivo (la definición de clase de usuario también está aquí). Kotlin no te obliga a tener cada clase pública en un solo archivo (o nombre de la clase exactamente como archivo). Por lo tanto, si tienes algunos fragmentos cortos de código relacionados con (clases de datos, extensiones, funciones, constantes - Kotlin no requiere clase para función o constante), puedes colocarlos en un solo archivo en lugar de propagarlos a través de todos los archivos del proyecto.
 
Cuando un usuario se guarda, nuestra aplicación debería mostrarlo. Necesitamos otra vista: puede ser cualquier vista de Android, vista personalizada, fragmento o actividad. Elige la Actividad.
 
Por lo tanto, vamos a definir la interfaz de*UserDetailsView*. Puede mostrar al usuario, pero también debe mostrar un error cuando el usuario no está presente:
 
~~~ kotlin
interface
UserDetailsView {
  fun
showUserDetails(user: User)
  fun
showNoUserError()
}
Next, UserDetailsPresenter. It should have a user property:
interface
UserDetailsPresenter: Presenter {
  var user:
User?
}
Esta interfaz se implementará enUserDetailsPresenterImpl. Tienes que sobrescribir la propiedad del usuario. Cada vez que se asigna esta propiedad, el usuario debe actualizarse en la vista. Podemos usar un setterde propiedad para esto:
class
UserDetailsPresenterImpl(override var view: UserDetailsView?):
UserDetailsPresenter {
  override var
user: User? = null
      set(value)
{
          field
= value
          if(field
!= null){
              view?.showUserDetails(field!!)
          }
else {
              view?.showNoUserError()
          }
      }
 
}
La implementación UserDetailsView,UserDetailsActivity, es muy simple. Al igual que antes, tenemos un objeto presentador creado por la carga perezosa. El usuario al mostrar debe ser pasado por intención. Hay un pequeño problema con esto por ahora y lo resolveremos en un momento. Cuando tengamos el usuario de la intención, View necesita asignarlo a su presentador. Después de eso, el usuario se actualizará en la pantalla o, si es nulo, aparecerá el error (y la actividad terminará, pero el presentador no lo sabe):
class
UserDetailsActivity: AppCompatActivity(), UserDetailsView {
 
  private val
presenter: UserDetailsPresenter by lazy {
      UserDetailsPresenterImpl(this)
  }
 
  override fun
onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      setContentView(R.layout.activity_user_details)
 
      val
user = intent.getParcelableExtra(USER_KEY)
      presenter.user
= user
  }
 
  override fun
showUserDetails(user: User) {
      userFullName.text
= "${user.name} ${user.surname}"
  }
 
  override fun
showNoUserError() {
      toast(R.string.no_user_error)
      finish()
  }
 
override fun onDestroy()
{
  presenter.onDestroy()
}
 
}
Pasar objetos a través de intentos requiere que este objeto implemente la interfaz Parcelable. Esto es un trabajo muy “sucio”. Personalmente, odio hacer esto debido a todos los creadores, las propiedades, el ahorro, la restauración, y así sucesivamente. Afortunadamente, hay un pluginadecuado, Parcelable para Kotlin. Después de instalarlo, podemos generar la Parcelable con sólo un clic.
Lo último que debemos hacer es implementarshowUserDetails (usuario: Usuario) en nuestra ActividadPrincipal:
anular divertido showUserDetails(usuario: Usuario) {
  startActivity(USER_KEY to user)
/* extensión anko – empieza UserDetailsActivity y pasa el usuario a USER_KEY in
intent */
}
Y eso es todo.
Demo Android app in Kotlin
Tenemos una aplicación simple que guarda un usuario (en realidad, no se guarda, pero podemos agregar esta funcionalidad sin tocar el presentador o la vista) y lo presenta en la pantalla. En el futuro, si queremos cambiar la forma en la que se presenta el usuario en la pantalla, como por ejemplo: dos actividades a dos fragmentos en una actividad, o dos vistas personalizadas; los cambios solo se verán en clases Ver. Por supuesto, si no cambiamos la funcionalidad o la estructura del modelo. El presentador, que no sabe exactamente qué es View, no necesitará ningún cambio.

¿Qué Sigue?

En nuestra aplicación, Presenter se crea cada vez que se crea una actividad. Este enfoque, o su opuesto, si Presenter debe persistir a través de instancias de actividad, es un tema de mucha discusión a través del Internet. Para mí, depende de la aplicación, sus necesidades y el desarrollador. A veces es mejor destruir el presentador, a veces no. Si decides persistir uno, una técnica muy interesante es usarLoaderManager para eso.
Como se mencionó anteriormente, MVP debe ser parte de Uncle Bob’s Clean architecture. Por otra parte, los buenos reveladores deben utilizarDagger para inyectar dependencias de los presentadores a las actividades. También ayuda a mantener, probar y reutilizar el código en el futuro. Actualmente, Kotlin trabaja muy bien con Dagger (antes del lanzamiento oficial no era tan fácil) y también con otras bibliotecas útiles de Android.

Conclusión

Para mí, Kotlin es un gran lenguaje. Es moderno, claro y expresivo, mientras se sigue desarrollando por grandes personas. Y podemos usar cualquier versión nueva en cualquier dispositivo y versión Android. Lo que me hace enojar en Java, Kotlin lo mejora.
Por supuesto, como he dicho nada es ideal. Kotlin también tiene algunas desventajas. Las versiones más recientes de plugins de Gradle (principalmente de alfa o beta) no funcionan bien con este idioma. Mucha gente se queja de que el tiempo de construcción es un poco más largo que el Java puro, y los apks tienen algunos MBs adicionales. Sin embargo, Android Studio yGradle siguen mejorando y los teléfonos tienen cada vez más espacio para aplicaciones. Es por eso que creo que Kotlin puede ser un lenguaje muy agradable para todos los desarrolladores de Android. Sólo inténtalo y comparte en la sección de comentarios debajo, lo que piensas.

El articulo original lo puedes ver en el siguiente enlace.