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
Yes to both. The GSM T720 phones support J2ME.
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.
Yes, having people call you ANYTIME ANYWHERE is quite a "freedom".
If I ever give in and get a cell phone, it will be for outgoing calls only, that's for sure.
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
With the rant about porn, I agree. With the rant about cell-phones, I completely disagree.
At work we have a couple hundred employees who are not in the office - or any office - most of the time. They stay in contact and do there work by means of their cell phone. In addition to basic voice calls, it sends and recieves email and acts as a modem for thier laptop computer. These features exist because of the very innovation you rail against here.
Furthermore, innovations and open innovative systems like J2ME create an environment in which additional feature sets can be added to a phone at an exponentially faster and more diverse manner. This means that some people are going to choose to do some disgusting things, but it also means that you can choose to do some amazing things. In fact, you probably won't have to - some other geek will do write the programs for you. He might even give it away for free.
Here's the point. Most people don't need (or want) all of the power of their laptop while they are walking down the street, but there are some things they'd like to be able to do. If their phone can handle it they don't have to carry (or even buy) a laptop.
I'm alergic to sig smoke.
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!
Although I have not intention (at all) of developing or using programs on my phone knowing that my phone has been hamstrung is very annoying. AAMoF, I currently pay $100/mo for a family plan, thus a $175 fee to cancel my contract (which I just renewed for two years) is not very painful: if I cancel now I'll deprive VZN of at least $1100. . .
This article has made me pissy. Maybe it's because I'm enjoying my new Zaurus which allows me great flexibility as a developer. I specifically didn't choose the PokeyPC because the open Zaurus is available (and Opera, esp. Opera 6 (in beta) far surpasses PokyIE). VZN blew it for me.
-- @rjamestaylor on Ello
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.
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
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.