Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Eclipseme Contra Netbeans Mobility Pack

Iniciado por sés, 06 de Septiembre de 2005, 09:41:17 AM

« anterior - próximo »

sés

 Solo quería decir que he estado probando un poco EclipseME y... bueno.
Por lo poco que he visto, si creo un proyecto J2ME en Eclipse, puedo generar un JAR. La pregunta es: ¿solo uno?

¿Alguien que lo conozca puede aclararme esto?

Si es así, supongo que la única solución es usar Ant+Antenna. Lo que quiere decir que Netbeans me parece infinitamente mejor para J2ME.
Soy indeciso... ¿o no?

erchus

 Saludos Sés:

Yo he usado de forma bastante básica el EclipseME, pero no se si entiendo bien tu pregunta:
¿A qué te refieres exactamente con que solo permite general un jar? O_O

Por cierto, ya que el Netbeans Mobility Pack está tan bien...¿podrías pasarme algún enlace para descargarlo? (ole)

Ta luegor  (twist)  

sés

 Me refiero a que creas un proyecto, le das a "build" (o como se llame) y compila y genera UN JAR.
¿Hay posibilidad de crear varios o hay que crear diferentes proyectos?

Aquí tienes unos enlaces de NetBeans:
NetBeans
NetBeans 5.0 Release Info

En este último enlace tienes a la derecha "Download development build". Ahí selecciona Q-Build y el SO que quieras. Bájate los dos primeros enlaces (23 August), que son NetBeans y su correspondiente Mobility Pack.

Información sobre lo nuevo de esta versión del Mobility Pack aquí.
Soy indeciso... ¿o no?

erchus

 Ya se a qué te refieres y por lo que yo conozco, para obtener distintos jar tienes que crear distintos proyectos.

Gracias por los enlaces, la verdad es que el NetBeans tiene buena pinta.

Lo utilizaré en cuanto pueda y ya te contaré.

Salu2

zupervaca

 yo desde que dijiste que netbeans esta muy bien para programar en moviles me lo he descargado y hechado un vistazo, pero por lo que veo realmente no te solucionan el problema de asegurarte que funcionara en los moviles ya que por ejemplo para el nokia 3650 que tengo aqui poniendo midp 1.0 y clcd 1.0 he compilado un ejemplo que trae y se me cierra la app y desde el emulador va de perlas, me parece que sigo prefiriendo el block de notas :lol:

saludos

Zaelsius

 Pues yo me c*** en Sun y en su política de ignorar Mac OS X como sistema de desarrollo. Sólo sacan paquetes para Windows y Linux. Lo mismo para el Mobility Pack de NetBeans <_< .

Tendré que seguir con Xcode + MPP + Antenna

sés

 Es que NetBeans no hace magia ^_^

Te da lo necesario para que TÚ puedas hacer que funcione en diferentes móviles. NetBeans no hace nada porque tú digas MIDP-1.0 en vez de MIDP-2.0.

Lo que sí que tiene es la posiblidad de definir varias configuraciones (cada una genera un JAR), donde puedes definir TODAS las propiedades de cada de cada JAR (JDK, fuentes y recursos a utilizar...) y preprocesador. Cualquiera que haya programado en C sabe lo que eso significa.

Ais... tanto huir del preprocesado...
Siempre ha sido útil y siempre lo será. No sé a qué esa manía de olvidar todo lo bueno que tenía C. Al final han tenido que implementarlo.
Soy indeciso... ¿o no?

TheAzazel

 Ses, muchisimas gracias por esos enlaces y toda la info, la verdad es que me pica mucho la curiosidad....
esto...y la base grafica, me refiero a GetPixel() y demas.... te lo ofrece Java o hay una minilib para los moviles??

PD: quien dice grafica...dice sonido, teclas, etc.. todo el bajo nivel vamos

zupervaca

 
CitarEs que NetBeans no hace magia ^_^
hace todo lo contrario ya que desde el block de notas hago apps que funcionan correctamente desde el nokia 3650 con el ktoolbar y con el netbeans sus propios ejemplos fallan

CitarLo que sí que tiene es la posiblidad de definir varias configuraciones (cada una genera un JAR), donde puedes definir TODAS las propiedades de cada de cada JAR (JDK, fuentes y recursos a utilizar...) y preprocesador. Cualquiera que haya programado en C sabe lo que eso significa.
yo estoy acostumbrado a usar el preprocesador para compilar directx u opengl para windows y linux y no se que tiene que ver para compilar con midp 1.0 si es un standard para todos los moviles que usan java, si usara cosas de midp 2.0 que no rualran en el midp 1.0 todavia, pero es que son ejemplos del propio netbeans con el midp 1.0

la verdad es que me ha decepcionado mucho el netbeans, no logro entender como es que sigue siendo mejor usar el block de notas y el ktoolbar para compilar para midp 1.0

saludos

pd: ses no estoy no estoy criticando lo que has puesto, tus frases las pongo por que apartir de ellas puedo aclarar mejor mis opiniones sobre el netbeans

editado: con esto podemos solucionar todos los problemas de compatibilidad http://www.j2mepolish.org/

sés

 El preprocesador su utiliza (igual que en C), para compilar ciertas partes según unos parámetros. Así, si es MIDP-1.0, puedes compialr un código y si es MIDP-2.0, otro distinto. Pero eso es algo que haces tú, no el NetBeans.

Y que los ejemplo de "una beta" no funcionen en un determinado móvil no veo importancia puede tener.

Otra cosa que tienes que tener en cuenta es que los Reyes Magos no existen.. .digo... ^_^ Que eso de "estándar MIDP 1.0" suena muy bonito, pero no es cierto. Hay cosas que, por muy estándar que sean, no te van a funcionar en algunos móviles.

¿Y qué tiene de bueno el NetBeans?

Prueba a hacer un juego normalito, que funcione en todos los móviles y que aproveche sus características.

Haz un .java para pantallas pequeñas, otro para pantallas medianas, otro para pantallas grandes... y cada uno de esos para MIDP-1.0, MIDP-2.0... ¿y qué tal una versión para i-mode? lo que ya hacen 12 códigos diferentes. Multiplica por las clases adicionales que uses y que puedan cambiar. Luego compila y empaqueta cada uno con sus recursos (con gráficos grandes, pequeños, medianos... unos con sonido, otros sin sonido, unos con midi, otros con mp3, otros con wav....). Y no olvides los iconos (12x12, 24x24...).

¡Uy!, se me olvidaba que algunos usan JDKs propias... adiós el "estándar". Usas su JDK para sonido y demás u olvídate.

...y ese modelo que anda escaso de memoria... y ese otro que no tiene softkeys... y ese que tiene el fallo X y tienes que hacer nosequé para que funcione una tontería...

:lol: Bienvenido al "maravilloso" mundo de los móviles.

Esto lo resuelves con NetBeans con diferentes configuraciones y unas instrucciones de preprocesador. Ahora dime cómo lo resuelves con el Bloc de Notas :P
Soy indeciso... ¿o no?

zupervaca

 
CitarEl preprocesador su utiliza (igual que en C), para compilar ciertas partes según unos parámetros. Así, si es MIDP-1.0, puedes compialr un código y si es MIDP-2.0, otro distinto. Pero eso es algo que haces tú, no el NetBeans
ya lo se, pero te estoy diciendo que si el codigo solo es midp 1.0 no hace falta

la mejor solucion que veo por el momento es el polish que tiene una base de datos con casi todos los moviles (segun ellos unos 300 y se puede ampliar) y diciendole para que lo quieres compilar ya se ruca el para que funcione

he estado mirando paginas web de juegos para moviles y hay muy pocos ya para el nokia 3650, ¿cuantos moviles usan aun el midp 1.0? por que no se que me da que le quedan dos dias

sés

Cita de: "zupervaca"con esto podemos solucionar todos los problemas de compatibilidad http://www.j2mepolish.org/
Ya lo estuve mirando, pero más que facilitar las cosas me da la impresión de que las complica. En el sentido de que  tienes que hacer las cosas como el te dice.

Los recursos, por ejemplo, me parece un asco como lo organiza.
Según su bonita base de datos, tienes que meter los recursos para pantallas de 176x208 en resources/ScreenSize.176x208.
¿Y qué pasa con los de 176x220? O sea, que si tengo un móvil que tiene un pixel más por algún sitio, me obliga a copiarme todos los recursos en otro directorio, o no me los coge.

De verdad, no creo que valga la pena el tener tantas separaciones pro modelos y tanto tocar en XMLs.

En NetBeans, si quiero un modelo (o grupo de modelo similares), creo una configuración del tipo: MIDP2_176x200 (tamaño informativo, sirve para todos los similares).
* Le digo que recursos quiero:
- res/sounds
- res/spr176
* Le digo la JDK: WTK 2.2 (opr ejemplo)

Y poco más.

Con tener unos "defines" en cada configuración que indican sus características, yastá. Solo he tenido que pinchar unos botones.

Ya te digo, J2ME Polish me parecía muy bonito hasta que intenté usarlo para compilar las versiones que necesitamos y vi que perdía mucho tiempo en instalar lo que pide, leerse la documentación, organizarlo en SUS directorios, etc.
Al final me hice 3 ó 4 proyectos con JBuilder y obtuve las versiones que viene en la página de Movilenio.
Soy indeciso... ¿o no?

sés

 
Citarya lo se, pero te estoy diciendo que si el codigo solo es midp 1.0 no hace falta
Como te he dicho: olvídate de eso de que es un estándar.
Por muy MIDP-1.0 que sea, vas a tener diferencias en un modelo a otro.

Citar¿cuantos moviles usan aun el midp 1.0? por que no se que me da que le quedan dos dias
Y te sorprenderías de la cantidad de móviles con MIDP-1.0 que quedan :P
Soy indeciso... ¿o no?

zupervaca

 no entiendo el por que se dice que el midp 1.0 no es tan estandar, el juego que hice yo para moviles hace ya un par de años funciono en todos los moviles que se probo y eran de diferentes marcas y modelos, aun tengo amigos que lo descargan a sus nuevos moviles y dicen que les va de maravilla

si una resolucion es de 176x208 y otra es de 176x220 veo muy importante que sean recursos diferentes ya que por ejemplo en el ultimo juego que has hecho que el fondo es una imagen que no debe de estirarse ni adaptarse de ningun modo no valdria para los dos y se tendria que decir al grafista que le toca currar en esos dos modos, ya lo se, todos sabemos que el grafista se va a hechar las manos a la cabeza, pero por suerte en los moviles hay juegos que se pueden hacer sin grafistas (twist)

saludos

sés

 
Cita de: "zupervaca"no entiendo el por que se dice que el midp 1.0 no es tan estandar...
Si es un juego sencillo, no habrá mayores problemas, pero en cuanto hagas cosas más complejas verás cómo te llevas palos por confiar en ese "estándar". Por ejemplo: Excepción porque en cierto terminal tienes un tamaño máx. de imagen (o ancho máximo...), métodos que no devuelven lo que deberían o no los tienen implementados...

Cita de: "zupervaca"si una resolucion es de 176x208 y otra es de 176x220 veo muy importante que sean recursos diferentes ya que por ejemplo en el ultimo juego que has hecho que el fondo es una imagen que no debe de estirarse ni adaptarse de ningun modo no valdria para los dos
^_^ Me gustaría ver cómo se lo dices a un dibujante. ¿Y para 176x196 hace otra versión?
En mi juego sirven los mismo gráficos para esas versiones.

Cita de: "zupervaca"por suerte en los moviles hay juegos que se pueden hacer sin grafistas
Eso solo sirve si:
- no piensas venderlo (o venderlo mucho).
- es realmente sencillo.
Soy indeciso... ¿o no?






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.