Sobre Apache Cordova y su uso para el desarrollo multiplataforma

dec · #1 22-06-2017

¡Hola a todos!

He leído vuestros mensajes esta mañana, pero, no he podido responderlos hasta ahora mismo. Pido disculpas. ¡Y vamos allá!

Cita:

Empezado por newtron

Muy buen artículo.

Pero como está en "La Taberna" no le he hecho mucho caso.

Bueno, tú de lo que leas créete la mitad de la mitad por si acaso.

Cita:

Empezado por mamcx

Mucho mejor que Cordova, es usar React Native . Si vamos a sufrir el uso de JS entonces al menos usar la opción que da el mejor desempeño:

https://facebook.github.io/react-native/

(O http://www.telerik.com/nativescript tambien)

(Ademas que es posible usar TypeScript, que es JS pero menos horrible)

P.D: React Native es lo mas cercano a desarrollo nativo usando JS que hay.

Cita:

Empezado por roman

Leyendo...

Mientras tanto...

A ver compañero

, que el maese dec se ha echado un rollote informativo y como que eso de desdeñar la info de un plumazo, pues, no digo que no tengas razón, que muchas veces la tienes, pero, ¿no podrías ahondar un poco y así ayudarnos a fijar posturas?

LineComment Saludos

Bueno, pero, también para eso estamos aquí, ¡para discutir!

Cita:

Empezado por mamcx

La informacion de dec esta bien, el porqué react es en general mejor es debido a que:

- Cordova y similares: Usas el control WebView y cargas todo como si fuera una página web, con un poco de comunicación entre el webview & el host para lo demás.

En donde quizás esto tiene mucho sentido es cuando queremos empaquetar un sitio existente y darle un toque de acceso al móvil, pero la app es definitivamente un sitio web "local".

- React & NativeScript: Solo usas el runtime de JS y los controles y clases son los NATIVOS de la plataforma. React también es una librería de hacer UI de forma declarativa, y se puede compartir una buena parte entre servidor/cliente.

Aquí estamos usando Javascript como un lenguaje de scripting sobre el runtime nativo del host, no usamos HTML, ni CSS, ni el DOM. Si tenemos un "Button" es el del host.

Esto es mejor si queremos que la app desempeñe prácticamente si fuera hecho de forma nativa, acceso casi completo a toda la API del host, etc. Es decir, es como si usaramos Xamarin o Delphi, solo que aqui es con JS.

React ADEMÁS es una excelente librería que resuelve el tema de cómo operar la UI y notificar los cambios (ie: data binding). Piensen que es como los controles RAD de Delphi, pero sobre una MUCHO MEJOR base lógica.

P.D: React es también usado en el servidor y para hacer páginas web, tanto directamente en el cliente, como compilado en el servidor. Se puede usar agregado al HTML/CSS o de forma totalmente independiente.

Ciertamente, no he probado "React-Native", aunque, recuerdo haber leído al respecto. El "framework" "React" sí que lo he probado, he leído su documentación, y, en efecto, podría ser un candidato para implementar en nuestras aplicaciones el "Two-Way-Data-Binding" mencionado arriba.

En efecto, no sólo existe Apache Cordova, ni tan siquiera "React-Native", también hay otras herramientas similares, por ejemplo, las que tratan (como Apache Cordova) de utilizar el "WebBrowser" las diferentes plataformas añadiéndole algunos "componentes nativos" accesibles vía Javascript. Digamos, no obstante, que Apache Cordova está en desarrollo constante desde hace más de cuatro años... hasta donde yo llego.

No estoy muy seguro de si "React-Native" trabaja de este modo, pero, según entiendo de tu mensaje no se basa en los "WebBrowser", sino en otras cosas. Está bien, Mario, no hay ningún problema, seguramente "React-Native" puede ser también una buena herramienta para según qué aplicaciones.

Sin embargo, creo que hay algún que otro punto que puede al menos debatirse. Ciertamente, "React-Native" te liga a un "framework" Javascript determinado, como es "React". Apache Cordova, en este aspecto, no sólo no te liga a ningún "framework", pero, tu aplicación podría ser la siguiente después de escribirlo en el bloc de notas que mejor te parezca:

Código PHP:


			
<!DOCTYPE html>
<html lang="en" dir="ltr">
 <head>   
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Mi app</title>
 </head>
 <body>
  ¡Hola mundo!
 </body>
</html>

Por eso también, precisamente, una aplicación HTML, Javascript y CSS, aunque use partes de Apache Cordova, siempre funcionará en cualquier navegador. Por supuesto, no podrá contar con lo que Apache Cordova le proporciona, pero, podrá seguir contando con todo lo demás, cosa que, si desarrollamos en "puro nativo", no vamos a poder hacer.

A lo mejor me equivoco y una de las plataformas de "React-Native", como también ocurre en Apache Cordova, es, precisamente, la plataforma "Browser", es decir, de manera que algunos de los plugins de Apache Cordova estén disponibles también en los navegadores. Como digo, no sé si esto es posible utilizando "React-Native".

Sin embargo, aunque la plataforma "Browser" no estuviese disponible en Apache Cordova (que lo está), lo cierto es que, poniendo por ejemplo la aplicación en que estoy ahora trabajando, de las más o menos 20 vistas conque cuenta, en sólo tres de ellas es necesario el uso de cierto plugin para Apache Cordova: el plugin Camera.

En realidad, si quisiéramos, podríamos preparar lo necesario para que, en dicha aplicación, se utilizase un posible sustituto al plugin Camera de Apache Cordova: de hecho estaba ya implementado así, utilizando controles HTML "input file". Esto, insisto, al menos ha de considerarse: nuestras aplicaciones correrán también en cualquier navegador en cualquier dispositivo.

A la hora del desarrollo también nos viene muy bien que nuestra aplicación pueda correr en cualquier navegador. En el caso de la aplicación en que trabajo y del programa con el que lo hago, probar una aplicación en Android puede llevarme menos de 20 segundos con mi teléfono conectado al PC, pero, probarla en el navegador me lleva aún menos tiempo: esto mismo, el tiempo de "compilación y prueba" se agradece mucho en Delphi también. "Compilamos" muchas veces al cabo del día...

¿Posibles desventajas del desarrollo "web"? Pues que acaso los controles no luzcan como los nativos. Afortunadamente, con "frameworks" como "Bootstrap CSS" (nótese que es el único que he recomendado aquí), esto no parece un mayor problema: nuestras aplicaciones pueden lucir realmente bonitas y aún espectaculares: dependerá de nosotros mismos, del estilo de nuestra app, de las imágenes utilizadas, etc.

A más a más, de entre los cientos de temas que hay para "Bootstrap CSS", seguramente existirá alguno que "imite" los controles nativos de esta o aquella plataforma. Cambiar de tema, si es que se precisa, es cuestión de enlazar con este o con aquél archivo CSS y tal vez algún otro Javascript. Pero, sinceramente, lo digo de verdad de forma sincera, yo no me preocuparía por la comparación con los controles nativos en este aspecto.

Otra cosa que quiero añadir, para ir terminando, es que, en mi opinión, Mario, has mencionado de una forma un tanto "despectiva" (pero sin malos rollos) a las aplicaciones HTML "que corren en local". No sé si conocerás el cliente de correo web de Google, GMail, que, podría perfectamente correr en local. Personalmente, llevo usando GMail desde hace años... con estupendos resultados, hasta el punto de que no uso ningún otro cliente de correo desde que lo conocí. ¿Cómo te quedas?

Uno de los puntos que mencioné arriba trata del hecho de que las aplicaciones HTML, CSS, Javascript (cada vez más, y, hoy día con cosas como Apache Cordova o similares herramientas, siempre que no rompan la "compatibilidad web", como tal vez sea el caso de "React-Native"), digo, que estas aplicaciones, están lejos de ser "simples" o "meros juguetes". Antes al contrario, se ven aplicaciones, juegos, "sitios web", en definitiva, la mar de útiles y para nada "simples".

No voy a comparar la aplicación en la que trabajo con GMail (aunque cumple su cometido perfectamente), empero, como dije en mi primer mensaje, esta aplicación permite el acceso a documentos privados para cada usuario, publicar artículos en un mercadillo, y, al modo de Wallapop, el contacto entre compradores y vendedores. La aplicación implementa varios tipos de "avisos" en forma de notificaciones "push" (que te llegan a tu dispositivo casi en tiempo real), noticias de la empresa a sus trabajodes, el acceso a programas, cursos, y, en definitiva, un montón de cosas útiles que esperamos satisfagan a sus usuarios.

Para terminar sólo diré que yo no soy ningún máster del universo, quiere decirse, que, con el debido conocimiento y el trabajo que sea menester, las aplicaciones HTML, CSS y Javascript pueden resultar muy, muy potentes. No olvidemos una cosa que tal vez los desarrolladores Delphi pasamos por alto al enfocarnos en el "local" que significa Microsoft Windows y la posibilidad de acceso al sistema de archivos, etc.: en las aplicaciones HTML, Javascript y CSS podemos tener a nuestra disposición uno o más servidores detrás para ofrecernos todo tipo de datos e información con la que trabajar.

¡Y eso es todo de momento! ¡Siento haberme enrrollado tanto!

P.D. Estoy seguro de que "React-Native" tiene también no pocas ventajas, pero, como no lo conozco, no las he mencionado.

P.D.2. Se me ha olvidado comentar acerca de Javascript vs Dart vs TypeScript vs [Ponga aquí lo que quiera]. En realidad nadie te impide usar estos lenguajes, que, al cabo pueden y aún deben "compilarse" a Javascript. Personalmente, no sé porqué, llámame estúpido, porque, seguramente no es otra cosa, prefiero el Javascript "puro"... pero, como digo, Apache Cordova no te impide usar estos lenguajes si luego los compilas al Javascript que al final se termine usando.

mamcx · #2 22-06-2017

Cita:

Empezado por dec

Otra cosa que quiero añadir, para ir terminando, es que, en mi opinión, Mario, has mencionado de una forma un tanto "despectiva" (pero sin malos rollos) a las aplicaciones HTML "que corren en local". No sé si conocerás el cliente de correo web de Google, GMail, que, podría perfectamente correr en local. Personalmente, llevo usando GMail desde hace años... con estupendos resultados, hasta el punto de que no uso ningún otro cliente de correo desde que lo conocí. ¿Cómo te quedas?

Precisamente, el chiste de Cordova es tener la pagina web corriendo en local, con un toque de acceso a la API nativa (y tener icono de la "app" separada sin ir al navegador).

Pero si estamos hablando de hacer apps *moviles" es claro que no es la opcion ideal. Es lo mismo que decir: Usemos Cordova para hacer una app windows. Quedaria claro que no es lo mismo que usar los controles/api de windows, cierto?

P.D: Aunque no usaria Google Mail como un ejemplo, ya que aunque es funcional, es claramente inferior a otros clientes de correo (osea, en cuanto a UI/funcionalidad de cliente, no almacenamiento/anti-spam), al grado que Google compro Sparrow (el cual fue el mejor cliente para OSX que habia) porque era muy bueno, y asi no tienen una competencia mas

roman · #3 22-06-2017

Cita:

Empezado por dec

Bueno, pero, también para eso estamos aquí, ¡para discutir!

Desde luego. De hecho, mi comentario a Mario fue una invitación a ello

.

Cita:

Empezado por mamcx

Pero si estamos hablando de hacer apps *moviles" es claro que no es la opcion ideal. Es lo mismo que decir: Usemos Cordova para hacer una app windows. Quedaria claro que no es lo mismo que usar los controles/api de windows, cierto?

Es que no entiendo esta afirmación. ¿Por qué es claro? Actualmente hay muchas aplicaciones que se ejecutan en un navegador y ya no se ve como algo "extraño". Pasándonos a un dispositivo móvil, no me queda nada claro porqué no sería la opción ideal. Y no digo que estés falto de razón. Es sólo que no me parece que sea tan obvio.

LineComment Saludos

mamcx · #4 22-06-2017

Cita:

Empezado por roman

Pasándonos a un dispositivo móvil, no me queda nada claro porqué no sería la opción ideal. Y no digo que estés falto de razón. Es sólo que no me parece que sea tan obvio.

Porque los controles nativos son:

1- Mucho mas rapidos
2- Consumen menos memoria, CPU y aun mas importante, menos bateria
3- No son controles web. Web es prácticamente otro OS con sus propias características y hay que hacer gimnasia para intentar hacer que una app web parezca una nativa.

Es muy notable cuando se compara una app nativa a una web que pretende serlo. Incluso en Desktop, las apps "web" mas notables (como Slack y otras hechas con Electron que es como cordova) son in-famosas por su excesivo consumo de recursos, lentitud y fallos en general.

Y a la larga, puede resultar mas costoso desarrollar no-nativo que nativo. Algo que por ejemplo experimento facebook, que termino cambiando de web -> nativo luego de creer que era buena idea; y de hecho, es la razon por la que termino haciendo React Native, como un punto intermedio entre ambos. Porque la REALIDAD del mercado, es que las tecnologias web permiten contratar MAS BARATO y a programadores MENOS EXPERIMENTADOS que nativo.

Ahora, de todas maneras estoy hablando de hacer apps, no de tener una pagina encapsulada, que es un caso de uso diferente. Hay apps donde tener la misma UI tiene sentido, y no hay intencion de ser ni parecer una app nativa, que es donde la falla se hace mas notable.

P.D: Quiero acotar que mi punto de vista es mas en termnos generales, que refutar que a roman o cualquier otro vean que les sirve su elección; que al final es mas significativa que la opinion de un tercero que no conoce tus circunstacias especificas.

Básicamente solo quera agregar que React Native es otra opción muy buena al arsenal, pero como cosa rara termine yendome por las ramas!

dec · #5 22-06-2017

¡Hola a todos!

Cita:

Empezado por mamcx

Porque los controles nativos son:

1- Mucho mas rapidos
2- Consumen menos memoria, CPU y aun mas importante, menos bateria
3- No son controles web. Web es prácticamente otro OS con sus propias características y hay que hacer gimnasia para intentar hacer que una app web parezca una nativa.

¡Contestaré sólo a estos puntos porque tengo caliente la cena! Habrá que definir "mucho más rápido" Mario. Hace años, tal vez, con ordenadores menos potentes... pero hoy día no es raro encontrar teléfonos con más de 2GB de RAM... y que además tienen sus "WebBrowsers" muy optimizados, ofreciendo respuestas verdaderamente sorprendentes, en algunos casos, equiparables a "lo nativo", porque, en efecto, si lo nativo tiene que comunicar con un servidor para traer datos... ya no estará sólo ante el peligro y tardará en mostrar los datos contando con lo que tarde el servidor en enviarlos.

¿Consumen las aplicaciones "no nativas" menos recursos? Es posible, pero, volvemos a lo mismo, vamos a poner esto en perspectiva. Cada vez los dispositivos son más potentes, más optimizados, en fin, esto es (más o menos) como cuando pretendíamos que nuestros programas en Delphi ocuparan lo menos posible, ¿os acordáis? ¿Quién comprime hoy sus programas con UPX para ahorra espacio? ¿A quién le preocupa si su programa ocupa 1 ó 20 MB hoy en día? No es lo normal, puesto que hoy día 20 MB son... menos que 1 MB antaño. ¡Y esto no se va a quedar parado aquí!

Por otro lado, creo que hay cierta insistencia en que las aplicaciones luzcan "nativas". Volviendo al ejemplo de GMail, ¿se parece GMail a una aplicación de Windows? ¿De Mac OS? ¿Tiene GMail alguna necesidad, para ser atractivo y útil, de parecerse a ninguna otra cosa? Lo que tiene que tener GMail, y por supuesto tiene, son "tablas" para mostrar información, "casillas" para introducir datos, "botones" para pulsarlos (claro está) y así sucesivamente. De hecho, GMail tiene una ventaja, desde mi punto de vista: será el mismo en todas y cada una de las plataformas, no se parecerá a nada, y siempre usarás el mismo GMail estés donde estés.

A mí esto no me parece mal...

dec · #6 23-06-2017

¡Hola a todos!

¡Vamos a seguir con tu última respuesta Mario!

Cita:

Empezado por mamcx

Es muy notable cuando se compara una app nativa a una web que pretende serlo. Incluso en Desktop, las apps "web" mas notables (como Slack y otras hechas con Electron que es como cordova) son in-famosas por su excesivo consumo de recursos, lentitud y fallos en general.

Yo creo que, para empezar, una aplicación no tiene que pretender nada más que resultar de utilidad. No se trata de "querer ser nativa", sino de ofrecer algo útil. A veces, en efecto, por varias razones que podrán ser más o menos discutidas, el desarrollo nativo acaso sea la mejor opción. Pero, sin despreciar otras posibilidades tampoco, sin cerrarnos en banda, vamos.

Cita:

Empezado por mamcx

Y a la larga, puede resultar mas costoso desarrollar no-nativo que nativo. Algo que por ejemplo experimento facebook, que termino cambiando de web -> nativo luego de creer que era buena idea; y de hecho, es la razon por la que termino haciendo React Native, como un punto intermedio entre ambos. Porque la REALIDAD del mercado, es que las tecnologias web permiten contratar MAS BARATO y a programadores MENOS EXPERIMENTADOS que nativo.

Una persona que domine HTML, Javascript y CSS (y algún otro lenguaje y base de datos en el servidor) puede ponerse a construir una aplicación web. Dicha aplicación podría correr en Android, iOS, Windows y en otras plataformas soportadas por Apache Cordova (si seguimos hablando del mismo), por no mencionar la plataforma principal: cualquier navegador en cualquier dispositivo.

Yo creo que el perfil de la persona que refiero arriba está mucho más cercano a la realidad de una posible persona que dominase el desarrollo nativo en Android, iOS, Windows, otras posibles plataformas y además en cualquier navegador en cualquier dispositivo. ¿No te parece a ti que de lo que se trata de buscar una "plataforma universal", mejor que diferentes personas para diferentes plataformas?

¿Qué desarrollo será más económico? ¿Aquél que necesite una persona o el que necesite dos, tres o cuatro? ¿Por qué tiene que ser necesariamente más barato un desarrollador HTML, Javascript y CSS? ¡Eso serán los malos, digo yo! Que un programador sea malo o bueno no creo yo que tenga que ver en absoluto con el lenguaje o entornos que esté utilizando.

Cita:

Empezado por mamcx

Ahora, de todas maneras estoy hablando de hacer apps, no de tener una pagina encapsulada, que es un caso de uso diferente. Hay apps donde tener la misma UI tiene sentido, y no hay intencion de ser ni parecer una app nativa, que es donde la falla se hace mas notable.

Yo también hablo de verdaderas aplicaciones y no de meros documentos HTML. Y has dado en el clavo: personamente, en lugar de adaptar una aplicación para cada plataforma... prefiero que la misma aplicación (si es posible) se ejecute y luzca más o menos igual (y eso hoy día es posible gracias a que las plataformas soportan cada vez mejor HTML, CSS, etc.) en cualquier lugar.

Cita:

Empezado por mamcx

P.D: Quiero acotar que mi punto de vista es mas en termnos generales, que refutar que a roman o cualquier otro vean que les sirve su elección; que al final es mas significativa que la opinion de un tercero que no conoce tus circunstacias especificas.

Básicamente solo quera agregar que React Native es otra opción muy buena al arsenal, pero como cosa rara termine yendome por las ramas!

¡Si es estupendo! En efecto, aquí nadie vamos a poder sentar cátedra de una vez por todas. De hecho estaríamos equivocados, porque, ¡cada aplicación es un mundo! Vale... quizás no tanto, pero, la idea es que aquí lo importante es la aplicación, qué se necesita, y, en función de eso, utilizar la herramienta que nos parezca más adecuada en función de nuestros conocimientos y experiencia.

¡Claro que "React-Native" puede estar bien! A veces será preferible a Apache Cordova... o viceversa... todo dependerá de lo que vayamos a hacer.

pacopenin · #7 23-06-2017

Buenas. Muy buen hilo. Me interesa mucho este debate, aunque no tengo argumentos para comentar, al menos de momento, pero estaré pendiente de lo que vayais contando.

dec · #8 24-06-2017

¡Hola a todos!

Cita:

Empezado por pacopenin

Buenas. Muy buen hilo. Me interesa mucho este debate, aunque no tengo argumentos para comentar, al menos de momento, pero estaré pendiente de lo que vayais contando.

¡Gracias Paco!

dec · #9 22-06-2017

¡Hola a todos!

Cita:

Empezado por mamcx

Precisamente, el chiste de Cordova es tener la pagina web corriendo en local, con un toque de acceso a la API nativa (y tener icono de la "app" separada sin ir al navegador).

Pero si estamos hablando de hacer apps *moviles" es claro que no es la opcion ideal. Es lo mismo que decir: Usemos Cordova para hacer una app windows. Quedaria claro que no es lo mismo que usar los controles/api de windows, cierto?

P.D: Aunque no usaria Google Mail como un ejemplo, ya que aunque es funcional, es claramente inferior a otros clientes de correo (osea, en cuanto a UI/funcionalidad de cliente, no almacenamiento/anti-spam), al grado que Google compro Sparrow (el cual fue el mejor cliente para OSX que habia) porque era muy bueno, y asi no tienen una competencia mas

Discrepo contigo Mario. Sé por dónde vas, y, en efecto, nadie va a negar que el desarrollo nativo tiene sus ventajas, por ejemplo, acaso un mayor desempeño en cuanto a la rapidez y agilidad de las aplicaciones, pero, ¡qué duda cabe de que el desarrollo nativo también tiene sus desventajas!

Una aplicación "web" con un icono en el escritorio del dispositivo vendría a ser lo que Google inventó con las "Progressive Web Applications", empero, una aplicación que se apoya en Apache Cordova puede ir bastante más allá que eso, recordemos, por ejemplo, que podríamos crear plugins (escritos en Java) para cuanto fuese menester.

Por otro lado, quiero hacer notar que la idea de estos hilos míos va más bien por pensar en HTML, Javascript y CSS, lo que ya hoy día es posible hacer con Javascript, y, más particularmente, lo que pueda llegar a hacerse en el futuro con Javascript. Apache Cordova, como dices, es un añadido, pero, yo tengo mucha confianza en las aplicaciones HTML.

Ahora bien, ¡no vayamos a intentar atornillar con un martillo! Si mañana me dices, necesito hacer un programa para Windows, problamente pensaría en Delphi. Seguramente no pensaría en otra cosa que en Delphi. Pero si me hablas de Android, ya no lo tengo tan claro, precisamente, porque, con HTML, Javascript y CSS, ojo a esto, POR EL MISMO PRECIO y con la misma base de código, podemos atacar varias plataformas más.

¿Quiero esto decir que ya sólo pensaré en términos de HTML, Javascript y CSS? No, por supuesto que no. Pero sí que quiero transmitir la idea de que estos lenguajes son cada vez más potentes, y, que, ya no hablamos de una, dos o tres plataformas, no... hablamos de poder llegar a esas dos o tres plataformas en que todos pensamos (sí, también Windows y su Windows Store) y además CUALQUIER navegador disponible en cualquier dispositivo.

Para mí eso tiene ventajas indudables. ¿Superan las ventajas a los incovenientes? ¿Sería mejor usar algo nativo? Dependerá de cada caso, ¡digo yo!

Cita:

Empezado por roman

Desde luego. De hecho, mi comentario a Mario fue una invitación a ello

.

Es que no entiendo esta afirmación. ¿Por qué es claro? Actualmente hay muchas aplicaciones que se ejecutan en un navegador y ya no se ve como algo "extraño". Pasándonos a un dispositivo móvil, no me queda nada claro porqué no sería la opción ideal. Y no digo que estés falto de razón. Es sólo que no me parece que sea tan obvio.

LineComment Saludos

Estoy contigo, Román, de forma completamente honesta además. Tal vez hace años la web se limitaba a mostrar información, pero, eso cada día es menos así. Cada día hay más "aplicaciones web", algunas lo son inlcluso sin saberlo, y, claro está que habrá sitios web que no necesiten más. Pues muy bien. Pero estoy contigo, en el mismo sentido: yo no veo nada claro que lo "no nativo" (estaría mejor decir lo "universal"... o "multiplataforma"...) tenga nada de malo, todo lo contrario.

Posiblemente un cliente de correo escrito en Delphi o cualquier otro entorno nativo para Windows sea más rápido que GMail... si es que guarda los mensajes en una base de datos local, pues, de lo contrario, habrá de contactar igualmente con un servidor. Pero lo que tengo claro es que no tiene porqué ser ni más bonito, ni más usable, ni mejor. Yo no uso GMail no porque reniege de lo nativo, vaya, sino porque con GMail tengo más que suficiente... e incluso mucho más de lo que utilizo.

Temas Similares
Tema	Autor	Foro	Respuestas	Último mensaje
Solicito orientación sobre un desarrollo para GPS.	TiammatMX	OOP	6	28-03-2014 15:37:29
Sobre .NET en multiplataforma	SMTZ	Noticias	2	16-09-2006 17:58:14
Compiladores y Entornos de desarrollo multiplataforma	Crandel	Debates	9	16-08-2005 18:29:18
Desarrollo de webservice para apache	padillarj	Internet	0	14-08-2005 08:24:05
Crear un componente multiplataforma para conectar un BD	RONPABLO	OOP	0	10-02-2005 20:25:49