Abiro  - The Lab
 
Web Abiro
Java ME
   Terminology
      JSR 248 MSA
      JSR 271 MIDP 3.0
   Pros and Cons
   Get Started
   Resources
   Development Tools
   NetBeans
      Getting Started
   Applications
   Projects
      Converter Pro
      EasyCall
      Jiminy! SMS
      Jitter
      Mobile Blogger
      Unit Converter
   Directory

Linux etc

PHP
   Pros and Cons
   Resources
   Applications
   Projects

Visual Basic
   Pros and Cons
   Resources
   Projects
   Snapper

Business Opportunities
 

Java Platform, Micro Edition (Java ME)

Java for Mobile Phones and other Self-contained Devices

Anyone with programming skills can develop basic Java applications for mobile phones, and for a very small startup cost, as you can develop and test them on a PC using any of the free tools mentioned on these pages, and then upload them to the phone from the PC, or download them from your own web or WAP site, or e.g. via GetJar. This is provided you give them away for free. If you intend to go commercial it gets a bit more complicated, especially if you intend to host your own e-commerce solution. There are also e-commerce brokers (read: distributors) for mobile applications, e.g. ClickApps, yet they usually take a big chunk of the revenue. It also gets more complicated if you want your application to run on many different phones. Functionality fragmentation is one of the big issues with Java ME, something the industry is well aware of. The only viable solution to date is to test on every supported phone and adapt, which can be very costly for smaller companies and individuals. There are though labs that focus on such testing and there are also frameworks (e.g. J2ME Polish) that make this less of a problem.

There are lots of applications you can download for free or for a small fee, at this time primarily games, but increasingly also productivity and communication applications. If you have a great idea for a new application you can use e.g. GetJar for checking if there's any chance you can provide something unique, and also "spy" on what others have done.

Talking about trends, it's very clear that online services (public and corporate) will be complemented by Java ME applications in phones to provide a better responsiveness, functionality and user interface than possible via browsers and messaging clients. We expect that this will fully bloom during 2006, and Google and Yahoo are leading the way right now. The industry expects that at the end of 2006 there will be 1.5 billion mobile phones (of 3 billion total) that have some level of Java support, where CLDC/MIDP clearly dominates.

Java ME is an application platform using Java as a programming language, intended for smaller self-contained and possibly mobile devices like set-top boxes, PDAs, mobile phones etc. Covered here is Java ME for specifically mobile phones, which in practice means Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP). Java applications for mobile phones are called MIDlets, reflecting they are MIDP compliant. A few smartphones are shipped with support for CDC as well, that's much closer to Java SE in functionality, but for the foreseeable future CLDC / MIDP will rule. If you are completely lost now, see Terminology for an explanation of the above.

It should be noted that there are several combinations of MIDP versions, CLDC versions and optional JSRs being used in mobile phones. Java Technology for the Wireless Industry (JTWI; aimed at lowering the feature fragmentation) has been broadly adopted by the industry, but there's a lot of crucial functionality not covered by JTWI, including advanced multimedia, MMS messaging, location etc. When counting all the optional JSRs for Java ME it's a very feature-rich application platform indeed, but it's very much dependent on the phone model, and its age and overall functionality, what JSRs are actually supported.

MIDP defines a high level of security to minimize the risk of the user downloading applications that might be viruses or detrimental in other ways. That didn't stop e.g. the Russian "Red Browser" that simply asked the user to select "Yes" on all permission warnings emitted by the phone, so the human factor can still override the security scheme. Anyway, there are two key reasons for why you should sign your application, and that way get rid of permission warnings:

  • the signing is a stamp of approval that your company stands behind the application
  • the user experience can improve considerably (of course depending on how much permission-controlled functionality you use)

If you provide your application to telecom operators they often take care of this for you. If you sell on your own you need to buy a certificate from Thawte, Verisign or other similar provider. Of course, if your application doesn't generate any permission warnings now, then signing won't make any difference, and there's no such thing as a cover-all signing. You might have to sign the application several times for different operators and phone brands.

Note: Java ME was previously called J2ME as in "Java 2 Platform, Micro Edition". Not even Sun itself has fully adapted to the new name yet.

  • Terminology - explains the Java name soup
  • Pros and Cons - personal arguments for and against Java ME / MIDP
  • Get Started - the minimum needed to get started with development
  • Resources - book recommendations, online tutorials, tool downloads and more
  • Development Tools - what you need to develop your applications
  • NetBeans - development suite for Java ME and other Java applications
  • Applications - links to sites with Java ME applications (primarily games, but also utilities etc)
  • Projects - applications developed by Abiro
  • Directory - listing Java ME application developers and customers
(c) 2004-2008 Abiro. All rights reserved. Terms of Service | Privacy Statement | Info Links
Site design, programming and information by Anders Borg.