A new product from AppForge, known as Crossfire, can leverage on your familiarity with VB.NET (or Visual Basic 6) and write cross-platform mobile applications supporting a wide variety of devices. What that means to a developer is that you now do not need to use the proprietary SDK for each device platform — you simply maintain one code base and it can then be deployed to multiple platforms.
Writing Cross-Platform Mobile Applications Using Crossfire
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
“now do not need to use the proprietary SDK for each device”
How about not using the AppForge proprietary SDK(!) and using Java instead – supported on a hell of a lot more devices than S60+ devices.
“that will run on over 90% of the world’s handheld, mobile, and wireless devices including Palm OS, Pocket PC 2000/2002, Windows Mobile 2003, Nokia Series 60, and Symbian UIQ”
Bah – marketing stuff. 90% of mobile devices are NOT that powerfull!
For a long time, there will be a lot of S40 class devices (and lower!) out there. So by using AppForge you will severely be limiting your sales.
That said, for inhouse projects, or projects you *know* will be S60, Palm or whatever device supported by AppForge it could be a nice option. Except, I fail to see what AppForge can do, that I cant in a j2me environment ?
My impression after reading the article and reading the crossover docs is that yes you can build for the supported devices… but not a common code at all…
(even .net cf doesn’t do that and i’ve no idea on how j2me behaves)
In reality, small device programming still needs “the tool”. The input/output layer should be decoupled with funcionality to allow you to “skin” the interface for each device you want to support (this is specially important if the “screen” is of diferent sizes/capabilities).
Alas, another small step in the right direction thru… (but not the final solution iet).
The input/output layer should be decoupled with funcionality to allow you to “skin” the interface for each device you want to support
Can’t that be reached by coding? Separating the GUI module from the functional module?
I have some experience with J2ME so let me give you my executive summary. J2ME sucks. It’s built for limited phones, not PDA’s/Smartphones.
Not having pointers in java really kills you on a handheld with limited memory and where data store records are in memory already. Why should I have to turn a record into a byte array when in C i can just lock it in place and read it directly? This really becomes unwieldy when you have to sort/search through a lot of records.
Even worse, they didnt include JNI so you cant access any native code to extend the very limited API built in. At least with the compact framework, you can pInvoke dlls.
You cant access any of the native apis for things like:
Native Data Storage/DB engines
Telephony
SMS
Voice Recording
SD card access
Hotsync/AtiveSync conduits
Camera
Voice recording
Write once run everywhere dont cut it in this industry where new toys are constantly being put into the os. J2ME just cant keep up.
I am sorry to hear you don’t think j2me is good enough – but those issues you have are hardly solved by AppForge?
btw SMS, Telephony, Camera (and perhaps some of the others) are accessible from j2me. Depending on the vendor though :/ (need to support the relevant JSR’s)
I’ve been working with this platform for over a year now to build for enterprise devices… ie. devices with integrated GPS beacons and barcode scanners.
It’s an alright tool for building simple applications, but when you try to stretch the capabilities even slightly to solve more complex problems related to issues like wireless networking, etc. the tools fall flat on their face. There are so many missing API calls that *SHOULD* be there, and failings in proper behavior in the event model that makes one wonder if AppForge bothers to QA this software at all prior to release.
I also installed some java apps on my Clie (coming with the j2me package), they are terrible. They were just not responding well and they look even worse than native apps.
So, I am sure Crossfire might have a stand here.