22 Jun

On the new Java Verified Testing for Java ME Simple Apps

First, let me start by including here the formal definition of the Java Verified program:

What is Java Verified?

Java Verified is the industry-recognised Java testing and signing programme.

Developers take their Java ME apps through a testing, signing and verification process through the Java Verified Submissions portal.

If their apps meets the testing criteria, they’ll gain the Java Verified seal of approval.

Without the Java Verified approval, there’s no guarantee that an app won’t work. More explicitly, the Java Verified endorsement shows the world that an app does work.

Read the last paragraph above… w/o the program, there is no guarantee the app will work across devices and operators. Hmm…

Recently Java Verified launched a new Simple App Testing program. Based on the short video clip on the Java Verified website, this is testing (certification) for “simple apps without complex features such as complex connectivity” and the cost of certification is around 75 Euros! (Today 75 Euros = 92.41500 U.S. dollars).

Some Observations

  1. Don’t create new (temporary) programs or certifications just for the sake of creating one or making noise or make it look easier when it really is not; address the root cause.
  2. When I went to the Orange developer conference almost 2 years ago, Orange plus others were working on a new developer support/app strategy for Java ME. Is this it?
  3. Perhaps a bad example by the person in the video, but what is complex connectivity? Non HTTP? Streaming? Interchanging XML or JSON data formats? Why does it matter? The reason must be related to the cost of testing and testing against external systems, so the more self-contained the app is the better and cheaper (from the Java Verified program perspective). But, why? By definition most mobile apps are connected! And this makes the simple app program irrelevant then?
  4. There should be ONE type of cost/fee, a developer fee (zero or yearly) and NO fees per application. Having to pay per app is not a good incentive for developers.
  5. The fact that there has to be a “simple” vs. non-simple kind of testing reflects the problem that still exist. Instead of working around the problem, address the problem. As long as inter-company politics and interests get in the way, this will never get fixed. There is too much IP across the involved companies, and too many companies involved, and too many interpretations/implementations of the JVM resulting in too many differences across devices (goes back to my point above on cost) which forces certifications and types of certifications and again increasing costs of publishing apps.
  6. Oracle, take over Java ME, negotiate the terms of the IP from the other companies, figure out something. If not Oracle, Nokia then. Or an independent group with a strong following and proven experience like Apache. But someone do something! Everything must be simplified. The fragmentation within Java ME must be eliminated once and for all. If you can’t do this, start all over again, or just adopt Android.
  7. BTW, what ever happened to MIDP3? As I have written before, there are and will be millions of feature-phones out there needing a good development environment for “native” apps; think MIDP3.


30 Jan

Oracle announced it finalized its acquisition of Sun — Bye Sun and Thanks…

Sun Microsystems

As I read Terrence’s blog Goodbye Sun & Thanks, Scott, I think back at my days when I worked closely with Sun. Many believed that I worked for Sun but I actually didn’t…

I have been a fan of Sun Microsystems through out my school years and then during my professional career. Like many, I was part of Sun’s and Java ecosystem and developer community.

Sun and Java have played a big role in my professional career…

I had the pleasure to work with many great people and minds at Sun and use Sun’s technologies. I spent a lot of time working with Sun’s mobile (from KVM to J2ME/Java ME) and server technologies and even writing for them (also see my Mobile Java section on my blog).

For years I ran a popular website/blog called J2MEDeveloper.com and I wrote one of the first books on MIDP. I participated and contributed to many Java Specs (JSRs) and was a very active member of the Java Community Process (JCP) and the Mobile & Embedded community where I was recognized as a community champion/star. I also helped co-design Sun Microsystems’ Mobile Java Developer Certification Exam (SCMAD). Even recently I provided advice to the ME executive committee on the future of mobile Java. In 2009 I was nominated to the 7th JCP Annual Awards.

While I was at AGEA, a startup where I was one of its first employees, I helped bring both companies to work very close to each other. Back in 2000-2003 we created products based on J2EE and J2ME and created NetBeans extensions for developers to create mobile apps. I even helped raise $12.2 million in funding most of which as the lead investor came from Sun, making AGEA a Sun portfolio company. And when I was at Aligo, I created or help create a number of software solutions based on end-to-end Java. And at eZee and others. And via Artemis Wireless Werks the dozens of companies I helped with their mobile Java solutions. And today it continues from Java ME to Java on Android.

As you can see, Sun played a big role in my professional career. Those were great days that I enjoyed very much and which I am very proud of. Those days as Sun are gone now; a new era indeed. I can’t get used to see Oracle’s brand on Sun’s sites. Bye Sun Microsystems, So Long, and Thanks for All the Fish…


16 Oct

On the the rise of open mobile

While looking for information on how CTIA 2009 in San Diego went, I found an article by Richard Wong (who is a venture capitalist with Accel Partners) titled on “The rise of open mobile (and congratulations Android team)“.

A good article by Richard, he reminisces on how mobility used to be in the early days of apps (i.e. year ~2000) when operators were in total control — I do remember those days very well and all the unnecessary control and FUD that literally pushed innovation back about 10 years. Richard then compares that past with what he observed at CTIA 2009 and the lots of noise related to Android — the shift from an operator-controlled mobile world to “Open Mobile” players such as Android.

I have written about this before, on how “control” have been and will continue to shift from the operator and to the ecosystem — the developer and community where developers create (and add) value via their software innovations in applications, where the ecosystem, open systems and common sense will be the drivers for success, where the new deck is the “deck that is on the cloud” and users drive which application succeed or not via simple “application demand”, ranking, recommendations and comments.

For this shift that we are (finally) getting to see we have to thank Apple and Google, but these are recent players. We must recognize the impact made by the Mobile Web and also what triggered it all back in 1999 — Sun with their mobile Java technologies as well as the good old WAP.

I do believe the Android market is going to explode globally becoming a predominant mobile platform together with the iPhone, and that native/local apps will continue to rule for quite a while.

Update Oct 21: Days after I wrote the above, TechCrunch wrote a piece validating my post above on Android; see Android Avalanche: A Complete List Of The Android Phones So Far.


01 Jun

What is new in MIDP 3.0 – a quick summary

As some of you may already know, MIDP 3.0 is going public. While smartphones have taken their own route with respect to the runtime environment, I expect feature phones to adopt MIDP 3.0; to be seen is the adoption by device manufacturers. But that said, FYI, the list of new features is very good (and many of my wishes were satisfied); to mention a few:

  • Backgrounds MIDlets (i.e. services) and auto-launched MIDlets
  • Enhanced storage management w/ support for record tagging/labels and support for external, secure storage
  • Access to unique device IDs such as UUIDs and IMEI (to better manage deployment instances)
  • New UI functionality such as support for splash, idle screen and screenisavers, text input into Canvas elements, tables, tabbed panes, splash screen, scalable images and animated GIF, menus and form layouts, other
  • Support for libraries — now you can decouple common infrastructure components from the app and into libraries that can be shared across apps
  • MIDlet concurrency and inter-MIDlet communication
  • Support for application and system eventing (from the system events such as low-battery, etc)
  • HTTP support for PUT and DELETE in support for REST-like web services
  • IPv6 URLs, file selectors, and other
  • Migration path to CDC
  • A number of clarifications that I hope helps reduce ambiguities that previously permitted inconsistent implementations
  • …and other

Related to this see JSR 271: Mobile Information Device Profile 3 – Proposed Final Draft.


Disclaimer: I was a member of the expert group that defined MIDP 3.0, so I am obviously a bit biased to see this succeed and at the same time very pleased with the set of features that made it to the next generation of the Mobile Information Device Profile (Java ME).

29 May

JSR 271: Mobile Information Device Profile 3 — Proposed Final Draft

It is good to see this. After a long time, hard work, lots of discussions, MIDP3 final draft has been submitted to the JCP…

MIDP3 includes a number of new APIs and functionality. And while the smartphones have gone their own way with their own platforms and environments, MIDP3 is relevant and will be a great environment for feature phones. For those asking what a feature-phone is, Phone Scoop as a good definition:

A Feature phone is any mobile phone that is not a smartphone or PDA phone. Feature phones have proprietary operating system (OS) firmware. If they support third-party software, it is only via a limited interface such as Java or BREW.

Compared to software for smartphones, Java or BREW software for feature phones is often less powerful, less integrated with other features of the phone, and less integrated into the main user interface of the phone.

This is changing, as newer versions of Java and BREW allow software to be more powerful and integrate with more features of the phone, although the difference is still present, especially on the interface side. While third-party smartphone software is a “first-class citizen” on the phone, third-party Java or BREW software is usually restricted to a special “applications” section of the interface.

The Proposed Final Draft Specification for JSR-000271 Mobile Information Device Profile 3 is now available at http://jcp.org/en/jsr/detail?id=271.

“This JSR will specify the 3rd generation Mobile Information Device Profile, expanding upon the functionality in all areas as well as improving interoperability across devices.”

I hope to start seeing MIDP3 devices later this year…


30 Apr

On Mobile Applications, Platforms and Monetization — “Show me the Money”

I’ve been keeping track of a very interesting thread at Forum Oxford (FOROX) on the topic of Android phone dissapointing developers (w.r.t. iPhone), with Jason Delport, Alex Kerr, William Volk (who started the thread) and others adding their different perspectives on the matter. All these guys are mobile experts so what they say resonate with me…

I like Jason’s responses as there is no bias, just pure pragmatism (i.e. he has been burned before); he makes a living building mobile apps, so for him it is about business and making money. Period. Jason’s take on why Android is dropping the ball is as follows:

  1. User’s don’t want to sign up to Google checkout
  2. There are plenty of places to find illegal copies of paid Android apps
  3. The store is over cluttered with crap apps
  4. The store has a poor design and has a rubbish user experience compared to the iPhone app store
  5. Paid apps were launched later than free apps and a tone was set in the market that apps were, and should be, free.

For which I respond as follows:

On #1, Google should do one of two: 1) require and capture credit card information the first time a user tries to buy a premium application, or 2) integrate with the network operator’s billing. On #2, true, but #1 is the main issue. On #3 and #4, I totally agree, plus, the good apps are hard to find! A better way to find applications is needed. On #5, I totally agree as well; the wrong expectations were initially set.

Alex followed writing that developers should be focusing on the platforms that are most “useful” to as many people as possible in the world… these being J2ME, Web and S60.

But useful is *very* relative. For talking on the phone? For writing applications? For deploying and making money from? I used to think as Alex… yes, it all sounds reasonable — target the platforms that (in theory) have the largest subscriber reach. Well, that is, until you take into consideration “Show me the money”, as Ajit likes to say.

From the “show me the money” perspective “rich development platforms and ecosystems” have proven, finally, successful. When I say “rich development platforms and ecosystems”, ecosystems go beyond app repositories, and it is about all the details that make it work, which includes user experience, integrated billing/payment, social and not, feedback system, and all the goodies a good/properly designed app store is all about.

I remember the debates between Ajit and myself over Web vs. local apps a couple of years ago, including at JavaOne Motorola Keynote, where I defended local applications while Ajit debated that “AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development” (note that he wrote J2ME but he really meant local apps). Today I can humbly say that I was right about local apps, and that “AJAX will not replace local apps as the platform of choice for developing mobile applications”. At least not yet. Ajit was/is right that mobile web apps will be huge, but they will in a different way as when it comes to richness and user experience and making money, today it is about a local apps.

And it took Apple to show “us” the way.

App Stores have proven central for developers (i.e. “show me the money”), and for subscribers (to easily find and download apps). And as a consequence, have proven beneficial to network providers themselves – gosh, it has taken so many years for network operators to finally open their eyes, not be so paranoid and over-controlling, and agree with common sense — it is an ecosystem after all. So now, all are converging into similar solutions such as iPhone’s App Store. They have to – the power is shifting to the subscriber itself, and to the developers who are bringing applications, software to the market. And those platforms that don’t play nice with the ecosystem, will fail.

So the argument that subscribers would not download local apps, argument a number of us didn’t agree with and defended against over the years via our blogs and apps, resulted in a non-issue. Yes, users will download rich, useful applications, and even better, will pay for them if given ways to easily find, pay for, and download those applications. While other types of apps such as Web and SMS, well, subscribers do like, but for free! Don’t you agree? What this translates to is into business models centered on the subscriber vs. “the other side of the subscriber” such as businesses, etc.

A word on the various platform

A word on iPhone: the device, the platforms rocks. I have an Android (personal) and an iPhone (work). And the iPhone is a beautifully designed piece, overall, from hardware to software. AT&T will hurt and cry if/when iPhone goes to other operators. As a sidenote, see ReadWriteWeb article by Sarah Perez titled The State of the Smartphone: iPhone is Way, Way Ahead, where she explores a recent report by Flurry that concludes that the iPhone is way ahead when it comes to mobile apps (based on the number of developers, apps and consumers). But, let’s take this report “with a grain of salt”. Why? Because it can be biased as follows: the majority of the developers using their analytics instrumentation code might just be iPhone developers, thus, the sample-set is biased by default.

A word on Android: just give it time. Android has the potential to be everywhere – phones, internet appliances, cars, etc. around the Globe, and thus many different types of developers (mobile to embedded). And it very well might allow developers to enter “emerging” markets easier. Judging Android after 6 months or so means nothing in the grand scheme of things. Time will tell (but I stand by what I’ve been saying thought).

A word on BlackBerry. They are getting it, but imposing a minimum app price of $2.99 — because “they value the efforts of developers” is bogus and is an attempt to sound developer-friendly. Let the market decide pricing!

A word on Nokia: they are trying with Ovi, but keep it simple! I really hope Nokia hits the ball out of the park –but they should consider simplifying their portfolio tho, see On Nokia’s App Store Strategy. Nokia’s attempt to do integrated billing for their App Store and (eventually) requiring Credit Cards mean they are thinking the right way.

A word on J2ME: Java ME suffered over the years due to 1) the process that created it was too slow to adapt, allowing for inconsistent implementations and incomplete API-sets, 2) its security model, and 3) lack of integrated app repository (i.e. app store). I still believe it has potential to be the platform of choice for mid-level phones. Specially with the latest MSA API-stacks and MIDP3 that (I hope) will come out later this year. And today,if you have the right market and channels, go for it.

A word on Web: best channel for apps that easily bring “generic” content out to people. Huge potential, especially with efforts such as BONDI and HTML 5 persistent data and the Canvas elements. In any case it is always a good idea, if it is applicable, to have a mobile web version of your app.

A word on short messaging (regardless of SMS or Twits): best channel for notification-like distribution. Second to none. True SMS is way to expensive and prohibitive for many; SMS though is a cash-cow for network providers who must be terrified of Twitter. If targeting notification-like app such as promotions SMS and Twitter is the way to go.

A word on voice apps: I wish we spend more time investing/researching this mode of interaction.

A word on SIM-based apps: The SIM card will always be at the center of mobile apps – directly or indirectly. New technologies such as JavaCard 3.0 and Smartcard Web Servers (SCWS) have the potential of bringing a new breed of mobile applications. Still developing SIM-card based applications is a niche and very network provider oriented, but if you have the relationship w/ the carrier, go for it!

And what the best type of application is? The hybrid app! This is a rich *local* app that is very good at consuming and rendering web content, as well as direct messages (i.e. SMS, Tweets). In the future, mobile web has tremendous potential but again, it is about making money *today*.

So in conclusion, we have to agree that today, integrated app stores that caters subscribers directly is the best channel for subscribers, and developers, and for operators as well. The potential for reaching more subscribers via J2ME, S60, and Web do exist, but but one thing is to create and attempt to deploy apps for those platforms, and the other is those apps getting payed for, downloaded and used.

As a recent report by IDC (Scott Ellison) titled “Developer Strategies for Success Shift as Apple iPhone Apps Store Passes 1 Billion Downloads” concluded:

Apple has demonstrated — again and again — that the success factors in mobile can change in the blink
of an eye — indeed in as little as 3 quarters in the case of the Apps store. The Apps store is increasingly
central not only to Apple, but to any developer or company seeking to play in the mobile applications and
content space. And understanding the shifting success factors within the Apps store is key to success
both on the device and in the digital marketplace that continues to remake mobile.


P.S. Anders Borg (Abiro Mobile News) has written an excellent analysis of this blog piece — see The state and future of mobile applications. And I like very much Michael Yuan‘s comment saying “What developers want is to address the “maximum number of people who are willing to pay”; exactly!

21 Nov

The Public Review — Mobile Service Architecture 2; Developer Input is Needed

The Mobile Service Architecture 2 (JSR 249) is the specification that promises making Java ME-based handsets what many of us have been waiting for years: API robust and consistent.

The JSR 249 is now in Public Review phase, and it needs the input from the developer community…

MSA 2 Stack – Input Needed! – Click to Enlarge
MSA 2 Stack

Click the image to enlarge. Notice the yellow indicating the area that the Expert Group is asking for input from the developer community. Help the EG prioritize the APIs for the mid-device class (or standard platform); send an email to jsr-249-comments@jcp.org; tell them Enrique sent you… 😉

And as I’ve previous written about on MSA 2, the API is not complete, and the following JSRs that should be considered for inclusion:

  • JSR 304: Mobile Telephony API version 2 -or- JSR 253 MTA version 1
  • JSR 266: Unified Message Box Access API (UMBA-API)
  • JSR 307: Network Mobility and Mobile Data API

Both the MTA and UMBA APIs are in limbo within the JCP, but the JCP should take them out of such limbo-state so the EG can incorporate! You see, while inter-vendor and JCP politics and legality stuff continues to slow things down, platforms such as Android and other continue to move forward.

Download the draft specification from http://jcp.org/en/jsr/detail?id=249.

This Public Review closes on 23 February 2009.