You gotta love Scott Adams…. Today – “Sales Secret Weapon”… Click on the image to go to Dilbert.com:
ceo
This week's Carnival of the Mobilists is hosted at Helen Keegan's Musings of a Mobile Marketer. You will find essays on mobile marketing, communities, mobile web 2.0, service and product reviews, and other. Enjoy the Carnival!
ceo
Come on Blogger! How can you just disable the Mobile Monday Austin blog?!!! Your automated process suck. MoMo Austin is not a SPAM blog!!!
Man, I tell you, this is the exact reason why SLAs should be extended to Web 2.0!!! Crap. It seems that I need to move MoMo Austin blog out of Blogger ASAP. This would be the second time I would move out of Blogger – I used to host J2MEDeveloper.com there, but due to issues back then I decided to move it out, and now this MoMo Austin issue – I guess I don't learn. Let's see if I can get the content out – what a pain in the neck – and they don't say what the “grace period” is…
Why is my blog disabled?
If your blog is disabled, it will be listed on your Dashboard, but you will not be able to click on it to access it. If this is the case, there will be a grace period during which you can request that it be reviewed and recovered. The disabling is a result of our automated classification system marking it as spam. Because this system is automated there will necessarily be some false positives, though we're continually working on improving our algorithms to avoid these. If your blog is not a spam blog, then it was one of the false positives, and we apologize. If this is the case, please write to Blogger Support and we will manually review and restore your blog. Be sure to give us the URL (address) of the affected blog.
Nokia has published their test criteria for J2ME and Symbian applications… It is good to go over these, and keep them handy. These documents will tell you about allowed content, power consumption, UI, interactions, and other requirements that your application must meet if you want to work directly with Nokia — passing the Nokia testing criteria is a requirement to get access to the Nokia sales channels (i.e. having your application pre-installed on the handset, or included in the device sales package CD-ROM, or in the Nokia Web sites or catalogs):


Don't even bother trying to get certified if your application uses or depicts:
ceo
There has been a lot of activity the last couple of months (end of 2005, early 2006) in the Java ME Community, with updates to many specifications (JSR). Many of these updates are happening because JSR 248 Mobile Service Architecture (MSA) is going final.
For those of you who don't know what MSA is, MSA is the umbrella JSR that will define the JSRs all MSA-compliant handsets must support, similarly to how JTWI defined the APIs to be supported (MMAPI 1.0, WMA 1.1, MIDP 2.0, etc.) by all JTWI-compliant handsets (note that the current generation of MIDP handsets are JTWI-compliant). MSA is the “next generation” JTWI if you will, and it will define many JSRs, including MIDP 2.1, as part of its definition. As I said, MSA is close to becoming final, and many JSRs are going or have been through maintenance reviews to include new clarifications that will help in creating new conformance tests (TCKs) that will result in consistent behavior across implementations… or at least that is the goal.
One of the JSRs that is currently getting updated is the MIDP 2.1 (JSR 118) specification, which currently is in maintenance review — the maintenance review period closes April 17. There are quite a bit of clarifications, important ones, under MIDP 2.1. If you are a mobility developer or product person, you should check it out and provide feedback (send feedback to jsr118-mr21@mobile-experts.org).
This revision is VERY important, because it will be the foundation or version for the upcoming MSA specification, and thus for all MSA-compliant handsets… and it is the last opportunity to include clarifications before MIDP 3.0 comes along, and, it will be foundation for MIDP 3.0.
You can find the MIDP 2.1 change log here, and the main page here.
Other Java ME JSRs in maintenance review include: JSR 82 Bluetooth APIs. The following JSRs recently closed their maintenance review: MMAPI, Location API for J2ME, and Scalable 2D Vector Graphics API for J2ME. I could be missing others.
Let me close by mentioning other important Java ME activities:
There are lots of opportunities for you to help shape the future of Java ME.
ceo
If you want to learn about how to make money with Google, go grab a copy of Make Easy Money With Google: Using the Adsense Advertising Program, which is written by my buddy Eric Giguère, mobility expert, and now considered the contextual advertising expert… Very cool. The book, which is targeted at people who want to learn how to create a presence on the web and make money with AdSense, is one of the Technorati Top 30 Popular Books…
OK, I have to admit… that I am a bit biased, as Eric is co-author of my J2ME/MIDP book, not to mention that I spent quite a bit of time reviewing this Google/AdSense book while it was written…
Book Description:
Get your Web site to “show you the money” by using Google to draw more eyes–and wallets–to your content. In this friendly, four-color guide from veteran author and Web developer Eric
Giguère, you'll learn all about Google's AdSense program and how you can use it to make your Web site…
ceo
The W3C has published The XMLHttpRequest Object specification working draft…
As you may know, the XMLHttpRequest object is at the center of AJAX, and while it is implemented across Web browsers, the implementations are not 100% interoperable, requiring special handling by developers.
The goal of this W3C XMLHttpRequest specification is to “document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code.”
ceo
No surprises here… A Mobile TV study by Red Bee Media concludes the obvious:
“full length programming on mobile is not as popular as made for mobile TV because screen sizes are too small, opportunities to watch full length
programs on-the-go are rare and subjects preferred to watch full-length programming on the TV”
But… it is good that someone is paying for these kind of studies, so that there is no doubt: mobile handsets, and their usage-model, are not the same as desktops, or regular TVs for that matter…
[Via Celluar-News]
In response to comments from various mobility bloggers, including mine, Ajit Jaokar has written part 2 of “Mobile web 2.0: AJAX for mobile devices – why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development”. A very good essay that I recommend you read.
Ajit did a good job summarizing and clarifying a number of points that he'd made on Part 1, and that I'd disagreed with: 1) on Mobile AJAX replacing local/rich and XHTML clients, and 2) on when Mobile AJAX is applicable and when it is not.
I'll start by saying that I do understand the disruptive potential of AJAX in the mobile space. But I don't believe Mobile AJAX will replace rich/local clients – there is a place for browser-based applications, and there is a place for rich/local clients. And Ajit clarified that – his point is that the majority of the mobile end-users will use applications that are mobile AJAX-based. Note that while Ajit says AJAX, I say browser-based — I make no distinction between the two – a browser-based app may or may not use asynchronous communication using JavaScript, and still be widely used — a good example is the current, plain but useful Weather.com and Google applications on mobile handsets. I do understand that AJAX will make browser-based mobile applications better, more dynamic – like browser-apps on steroids.
I like Ajit's use of the 80/20 analogy to explain how and why browser-based applications will outnumber local applications. I think it is a good representation of the (expected) distribution, and it goes inline with what I am saying that there are times when the browser-based approach vs. rich/local applies. But AJAX is not the reason for the 80/20 distribution. The reason for the 80% is that most of the mobile usage is just about fetching content and rendering it to the user – that's it, searches, weather, sports information, email — and browsers satisfy that very well. It is known that browsers are, after text messaging (which in turn comes after voice) one of the top usages of mobile handsets — and this is regardless of AJAX. The other 20% would be about advanced rich clients (native or Java ME or BREW, or as Debi pointed out, Flash, and so on) that use messaging, and location, and multimedia, and advanced graphics, and persistence, and all the advanced features that are needed for those types of advanced applications:

[Source M:Metrics press release March 6, 2006]
Will AJAX shift the above 80/20 to let's say 90/10? Probably not, 80/20 sounds about the right distribution. But I will add that the 80/20 distribution is when looking at this from the horizontal perspective – if we look at individual verticals, such as gaming, non-browser-based applications outnumber, and will very likely continue to outnumber browser-based ones.
Browser runtimes or containers such as Opera and others provide or will provide access to native functionality (for the record, I run Opera on my desktop and my handset, but haven't spend time with their SDK yet). But for Mobile AJAX to reach its full potential it must go beyond a single vendor, beyond Opera, and in a standard way, which means standard JavaScript objects and methods, services, and behavior. In the meantime it is fragmented. And, the minute such platforms provide access to those native APIs or capabilities, which are considered restricted by many network carriers, we will get into the same issues that native and Java ME applications get into: privacy, and security, and signing issues. Do I now have to sign my browser-based application as well? And let's not forget that creating web sites or server-side mobile applications require "special attention" – device management, transcoding/transformation vs. “hardcoded” mobile websites, .mobi or not, (lack of consistent) CSS support, possible re-download of large amounts of AJAX JavaScript (which translates to cost), and so on.
But at the end of the day, it is the the end-user, and the industry who will shape this space — let's wait and see. It is interesting to me though to see what the developers themselves, the ones who create mobile applications based on customer needs or opportunities they see, think about this topic of Mobile AJAX. Below are the results of a poll I did on my website as part of my response to Ajit's Part 1 of the Mobile AJAX essay:
Results for Mobile AJAX vs. Java ME? (Responses: 189) Java ME will rule: 42% Mobile AJAX will rule: 10% They are complimentary: 37% Does it matter?: 12%
You can find the poll here (click/expand the line item Poll: Java ME vs. (Mobile) AJAX)
In conclusion, browser-based mobile applications, with AJAX, have great potential, and will be widely used – and browser-based mobile applications already are. Rich/local clients will too. Browser and local/rich clients are both complimentary. The 80/20 distribution sounds interesting, and it applies to the mobile usage when viewed from the horizontal/broad perspective.
I am looking forward to browser-based mobile applications "on steroids" using AJAX, and for browser containers that provide access to native functionality using a common, consistent way — it is up to the browser players to get together and make that happen. (BTW, browser players should also get together and standardize widget authoring). I am also looking forward to, and will help define, the convergence of browser and Java ME clients through the new JSR 290 APIs, whose goal is (or should be) to allow for (rich/local) Java mobile applications with browser-based functionality. In the meantime I say "think forward, but deploy today".
Related blog entries:
* The Web 2.0 from a Practical Perspective
* Will AJAX Save The Day (for Mobile Apps Development)?
[Image source: OpenGardens / Future Text]
ceo
"Great individuals invent their own values and create the very terms under which they excel." -Kierkegaard and Nietzsche