Ver la Versión Completa : [ NOTICIA ] Microsoft compra Xamarin, ¿qué le depara a RoboVM? (cerrado a los dos meses...)
mocelet
25/02/16, 10:00:22
Microsoft ha comprado Xamarin (https://blog.xamarin.com/a-xamarin-microsoft-future/), famosa por sus productos para poder desarrollar apps en iOS y otras plataformas con C#. Esta última a su vez adquirió RoboVM hace unos meses para hacer lo propio con Java.
En la nota de prensa no hablan de Java para nada, normal por otro lado si la idea de Microsoft es integrar Xamarin con su ecosistema Visual Studio y su experimento con Java hace años (Visual J++ y J#) finalizó malamente.
¿Qué futuro le deparará a RoboVM? Este producto nació casi de la mano de proyectos como LibGDX y PlayN para crear en Java juegos multiplataforma (y son los únicos casos en los que el desarrollador no precisa pagar licencia para uso comercial), de hecho el creador de LibGDX forma parte del equipo de RoboVM. En sus redes sociales de momento no han comentado nada.
¿Alguno usáis RoboVM? ¿Qué os parece la noticia? ¿Creéis que acabará muriendo por no prestarle atención?
EDIT: En efecto, dos meses ha tardado Microsoft en darle carpetazo... https://robovm.com/robovm-winding-down/
kriogeN
25/02/16, 11:34:13
Microsoft ha comprado Xamarin (https://blog.xamarin.com/a-xamarin-microsoft-future/), famosa por sus productos para poder desarrollar apps en iOS y otras plataformas con C#. Esta última a su vez adquirió RoboVM hace unos meses para hacer lo propio con Java.
En la nota de prensa no hablan de Java para nada, normal por otro lado si la idea de Microsoft es integrar Xamarin con su ecosistema Visual Studio y su experimento con Java hace años (Visual J++ y J#) finalizó malamente.
¿Qué futuro le deparará a RoboVM? Este producto nació casi de la mano de proyectos como LibGDX y PlayN para crear en Java juegos multiplataforma (y son los únicos casos en los que el desarrollador no precisa pagar licencia para uso comercial), de hecho el creador de LibGDX forma parte del equipo de RoboVM. En sus redes sociales de momento no han comentado nada.
¿Alguno usáis RoboVM? ¿Qué os parece la noticia? ¿Creéis que acabará muriendo por no prestarle atención?
No conocía RoboVM, pero tampoco lo habría usado, lo poco que acabo de ver no te abstrae de la plataforma. Sigues necesitando usar toda la arquitectura de iOS (UIStoryBoard, UIViewController, etc), y con los cambios que hace Apple tan a menudo que de una versión a otra de XCode te cambian algo que te obliga a rehacer gran parte de tu código, si encima dependes de que un 3º actualice, apaga y vamonos.
Además, conociendo a Apple, capaces son de decir un día "No aceptamos esta app porque está hecha en Java". Ya en sus condiciones de uso dicen que sólo se aceptan aplicaciones hechas con XCode oficiales, si usas un XCode no oficial te la rechazan.
En cuanto a Xamarin, si lo conocía, y lo mande a la mierda por lo mismo que digo arriba. No te abstrae de la lógica de la plataforma. Si quieres una app en Android y otra en iOS tienes que hacer las Activity y Fragment por un lado y los UIViewController por otro. Lo único que no tienes que repetir son los modelos, que es lo más sencillo y lo que menos tiempo se tarda en hacer. Y si quiero usar la librería tal porque me gusta, no puedo si no la reescribo primero en C#.
Dexafree
25/02/16, 11:42:37
Vaya por delante que nunca he utilizado este tipo de plataformas más allá de una prueba básica.
Lo único que no tienes que repetir son los modelos, que es lo más sencillo y lo que menos tiempo se tarda en hace
Si se consigue montar una buena arquitectura donde la lógica de negocio quede totalmente separada del framework imagino que puedes llegar a ahorrar bastante código también, teniendo que rehacer solo las vistas (Activity/Fragment únicamente como vistas).
Eso si, la persistencia es otro cantar (siempre puedes depender de interfaces en vez de implementaciones concretas).
Y si quiero usar la librería tal porque me gusta, no puedo si no la reescribo primero en C#.
Esto es lo que mas me ha echado para atrás siempre a la hora de probar alguna plataforma de desarrollo multiplataforma "a la vez", que pierdes prácticamente todas las librerias que hay disponibles para el sistema.
Y si tienes que convertir alguna a otro lenguaje, para eso haz la app nativa ya xD
kriogeN
25/02/16, 11:55:27
Si se consigue montar una buena arquitectura donde la lógica de negocio quede totalmente separada del framework imagino que puedes llegar a ahorrar bastante código también, teniendo que rehacer solo las vistas (Activity/Fragment únicamente como vistas).
Al final para hacer la separación de forma real tienes que montar tal arquitectura que pierdes menos tiempo escribiéndolo en nativo.
Porque ya no es sólo las Activity/Fragment. Las Push tienes que programarlas con GCM y con APNS respectivamente igualmente. Los Adapter y los UITableViewDataSource y Delegate también tienes que hacerlos por separado, etc...
Hacer una abstracción de todo eso es chungo.
mocelet
25/02/16, 11:57:30
El día que Apple discrimine por lenguaje de programación se quedan sin juegos en la App Store xDDD La mayor parte están hechos en Unity, Corona o similares que funcionan con una capa intermedia para adaptarse a la máquina virtual de iOS y ni siquiera se programan en Obj-C o Swift ni usan el entorno de Xcode para nada.
Precisamente en los juegos es donde menos afecta el tema de la interfaz de usuario nativa porque normalmente ya implementan la suya propia al estar hechos directamente sobre motores OpenGL. Donde sí hace falta código específico de la plataforma es para temas como las compras in-app o la publicidad, pero son funciones tan habituales que las soluciones ya suelen facilitarlas.
En ese ámbito sí compensa tener una lógica común y luego código más o menos específico en las partes nativas que hagan falta.
kriogeN
25/02/16, 12:04:17
El día que Apple discrimine por lenguaje de programación se quedan sin juegos en la App Store xDDD La mayor parte están hechos en Unity, Corona o similares que funcionan con una capa intermedia para adaptarse a la máquina virtual de iOS y ni siquiera se programan en Obj-C o Swift ni usan el entorno de Xcode para nada.
Precisamente en los juegos es donde menos afecta el tema de la interfaz de usuario nativa porque normalmente ya implementan la suya propia al estar hechos directamente sobre motores OpenGL. Donde sí hace falta código específico de la plataforma es para temas como las compras in-app o la publicidad, pero son funciones tan habituales que las soluciones ya suelen facilitarlas.
En ese ámbito sí compensa tener una lógica común y luego código más o menos específico en las partes nativas que hagan falta.
Si, para juegos no te digo que no.
AdminFildo
26/02/16, 21:58:19
Solo pasaba para comentar (que curro con xamarin en el dia a dia) Xamarin en iOS no es interpretado, es decir c# es un lenguaje que se convierte a IL (lenguaje intermedio) y luego se """interpreta""" (.net no es como java no se interpreta, se compila en tiempo de ejecucion el IL a codigo maquina, pero bueno como concepto sobra). Xamarin en iOS compila a nativo 100%.
En cuanto a reutilizacion de codigo creedme que es una maravilla :) si teneis mas dudas preguntad estare encantado de comentaros lo que sea :)
mocelet
26/02/16, 23:20:14
Solo pasaba para comentar (que curro con xamarin en el dia a dia) Xamarin en iOS no es interpretado, es decir c# es un lenguaje que se convierte a IL (lenguaje intermedio) y luego se """interpreta""" (.net no es como java no se interpreta, se compila en tiempo de ejecucion el IL a codigo maquina, pero bueno como concepto sobra). Xamarin en iOS compila a nativo 100%.
En cuanto a reutilizacion de codigo creedme que es una maravilla :) si teneis mas dudas preguntad estare encantado de comentaros lo que sea :)
El tema de rendimiento en efecto parece que está superado y hay benchmarks (https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.ptoo8elzx) donde Xamarin, RoboVM y otros se acercan bastante al rendimiento del mismo código escrito en el lenguaje "estándar" de la plataforma.
A mí me interesa más RoboVM, si bien conceptualmente será lo mismo que Xamarin. La cuestión que más interesa es hasta qué punto es necesario conocer el API de la plataforma destino para crear una app.
- En las interfaces de usuario, ¿existe un API genérica de, digamos, barra de título / menú / lista scrollable / etc.? ¿O hay que tratar de forma independiente una u otra plataforma? Está claro que para personalizar cosas específicas de la plataforma no queda otra.
- En tema de servicios de red, ¿abrir un socket y transferir datos es un API independiente de la plataforma? ¿Y para notificaciones push?
- Hilos, temporizadores, etc. ¿se usa el mecanismo habitual de la plataforma de desarrollo o el de la plataforma destino? Me gustaría no tener que saber que en iOS se usa el Grand Central Dispatcher y en Android los Executor, por ejemplo.
- Tema almacenamiento local, ¿hay un API que te aísle que en iOS son plist y en Android preferencias por poner un ejemplo?
Como eso son muchas preguntas en realidad solo voy a aprovechar la oportunidad para hacerte una :D ¿Qué porcentaje de código de un proyecto con Xamarin que tengáis para iOS y Android es independiente de la plataforma?
Supongo además que habréis creado una biblioteca intermedia para "generalizar" funciones habituales y no tener que implementar los detalles específicos de cada plataforma en todos los proyectos.
mocelet
15/04/16, 15:16:34
Irónico. Es la palabra que mejor lo define. Ayer me decidí a empezar a desarrollar juegos con LibGDX y RoboVM, me doy de alta para pedir la licencia de desarrollador indie y... hoy me contestan que Microsoft ha decidido cerrar el chiringuito de Java en iOS, adiós RoboVM.
https://robovm.com/robovm-winding-down/
Ya me lo temía hace dos meses cuando Microsoft compró Xamarin (y RoboVM venía en el pack). Ains...
EDIT: El creador de LibGDX comenta que ya están trabajando en la integración (http://www.badlogicgames.com/wordpress/?p=3925) con Intel Multi OS Engine (https://software.intel.com/en-us/multi-os-engine), que viene a ser lo mejor después del extinto RoboVM (del que también era creador, por cierto). De todas formas casi me voy a olvidar de andar con "emuladores", SpriteKit + Swift y a correr, aunque tenga que escribir el mismo código dos veces, uno en Java y otro en Swift..
Dexafree
15/04/16, 16:48:11
Justo venía a este hilo a avisar del cierre.
Lo siento por lo de la licencia tío... Y eso que se pedía fuertemente que si Microsoft no lo iba a mantener (eso creo que ya lo habian dicho), al menos que lo hiciera público... al final lo cierran y listos. En fin.
Al menos dicen que devuelven el dinero, y puedes usarlo hasta 2017 (parece que al igual que el cierre de Parse se esta extendiendo el hecho de avisar con tiempo).
De todas formas casi me voy a olvidar de andar con "emuladores", SpriteKit + Swift y a correr
Lo utilicé para montar un front-end de visualización de algunos algoritmos y fue bastante cómodo trabajar con ello, creo que a la larga vale la pena.
Aprovecho para dejar este artículo...
https://medium.com/teach-code/your-hybrid-app-is-going-to-kill-you-416041d27eac#.k698ffboh
mocelet
15/04/16, 17:07:05
Bueno, la licencia de indies era gratuita, así que solo he perdido las ganas xD
RoboVM era software libre antes, luego lo cerraron, antes de que lo comprara Microsoft. Volverlo a abrir y que lo coja alguien podría ser una opción, pero me da que no es viable.
Lo de Parse es distinto, siguen manteniendo los servidores, te ofrecen un plan de migración... aquí ya no hay más mantenimiento, lo dejan a su suerte como está. Como no depende de servicios en red no tienen problema, pero si sale una versión nueva de iOS y se estropea algo, tu app deja de funcionar. Si te encuentras con un bug, te lo comes con patatas que no van a arreglar nada a partir de hoy.
El artículo que indicas es muy apropiado, esto de escribir una vez y que valga para todo realmente vale para juegos o apps muy sencillas que no se integren demasiado en cada ecosistema O ni eso, si luego quieres integrar los juegos de iOS con Game Center, los de Android con Play Games, tener notificaciones de APNS en uno, de GCM en otro, etc. ya olvida lo de escribir una vez salvo que te hagas una biblioteca genérica por debajo.
Swift y SpriteKit son cómodos y potentes, de hecho es más fácil de usar que LibGDX porque es de más alto nivel, pero ya toca reescribirse todo. Paciencia supongo xD
vBulletin® v3.8.1, Copyright ©2000-2026, Jelsoft Enterprises Ltd.