loretoparisi

Members
  • Content Count

    31
  • Joined

  • Last visited

About loretoparisi

  • Rank
    HIC Developer

core_pfieldgroups_99

Contact Methods

  • Website URL
    http://loretoparisi.splinder.com
  1. Sono trascorsi più di due anni dal post NetBeans Mobility Pack 5.0 su MacOS X, relativo all'hack per installare il Mobility Pack per J2ME su NetBeans 5.0, eppure ancora oggi la Sun si ostina a non dare supporto alla piattaforma J2ME su MacOS X, nonostante non ci sia più il problema del Big Endian, essendo passati nel frattempo ai MacIntel. Potendo dunque ricompilare il Sun Wireless Toolkit per Linux per MacOS X, non capisco ancora perché l'ultimo super accessoriato NetBeans 6.1, non integri un Mobility Pack su MacOS X. Perciò siamo alle solite, e vediamo un altro hack, per mettere in funzione JavaME su Mac. Le risorse sono sempre le stesse IDE - NetBeans 6.1 MacOS X e OS Indipendent Zip: http://download.netbeans.org/netbeans/6.1/final/ Wireless Toolkit - MPP SDK: http://mpowerplayer.com/?cat=6 1. Scaricate e installate NetBeans 6.1 - MacOS X, final release in /Applications/NetBeans, scegliendo la versione minimale (verrà sovrascritta in seguito); 2. Scaricate e decomprimete NetBeans 6.1 - OS Indipendent Zip in $HOME/netbeans. Scegliete All, in modo da avere tutti i NetBeans Packs , o quanto meno Mobile; 3. Scaricate e decomprimete l'MPP SDK in $HOME/mpp-sdk; 4. A questo punto, sostituiamo la cartella: /Applications/NetBeans/NetBeans 6.1.app/Contents/Resources/NetBeans con la cartella $HOME/netbeans ovvero con quella dell'OS Indipendent Zip: cd /Applications/NetBeans/NetBeans 6.1.app/Contents/Resources/ sudo rm -rf NetBeans/ sudo cp -r /$HOME/netbeans /Applications/NetBeans/NetBeans 6.1.app/Contents/Resources/ oppure semplicemente fate Drag and Drop dal Finder e poi rinominate netbeans in NetBeans. Secondo quanto indicato da Lukas Hasik, questo passaggio non sarebbe necessario. Tuttavia dopo diversi tentativi non sono riuscito ad installare alcun Mobility Pack da Plugin Manager di NetBeans 6.1, invero seguendo questa procedura avrete l'IDE con il mobility8 installato. 5. Lanciate NetBeans, in Tools/Java Platforms scegliete Add Platform... selezionando quindi JavaME MIDP Platform Emulator . Scegliete come cartella quella dell'MPP SDK, $HOME/mpp-sdk. Come potrete osservare NetBeans, ora riconosce correttamente l'MPowerPlayer SDK e i relativi device (ed era ora!!!). 6. Create un nuovo progetto Mobile>MIDP Application, scegliendo come piattaforma SDK MPowerPlayer. Scegliete quindi MIDP e CLDC (questa volta CLDC 1.1 viene riconosciuto correttamente). 7. Se tutto è andato a buon fine, lanciando Run sul nuovo progetto, l'mpowerplayer verrà eseguito mostrando la MIDlet di test. L'alternativa a tale ambiente di sviluppo su MacOS X, è utlizzare Eclipse, EclipseME e sempre l'MPP SDK. Anche in questo caso, l'ultima release di EclipseME la 1.7.9 supporta MPowerPlayer, ed è di facile installazione su Eclipse 3.3.2. Da notare che a proposito di Eclipse, EclipseME è stato da poco integrato nel progetto Eclipse MTJ (Mobile Tools for Java), il chè ci lascia sperare che dia una spinta ulteriore agli emulatori J2ME su MacOS X. LP Links: NetBeans: http://www.netbeans.org/ MPower Player SDK: http://mpowerplayer.com/ Eclipse: http://www.eclipse.org/ EclipseME: http://eclipseme.org/ Mobile Tools for Java (MTJ) Home Page: http://www.eclipse.org/dsdp/mtj/ Lukas Hasik's Weblog: NetBeans Mobility 6.1 on Mac (Leopard) The Java Slug: OS X, J2ME and NetBeans 6.0 Tratto da: Loreto Parisi Home - NetBeans 6.1 e Mobility Pack 8 su MacOS X
  2. Dunque, l'errore è nella preverifica: preverify: [exec] Error preverifying class NomadisWS01_PortType_Stub [exec] java/lang/NoClassDefFoundError: javax/xml/rpc/Stub [exec] Result: 1 ovviamente la classe sotto accusa non viene trovata: run: [java] mpowerplayer 2.0.898 [java] Error while starting midlet: [java] java.lang.NoClassDefFoundError: NomadisWS01_PortType_Stub [java] at NomadisWS01.startApp(NomadisWS01.java:25) [java] at javax.microedition.midlet.MIDlet._startApp(MIDlet.java:84) [java] at com.mpp.adapter.Controller._start(Controller.java:724) [java] at com.mpp.adapter.Controller.access$100(Controller.java:25) [java] at com.mpp.adapter.Controller$3.run(Controller.java:688) [java] at java.lang.Thread.run(Thread.java:552) A quanto vedo si tratta di un pb di libreria o di CLASSPATH, vista l'eccezione NoClassDefFoundError di java.lang. Si tratta della libreria per i Web Services, ma lo stub richiesto non viene trovato. La prima cosa da fare è proprio importare la libreria nel progetto, o aggiungere al CLASSPATH il percorso dove si trova l'archivio j2me-ws.jar. La VM del dispositivo ne permette l'uso solo se i package sono contenuti all'interno dell'ambiente di Run-time del dispositivo. Perciò occorre: 1) importare il file j2me-ws.jar come libreria esterna; 2) Usare poi un offuscatore per eliminare i nomi dei package riservati in java e javax.
  3. Da qualche settimana è disponibile un plugin per XCode 2 per la programmazione su piattaforma Symbian OS in MacOS X. Il plugin Open Source è stato sviluppato da Tom Sutcliffe e consente di: - Importare file MMP nei progetti XCode; - L'edit della configurazione per il build, come in un normale progetto XCode; - Lavorare con più SDK, quali UIQ, Symbian S60, S80; - Costruire file SIS ed inviarli al dispositivo reale Symbian via Bluetooth per la fase di testing. Il plugin include GCC e altri tool specifici in bundle, senza la necessità di ulteriori download. Inoltre il codice sviluppato su PC Windows può essere importato e compilato as it is in XCode. Fonti: [Macity] http://www.macitynet.it/macity/aA24226/index.shtml [symbian.com] http://www.symbian.exvn.com/page.cfm?article=0x81e440c04fd7b04b0c3207d4fe191fc6.6.11659 [Tomsci.com] http://www.tomsci.com/xcodeplugin/ Download: [Tomsci.com] http://www.symbian.com/developer/downloads/files/XcodePluginForSymbianOS.dmg Finalmente, qualcosa si muove sul fronte della programmazione Mobile con MacOS X! LP
  4. Dunque, il file JAD (Java Application Descriptor) è il descrittore dell'applicazione, la MIDlet. E' utilizzato per informare il dispositivo del contenuto del file JAR (Java Archive File). E' inoltre utilizzato per definire i parametri di ambiente della MIDlet (le property), che possono essere letti dalla MIDlet con getAppProperty(propertyName). Ovviamente il file JAR è l'archivio dei file Java compilati, preverificati ed eventualmente offuscati, i file .class, e quindi contiene l'applicazione eseguibile. La classe eseguibile, la MIDlet viene specificata nel file manifesto, in genere manifest.mf. Ecco un esempio di file manifesto: MIDlet-1: HelloWorld, , HelloWorld MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 Created-By: 1.4.0 (Sun Microsystems Inc.) MicroEdition-Profile: MIDP-1.0 MIDlet-Name: HelloWorldApp MIDlet-Vendor: LPCoding Inc. e di file JAD: MIDlet-1: HelloWorld, , HelloWorld MIDlet-Jar-Size: 100 MIDlet-Jar-URL: http://myAppServer.myDomain.org/apps/HelloWorldApp.jar MIDlet-Name: HelloWorldApp MIDlet-Vendor: LPCoding Inc. MIDlet-Version: 1.0 Pertanto è sufficiente inviare il file JAR, ma è preferibile, in particolare nell'ottica di distribuire l'applicazione Over The Air (OTA), inviare il JAD, quindi il dispositivo scaricherà il JAR, dall'URL indicato nella proprietà MIDlet-Jar-URL. LP
  5. A rigor di logica, si tratta del percorso del preverificatore!
  6. Vedo...il codice sembra ok, Quello stesso errore era causato dalla mancanza dei permessi di esecuzione su .../preverify, ma a quanto dici sono ok. Per non arrovellarci il cervello, fai un backup della tua app, quindi elimina il template in XCode, riavvia XCode senza, e poi installa di nuovo il template, e crea un nuovo progetto MIDP, ma non in deploy questa volta. Da qualche parte in XCode (in qualche file XML di conf) qualcosa non va, a meno di configurare propriamente il deploy, credo fai prima a re-installare il tutto.
  7. Ciao, credo si tratti di un pb di path: 'cannot excute' a 'build.xml:41'. In XCode, quando fai il Deploy, devi modifcare opportunamente le impostazioni così come hai fatto per la modalità Development. Hai per caso modificato il file di build? Riporta il listato della linea incriminata...
  8. Installando OS X Developer Tools hai a disposizione gcc 4.0.0, ma puoi optare anche per gcc 3. Le librerie dinamiche richieste le trovi in /usr/lib, gli header in /usr/include, ecc.: /usr/lib/libc.dylib /usr/include/libc.h ... Dunque, perchè tentare di installare da zero gcc, hai forse necessità di customizzare il compilatore? Considera che gcc 4.0.0 è ottimizzato per OS X Tiger dagli ingegneri Apple. LP http://loretoparisi.splinder.com/
  9. se desideri sviluppare con un linguaggio open ci sono mille scelte piu' indicate piuttosto che usare mono > Mono è ad oggi l'unico compilatore C# (perchè è di questo di cui discutiamo!) non microsoft, open source e multipiattaforma esistente! che sara' sempre in rincorsa nei confronti di .net > In parte è vero, sotto XP Mono ha un -20% di prestazioni rispetto a .NET. Del resto era ovvio... e avra' sempre la spada di damocle di qualche brevetto pronto per chiuderlo. > non credo, chiunque (in grado di farlo s'intende) può realizzare un compilatore per un qualsivoglia linguaggio! Poi, liberissimo di farlo, ma non ne capisco l'utilita'. >se devo necessariamente lavorare in C#, preferisco utilizzare sw libero... >Per sviluppare con .NET hai bisogno di Visual Studio, non è vero. > non credo che chi lavora con WinXP e .NET utilizzi il note pad... LP http://loretoparisi.splinder.com
  10. Questa volta sono daccordo! Lavorando su progetti .NET esistenti, Mono è l'unica alternativa al .NET Framework! Per il resto, non mi interessa di rafforzare Microsoft piuttosto che Apple o Sun, quello che interessa è poter sviluppare in piena *libertà *.J2EE o .NET che sia benvengano! LP http://loretoparisi.splinder.com
  11. Semplicemente perchè .NET difatto è una piattaforma *closed* source, mentre Mono è assolutamente *open* Source. Per sviluppare con .NET hai bisogno di Visual Studio, per sviluppare con Mono solo delle tue capacità ! Inoltre, considera che Java 1.5 ha introdotto caratteristiche già presenti in C#, che a sua volta nasce da Java...per chi programma è importante conoscere entrambi i linguaggi, così come è importante poter sviluppare per *tutte* le piattaforme, cercando quando è possibile e laddove si renda necessario, utilizzare le api native. Così un developer Windows potrà sviluppare sistemi .NET like utilizzando MonoDevelop per XP e le relative api Windows, lo sviluppatore OS X potrà poi portare il tutto su OS X, sfruttando Cocoa#, e dunque le api OS X - Aqua. Credo che questo basti! LP http://loretoparisi.splinder.com
  12. Dopo giorni di interminabili compilazioni, configurazioni e 'make', risultanti in eccezioni a catena (principalmente a causa delle infide glib), MonoDevelop è ora in esecuzione su MacOS X 10.4.2! Falliti tutti i tentativi di installare l'IDE di Mono dai sorgenti, sia utilizzando fink che script ad-hoc, essenziali sono risultati i package creati da Andrew Theken in How to Run MonoDevelop on Mac OS X Strike 2, rispettivamente un installer DarwinPorts per le librerie gnome, gtk+, gtk#, glib e relative dipendenze necessarie per l'interfaccia grafica non Aqua-nativa di MonoDevelop, e una versione modifica del Mono.Framework 1.1.8.1 Dunque, una volta installati i packages (in /opt/local/ il primo e in /Library/Frameworks/ il secondo) occorre esportare la variabile d'ambiente DYLD_LIBRARY_PATH necessaria per le librerie dinamiche (aggiungete in $HOME/.bash_profile): >export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH: /opt/local/lib:/Library/Frameworks/Mono.framework/Versions/Current/lib Lanciate dunque il server X11 ed eseguite in xterm Monodevelop >monodevelop Se si vericasse la seguente eccezione Unhandled Exception: System.DllNotFoundException: libgnomeui-2.0.dylib in (wrapper managed-to-native) Gnome.Modules:libgnomeui_module_info_get () in <0x00010> Gnome.Modules:get_UI () in <0x004c8> MonoDevelop.SharpDevelopMain:Main (System.String[] args) reinstallate X11 dal DVD di Tiger e riavviate MonoDevelop. Come verificato, la libreria cercata (libgnomeui-2.0.dylib link simbolico a libgnomeui-2.0.1000.0.dylib) esiste in /opt/local/lib, ma per qualche ragione non viene trovata. Reinstallando X11 è probabile che il pre-binding forzato delle librerie dinamiche, eseguito in fase di ottimizzazione, risolva il problema. PS Grazie a Francesco e Stefano per la preziosa e paziente collaborazione e per gli innumerevoli insegnamenti! LP
  13. LP http://loretoparisi.splinder.com
  14. mpowerplayer è un emulatore midp 2.0 e cldc 1.1 a tutti gli effetti. Non è ancora ufficializzato, come il Sun Wireless Toolkit (disponibile per piattaforma Windows), ma gli sviluppatori sono fiduciosi in suo prossimo utilizzo in NetBeans (http://www.netbeans.org) 1.5.x sotto il nome di NetBeans Mobility Kit for Mac (attualmente esiste nu Mobility Kit for Windows che integra il WTK di Sun).Tuttavia le api MIDP licenziate e quelle CLDC in parte licenziate (dalla Sun) e in parte proprietarie, garantiscono una buona affidabilità per il testing di applicazioni J2ME per dispositivi mobili. LP http://loretoparisi.splinder.com