Slashdot Mirror
Developing for the Motorola T720
r0.ini writes "Nice step-by-step introduction guide on how to make that cool app for your T720." Worth a read even if you never intend to write a program for your cell phone, for the comparison between BREW and J2ME (and implicitly between Verizon and AT&T).
Do you realize how close they are to releasing the T-1000? We're all going to die!
slashdot now linking to porn? mmm I suppose that is one use for a colour screen....
Only after getting the cell phone, however, did I realize the amazing freedom of being able to call or be called anywhere at any time.
Someone give him a coconut.
I didn't bother looking at the link until you mentioned there was porn.
Shame on you Verizon...shame shame shame!
You're all bastards!
I totally agree with this guy, J2ME is really cool. I went to lunch with a couple friends the other day and they both had java phones. So i came home, grabbed Sprint's Wireless Toolkit and started playing with it.
I'm really impressed how fast you can develop applications for it. One friend wanted a tip calculator, which took about 5 minutes after I figured out how everything worked. It is alittle different from standard Java and you're missing some important things such as floating point numbers (float and double are gone). So it does take some getting used to.
But most things are really easy todo, such as writing a small app to send SMS messages, the important part of the code is only about 10 lines long. Check it out, I'm planning on picking up one of the Sprint phones when my contract expires in a few months
I had an opportunity of developing applications for both environments BREW and J2ME on Motorola T720. I agree that deploying BREW application for real phone is quite complicated and expensive. But there are ways to lower costs of development. For example, it's possible to use GCC crosscompiler for ARM which saves $1500. It's not easy, but it works! And I believe that author of the article didn't even try to develop any J2ME application for T720 phone. I did, and J2ME is about 20 times slower than BREW, which makes it completely useless...
I don't know about you but I want a mobile phone to make calls. I don't need a phone that decides to crash and reboot in the middle of a call... I have enough headaches with PCs, I just want my phone to work. (ps, I have never tried one, just my observation from reading that newsgroup when I was trying to decide what phone to buy. Based on the rants, I got a v60i for the wife and hung onto my trusty 2 year old moto 7868W startac which has always worked like a champ)
Sounds like a good script for a horror movie. The bad guy is about to slash you up in bits, you reach for your fancy cell phone, and it blue screens while trying to call 9-1-1
Speaking as a former employee of a large cellular phone company, I have one big question..
Why the hell is everyone looking at some whiz-bang cell phone features but settling for crappy reception/range?
Grr. I know why certain areas don't have cell towers. Not profitable, NIMBY folks, FCC regs, etc.. but what I don't get is the notion that your phone needs to be a second Game Boy. If I want to play games and crap, I'll get an actual Game Boy Advance. I use my Ericsson T68 for my address book & calendar stuff. Maybe some WAP browsing here & there. But, that's about it. I would much rather have more effort put into stability & call quality than "gee whiz!' features.
First off, if you are serious about developing for J2ME, you should get the Sun WTK (which is free), or perhaps the JBuilder personal edition + MobileSet (also free).
Creating JARs and JADs by hand is a pain in the ass. One should build with ant, and use a JAR creation task such as JADCreator or the tool from Stampy soft (whose name escapes me at the moment). JBuilder Professional will also build JARs for you.
Moving on to the T720; it has problems. Networking is seriously screwed, and there are reports among developers of bugs such as: your JAR not working if the size is an even multiple of 100 bytes. While it is cool that you can do OTA downloading, the real deal is to load apps via the serial cable using Midway. Unfortunatly, the only way to do this is to be a developer, and convince Motorola to flash your phone with the correct ROM version. It also blows that you cannot view output from the phone via the serial cable using Hyperterminal; the i95CL does allow this, which is vital for debugging on the actual device.
Lastly, the Brew issue: development companies love the very things the author despises (well, not the $1500 for the dev kit). If you are shipping product on J2ME, and actually plan on making money, you have to deal with the complete lack of adequate billing solutions (and each carrier does things differently, and has a volumnious documentation describing what you need to do to work with them). Brew takes care of this for you, which is a big plus.
There are important reasons for the differences between BREW and J2ME, and BREW solves many problems that J2ME does not. As others have said, some of these are extremely important to carriers and professional software development companies:
- J2ME performance is very slow compared to BREW native code
- Most J2ME implementations are also very limited in total code size in the JAR, and available heap space to work with at runtime. It's a bit frustrating, b/c the current limits are typically just below the threshold for "toy app". If they were even 2-3x what they are now certain types of more complex apps would become possible, but I expect the next release of J2ME to increase the JAR and heap limitations significantly, so this is more of a temporary gripe.
- There are significant limitations in the current J2ME APIs that restrict multimedia capabilities. E.g., can't create a new Image out of an array of pixel values, so you're left with blitting around bitmaps loaded from the jar or the net. This means no 3d graphics, among other things
- J2ME implementations change from phone to phone, many manufacturers add custom multimedia extensions to get around the restriction above, but this makes it hard to build certain types of apps and deploy widely (often a business relationship is required w/ the phone manufacturer or carrier to get access to their extended APIs.)
- There is no standard download model for J2ME (this is very important to carriers)
- There is no standard billing model for J2ME. This is extremely important for carriers and software producers, and is one of the main reasons for Qualcomm's centralized control of the certification process, and the download/billing infrastructure. It is proprietary, but provides many important things (billing, versioning, test-downloads for free that expire, etc.) that in the J2ME world keep getting reinvented for each separate carrier, if they get implemented at all.
- I know that paying for apps is not as "nice" as free downloadable applets, but it's the only thing that creates a real market of real apps. How many companies are selling java applets that run inside web browsers? How many java applets do you download and use from the web, in your day-to-day computer usage? NTT DoCoMo implemented their own custom certification and billing process for their version of J2ME called "i-Mode", and it led to the incredible explosion of the cell phone market there. You pay incremental monthly billing charges for your apps, but it has driven the "coolest" market for phone technology in the world, both for cell phone software and hardwrae. It is fun and cheap to have really cool stuff on your phone in Japan, because companies can make a lot of money with small billing charges in a mass market.
- In a certain sense, BREW can be thought of as trying to replicate the market and business model of NTT DoCoMo, but using their own custom native-code platform instead of J2ME. The carrier gets a small cut (~10%), Qualcomm gets a small cut (~10%), and the developer gets most of the money (~80%). I believe these numbers change some from carrier to carrier. But this type of billing market I believe is necessary to duplicate the kind of explosion that happened in Japan.
On the flip side, I concede what I think are some of the major points in the author's article:
- BREW is proprietary, controlled by Qualcomm. There are pluses and minuses to this, I'm not looking to start a religious war. Personally, I prefer open-source standards. Business-wise, it has been very helpful for companies that Qualcomm controls the BREW standard and the software infrastructure that supports the business model.
- The development tools are harder to come by. Either pay $1500 for ARM tools, or do some extra legwork to get GCC to compile correctly for BREW apps. There is no widespread community for support yet, outside the companies who have started developing for BREW.
- You can't upload your own code to the phone outside of the Qualcomm/carrier download model, and the certification process typically costs in the low $1000s of dollars per app, so this completely closes out the geek hobbyist development market. This is very lame. I'm not buying a cell phone until I can: 1) develop in native code for it, 2) upload the code to the phone on my own.
Some things in the argument were overstated or perhaps misunderstood:
- You don't have to submit source code for your application. In the case of a library (not app), you have to submit the source code for a unit-test program that exercises the functionality of your library in all of the various use-cases.
I develop both for BREW and J2ME, native-code is very important to me for application speed (multimedia, 3d). I have been very happy with BREW as a platform and have found it better to work with than J2ME in almost every regard. However, it is too closed and expensive for hobbyist at-home use, a major downside, and not an option for open-source development. Also, there is some chance that the next few revs of J2ME will fix many of its current drawbacks and the terms of this debate will be reversed.