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).
slashdot now linking to porn? mmm I suppose that is one use for a colour screen....
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
Yes to both. The GSM T720 phones support J2ME.
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 know my Samsung S105 supports J2ME but Ive yet to see any good free J2ME programs out there that do anything worth wild.
The ultimate network admin tool needs HELP!
Colin,
I just read your article at http://www.colinfahey.com/2002dec14_j2me_cell_pho
This one is true, but work is being done to solve this problem. You should soon be able to use GCC.
Test signatures expire after three months. A real signature, which is required to in order to make your app available via a carrier, does not have this limitation.
You are absolutely not required to submit source code for anything. You must submit your *binaries* for testing in order to have them signed. You do not need to submit any part of your application to acquire a test signature.
Get It Now is Verizon's brand name for BREW. In order to make your app available, you need to have it tested and signed. You then submit the app to Qualcomm, which makes the app available to carriers. The carriers then choose which apps they want to carry.
I hope you will correct these mistakes in your article. Thanks.
-Mark
You could have saved yourself some hassle installing all the different toolkits. Just download Sun ONE Studio 4 update 1, Mobile Edition, its completely free (as in beer), and is a great integrated development environment (about 20MB download). All the tools, emulators and demos from the article are bundled. Since last week I'm running it under RH Linux 7.2, with 512mb of ram (YOU NEED LOTS OF RAM!!!). Took just one minute from skipping the regestration screen to stepping through the worm game in the debugger (I always love the game worm/snake/nibbles in all its incarnations, and the demo version provided is beautifully programmed - simple but object-oriented and multi-threaded in a tiny amount of code).
'Be the change you want to see in the world' - Al Gore
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.
There is at least one microprocessor on the market which executes Java bytecodes directly. It has been demonstrateed to lots of cell phone companies, with benchmarking data as well as live demos which show that it is faster because there is no interpreter.
This web page shows a working prototype device which executes all of its software in Java.
http://www.ajile.com/
(disclaimer: I work for aJile)
Second, the majority of the people in the alt.cellular.verizon group aren't mad that the T720 is bad, they're mainly mad that "next generation feature X" isn't in it. True, the T720 isn't the holy grail of high end cell phones - it's a "lite" entry for those who want a color screen.
Finally, most of the newsgroup complaints come from people whose coverage area is bad. It may be that the T720 is less forgiving of bad service. Well, I've had one for a month now and I've been all through Texas with no problem. Perhaps Verizon just likes the Lone Star State.
Schnapple