After attending Scott Knaster's iPod Parlor Tricks, it occurred to me that a photo slideshow is not much different from a presentation. Perhaps the device could be used as a (ultra) portable presentation device?
Read iPod Photo as Portable Presentation Device? on my O'Reilly weblog.
Some interesting Wi-Fi news from the Big Apple.
Today during my commute into the city I passed Verizon setting up an extravaganza in Madison Park (23rd-27th street between Broadway and Madison). Seems Verizon is talking up the hundreds
of hotspots they have deployed around the city. Oh yes… and that they and MSN have jointly launched a broadband service also. (That is the sound of one hand clapping that you hear.)
The hotspots are available to its DSL subscribers free of charge. Very smart of them. (Look here for more info.) They were handing out duel hotspot and subway maps in MetroCard holders. According to my pocket map Verizon's coverage in New York includes Columbia University/Morning Side Heights, Upper West and East Side, Midtown from 59th through Chelsea (coast to coast), The Union Square extended, NYU/Washington Square Park, Wall Street/Battery Park and Brooklyn Heights. (Why is their online hotspot maps are SSL protected? Maybe they are not as smart as I gave them credit for.)
Like I said, interesting. It doesn't help me really. Verizon provides such poor service to my neighborhood that I went with @Home now Comcast. I suppose it will be helpful in getting the market to innovate and keep moving forward at an aggressive clip. T-Mobile recently announced they are packaging mobile phone and Wi-Fi. (I'm really considering T-Mobile for my next phone to take advantage of that and justify my Starbucks coffee addiction.)
UPDATE: Seems I'm not the only one thinking Verizon's move could mean something to the price and service of broadband hotspots. Internet News is reporting that Verizon could spark me-too Wi-Fi efforts. This being said, Reuters notes in that whether it be broadband Internet access, 3G mobile phones or flat screen monitors, the high-tech industry has turned hyping new technologies into high art. Cashing in is another matter entirely.
While I'm getting any real work done today having unleashed my dormant mobile computing thinking, Mark Pilgrim writes about his weblog's mobile edition concluding:
As I said, XHTML Basic has no basis in reality. Ignore it.
Certainly his points are understandable though less so outside of the US. I don't think you'll be able to ignore it very long though.
XHTML Basic is the underlying markup language of WAP 2.0 that replaces the wrong-headed Wireless Markup Language (WML) of version 1.0. Despite all of its foibles and my own harsh criticism, WAP still has the support of all the major telcos and handset manufacturers of the world for browser based applications. Most notable is Japan's NTT DoCoMo who operates i-Mode, the most successful (by a landslide) mobile Internet service in the world. Replacing WML with a standardized XHTML subset was the key concession to getting NTT to endorse WAP and migrate away from its own HTML subset called cHTML. A good, but somewhat dated summary by Wired can be found here.
Are an extensive amount of devices with WAP 2.0 out there? Not really, but look for that to change in the next year or so. So enjoy ignoring it while you can.
There are zero occurrences of the word asynchronous in the current JSR 172 (J2ME Web services) draft specification. If there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate. More over on my O'Reilly Weblog.
CNET has posted a video interview (the link pops open a window) with Paul Festa and Opera Software CEO Jon von Tetzchner demonstrating their mobile browser that I wrote about here. At the time I wrote:
I've always been skeptical when it comes to these attempts to repurpose web content on a mobile device as Opera's proposal or existing implementations such as Danger's HipTop browser. I've never seen them succeed at anything but frustrating users.
Web pages are designed for large high-resolution color displays, the use of keyboard and mouse and a reliable and relatively high bandwidth connection. Being a display language HTML is not terribly efficient or reliable for consumption by another application. "Qualified guessing" will yield the equivalent of a Frankenstein monster. It’s a hack at best.
Yes, if designed properly a Web page will scale gracefully and adapt to different displays and resolutions -- IF is the operative word though. Like eating your vegetables, most of know we should do it, but don't. Face it, web sites do some rather freaky things with HTML. You don't have to go past the world's most prominent software company's site to witness that.
I still remain skeptical this approach will ever work -- perhaps even more so after watching the video interview.
The interpreted CNET gateway used in demo seems readable, but it hardly looks like its original self. It also requires a lot of scrolling to read. The demo is also done using Sony Ericsson's P800 mobile phone which sports an extra large color screen. Goes to a Nokia phone momentarily and switches back to the Sony Ericsson device before giving a really good look.
Personally I remain optimistic and intruiged with the utilization of well-formed RSS and XSLT in addition to the development of novel applications (most likely using J2ME) for users on the move.
Mark wasn't the only weblogger to have an O'Reilly article published yesterday evening. My latest "Introducing MIDP 2.0" was posted here.
MIDP 2.0 improves on the original specification for open development on mobile devices by introducing secure networking, extended network connectivity, and audio and gaming capabilities.
A follow-up weblog post on Web services support in J2ME is forthcoming.
In response to the Bluetooth article "Teething Pains" published by the Boston Globe on November 11th, Bob Frankston provides some notable insights and criticism of the wireless networking technology's design.
We should learn from the example of X.400. X.400 was (is?) a mail protocol approved and required by essentially all the telecommunication agencies throughout the world. It was designed over a period of ten years yet failed against SMTP (Simple Mail Transport Protocol) which could be implemented in an afternoon. Like x.400, the Bluetooth was designed and promulgated before anyone could learn from the first generation. Bluetooth is designed to work in the specific cases imagined by its designers and thus will perform very well in precisely those scenarios and these are the scenarios touted in press releases.
Frankston continues...
Bluetooth is in the mainstream of the old model of telecommunications in which all the services are defined by the center and every new capability must be approved before it can be deployed and thus before we even understand it. 802.11 is simply a transport for packets and doesn't stand in the way of creating new capabilities.
Once again we face a familiar paradox. Bluetooth which defines so much of the solution is thus limited to what it defines and that is very little and it only works among a few nearby devices. 802.11 which makes few promises inherits the existing richness of the Internet Protocols and has no such limits of distance.
While I admire Opera Software's work and persistence in advancing browser design, I can't help but roll my eyes reading their recent announcement. Opera has developed a mobile browsing technology that has, as Paul Festa reports, "finally solved the long-standing problem of reading big, bulky Web pages on tiny cell phone screens, posing a potential threat to both WAP and to Microsoft."
Mobile users don't browse like they do from their desks, so let's stop trying to repurpose content designed for the Web.
WAP has failed for a host of reasons including the inherent security hole of the WAP gateway architecture, initial deployment on circuit-switched networks as opposed to always-on packet-switched data networks, and a lack of well-designed and useful applications. Even once addressed, browsing would still have its issues and limitations in the mobile arena. Mobile users are "on the go" and generally not in environments where they have the time or patience to navigate content as they would seated at their desks. Their environment requires useful content and applications to be location-based, time sensitive and concise. In addition, utilizing an architecture where nearly all the data and logic resides on a remote server is a poor fit with the reality of unreliable and low bandwidth connections. It frustrates users and erodes their confidence.
Besides, WAP and more specifically WML (WAP's markup display language) is becoming more symbiotic with the Web. WML2 is an extension of XHTML that utilizes a mobile specific profile. (In his CNET article, Fiesta incorrectly compares WAP and HTML that is apples and oranges. WAP and Web Architecture or WML and HTML would have been more appropriate.)
I've always been skeptical when it comes to these attempts to repurpose web content on a mobile device as Opera's proposal or existing implementations such as Danger's HipTop browser. I've never seen them succeed at anything but frustrating users.
Web pages are designed for large high-resolution color displays, the use of keyboard and mouse and a reliable and relatively high bandwidth connection. Being a display language HTML is not terribly efficient or reliable for consumption by another application. "Qualified guessing" will yield the equivalent of a Frankenstein monster. It’s a hack at best.
Yes, if designed properly a Web page will scale gracefully and adapt to different displays and resolutions -- IF is the operative word though. Like eating your vegetables, most of know we should do it, but don't. Face it, web sites do some rather freaky things with HTML. You don't have to go past the world's most prominent software company's site to witness that.
Despite my criticisms in this area, I still believe in the promise of mobile computing. Mobile data devices will eventually surpass the number of desktops. They're more affordable and the constraints of these devices insist on a simplicity that will assist the mass-market in embracing interactive services.
Repurposing Web content for mobile is not the answer, it’s a hack. Studying mobile users’ needs and tendencies, getting content into easily consumable formats and developing more usable and appropriate mobile applications are the real answers.
In his content syndication weblog, Ben Hammersley points out a nifty mobile application named PeekAndPick that he's begun using on his new Java enabled phone. PeekAndPick is a J2ME MIDP application for reading headlines and excerpts from RSS feeds and selecting the items you are interested in reading later. Your selections can be compiled into a list of links and emailed to your desktop for later reading.
PeekAndPick, the work of Jonathan Knudsen, is a brilliant mobile app because it illustrates good mobile application design. It doesn't try to do too much or be like a desktop application. It does demonstrates how mobile and traditional Internet channels can be used to provide a useful and appropriate solution together -- though it could do that a bit better. (More on that in a bit.)
The application's design acknowledges that mobile means "on the move." This mobility generally finds the end user in a less then ideal setting (context) that requires information be concise and interactions simple in order to be useful. Mobile users do not browse -- especially on a screen that typically is not much large then a postage stamp. (Note to telcos and device manufacturers: Web content was not designed or with a mobile devices or users in mind. It futile to try because it really doesn't work out and it just annoys people.)
While very well done application that we have to give Jonathan a great deal of credit for, PeekAndPick is not without its issues or room for improvement.
PeekAndPick underlines the need for RSS feed publishers to exercise good form and provide descriptive titles and concise well-formed excerpts. Since quite often this is not the case, PeekAndPick would probably benefit from a server-side proxy that retrieves feeds, cleanses them and strips any extraneous information that the app does not need. Besides heading off trouble this approach also helps keep bandwidth use to a minimum. Optimizing bandwidth usage not only improves response time, but it saves the end user some money. Remember mobile data services are typically priced by the bandwidth consumed.
Most of the configuration for the app, such as defining your list of feeds, should be handled through a web interface and not the mobile device. At a former employer, where I consulted on a number of mobile projects, we professed "configure while seated, consume while mobile." Who wants to type in a URI like http://www.timaoutloud.org/xml/index.xml with their phone's keypad?
In my cursory review of the code, the application does not queue messages if a connection if not available. Given the unreliable nature of mobile networks, handling these occurrences is important, even crucial, to developing user-friendly and reliable mobile applications.
I could really use PeekAndPick myself because I find myself woefully behind when I'm away from my desk for any extended period of time. Alas, I cannot use it because I use a Blackberry 957 that is not Java-enabled. (I love my Blackberry and still find it useful, but I've been deeply disappointed that RIM has forsaken users and not continued to advance this model's capabilities by providing J2ME support as its descendants. I suppose that's for another posts though.)
Check out PeekAndPick and consider your mobile application future.
Infoworld is reporting Microsoft announced at DemoMobile that they have come up with the killer application for mobile: Location.
I laughed maniacally when I read this. Its not that Microsoft is wrong. They are quite right. I laughed because I had to wonder "what took everyone so long?!?" Is it so hard to fathom that location would be a crucial factor in mobile data services?
I worked for a company that did some consulting on mobile back when it was the next big thing. It became abundantly clear then that, as they say in the real estate business, it was all about "location, location, location." Despite names like the "wireless web", mobile Internet services are used in a very different context then from a desk with a full keyboard and large color screen. The user's environment necessitates the need for short, time sensitive location-based chunk of information. Mobile users do not surf.
Over two years ago I visited Seattle for the first time. Armed with my then new Blackberry 957 and with a WAP browser I was walking around with a colleague looking for a place to eat. Being enthralled with the power of mobile, I pulled out my device and went into 10best.com's mobile service to find a seafood restaurant. Dozens of clicks and 40 minutes later we found a place almost by dumb luck. I had to navigate through several levels, (Portal menu to 10best menu to Seattle to restaurant to seafood etc.) and manually scan each listing to make a determination. Besides being laborious, I was never in Seattle before and didn't know where most of these locations where relative to where I was standing. I never tried that again.
When asked by clients if they should build mobile app X, we would advise "only if it is better and more convenient then other options." With this understanding mobile applications location because the differentiating factor from mediums like the desktop. This makes location a near requirement to good mobile applications.
In all fairness, I do have some sense of what took so long. Determining location of a mobile user is difficult. Global Position Systems (GPS) requires too much power. Cell-tower triangulation can be highly inaccurate especially in big cities such as New York where signals ricochet off buildings. Determining location also requires the roll out of additional equipment. I am of the opinion that location was more important to mobile data adoption then 2.5G and 3G bandwidth and that the telcos place their efforts in the wrong place.
Going back to my trip to Seattle, ideally I should have only had to select restaurant recommendation and perhaps the type, seafood. I should have then received a list of 3 or 4 of the closest right away because the application new I was in Seattle standing near the Pike Place Fish Market. My personal killer app when I did a lot of business travel would have been a service like this for locating the nearest Starbucks. One click and "Here is the closet Starbucks. Do you want directions?"
In another astounding revelation, CNET is noting that "Push technology is finding redemption in millions of cell phones." What is this push technology? SMS and always-on wireless email. (I developed a homespun solution with Blagg that pushes news excerpts to my device periodically throughout the day. It took me less then an hour to setup.) Once again this makes a lot of sense, but I am astonished at how long it's taken the industry to get it right.
My letter to the editor gets printed in response to David Berlind's "Binary compatibility: Holy grail or red herring?" The letter was based on this post I made some time ago.
Working in J2ME means do more with less, and has really illuminated specifications in a way I wasn't capable of doing before. The difficulties in the XML spec become much clearer, SVG Tiny starts to look huge, and things which might have looked reasonable in the ever-faster ever-more-bloated environment of PCs become plainly stupid. While I miss a few things (like Java 2 Collections), for the most part, it's a privilege to work in a leaner environment for a while. I doubt this will sweep the computing world, but maybe it should. [Simon St. Laurent - "The strange pleasures of J2ME"]
I know exactly how Simon feels. My research into, and at times outright yearning for, a simple and streamlined desktop apps is a direct result of my work in mobile computing and more particularly J2ME. Working with J2ME really makes you think about what really is necessary in providing the solution as opposed to whiz-bang features and other forms of programmatic kung fu. What's more amazing to me is how incredibly small and lightweight functional applications can be relative to what we have on the desktop. Its made me come to the realization that as programmers we have, perhaps subconsciously, become far too reliant on the every increasing resources the Intel, Microsoft and Dell tell us we need.
This is not to say that Photoshop or a full-featured web browser can be written in a 35k MIDlet. For some applications this approach is not really feasible. Nonetheless most application code are interfaces with some data handling logic. Coupled with Web services to a robust backend, these applications should be quite small and very quick on their "desktop mainframes" most users have on their desktop. If it weren't for the 20 MB download required, I would say the .NET Framework in some ways demonstrates. The MIDP KVM and core libraries are measured in KBs not MBs.
MIDP is a bit too spartan and extreme for use on the desktop. With the basic and limited GUI provided by MIDP, you will not win any design contests. MIDP is just one profile (and the smallest for that matter) in the J2ME world. In the J2ME connected device configuration or CDC (MIDP is in the Connect Device Limited Configuration or CDLC) there are profiles such as the Personal Basis profile, that have richer, yet highly streamlined, APIs that might be more appropriate for desktop application. (J2SE may be fine for developing JBuilder, but its just too fat and overkill for its own good. Don't even get me started on Applets either.)
Simon links to his Tiny API for Markup (TAM) that comes in a 17 KB Java archive file. The kXML 2 parser however is substantially smaller. (~6 KB I believe) kXML a simple pull parser rather then Simon's SAX2-like parser. The next version of MIDP that is in the works, MIDP 2.0, will most likely include an XML parser that I believe may be based on kXML. Additionally the JCP has released or are developing several extension APIs that can be added on an as needed basis -- all in the tens of KB size range.
The uses of XML over expensive slow and unreliable networks is an issue that has not received enough attention in my mind particularly in the area of mobile computing and Web services, a topic I have voiced my reservations about. Jeff Bone has recently been writing about "XML sucking" and in his recent post points to XTalk a "semi-parsed, pseudo-binary representation of an XML" from IBM Labs. WAP employed a similar tact with its WAP Binary XML (WBXML) specification. While attending the Wireless Enterprise Seminar in Atlanta this May, I saw Adam Bosworth present a wireless application framework powered by J2ME using a "binary DOM representation" to communicate to its ultra thin client app. JXTA uses a binary format for its J2ME client, but I'm unsure if it is a tokenized binary representation of XML like the others.
While XML purist probably wince at this ideas, they seem like a reasonable comprise given the constraints of the mobile computing and making XML viable while remaining true to its core principles. I only hope that we settle on one standard method for this encoding.
Recently, the CEO of a well-known software company that's diversifying into mobile applications explained how his developers are having difficulties with the write-once, run-anywhere promise of Java. After writing an application that should supposedly run on any J2ME-based MIDP-compliant (Mobile Information Device Profile) device, his developers discovered that all such devices are not created equal. One device, (Motorola's i85s phone) allowed up to eight characters for labeling the functionality of the device's buttons. A newer device (Motorola's i95cl Color Java phone) only allowed for seven. As a result, the program that worked fine on one device had its button labels truncated on the other. [David Berlind in "Binary compatibility: Holy grail or red herring?"]
Just an FYI for all of you who have not studied with J2ME or just missed it in the fine print-- Sun sanctions, but not encourages, the breaking of write one, run anywhere (WORA) ideal in J2ME. Anyone who has developed for devices know that their feature sets can be vastly different -- even in a single product category like mobile phones. Therefore J2ME is made up of varying device class profiles such as the Mobile Information Device profile (MIDP) for mobile phones and low end PDAs. (Would you want to package Interactive TV APIs in a mobile application?) Sun also allows for OEM specific APIs to be bundled in addition to the standard API in each device class profile such as MIDP. This allows a developer to make choices between compatibility or optimize for the devices capabilities throughout. Device class profiles and OEM APIs are understandable because capturing all of the differing requirements of all devices and make it work in very constrained places would be an exercise in futility.
Its still not binary compatability -- an ideal we strive for, but can never fully achieve. Its also not an "insidious problem" in J2ME, but rather the nature of the device space.
The developers of the nameless company he references used OEM specific APIs by Motorola and suffered the drawbacks of doing so. Shame on them if those developers didn't properly educate their CEO on that point. What is perplexing is that the phones are produced by the same OEM (Motorola) and was poorly designed.
With proper and thoughtful design utilizing a Model-View-Controller (MVC or Model 2) pattern, a certain amount of compatability can be achieved with J2ME code. How much depends on the design and the situation.
Nextel announced it has selected a partner to provide its subscribers with inter-carrier text messaging capabilities. This is significant because Nextel was the last US carrier that not agreed to do so. Inter-network messaging ubquitity is cited as one of the reasons text messaging (SMS) has not seen the adoption in the US that other parts of the world have enjoyed.
Ephrain Schwartz writes about Mobile Telecommunications Radio and Relay or MOTERAN in his weekly InfoWorld column here.
MOTERAN allows any 802.11X or Bluetooth device to act as a relay in passing information to another device towards its destination point. The belief is that this concept will reduce the number of base stations and switches required and thereby lowering the cost of deployment. (Could it improve the quality of service also?) MOTERAN is being developed by Mitsubushi with Detcon (the engineering and consulting affiliate of Deutsche Telecom) who holds the patent.
Its an interesting concept to watch and see what its potential and shortcomings are. What is interesting is how distributed decentralized technologies can be applied to reduce costs, provide better service and perhaps make an otherwise unfeasible idea possible -- not just "destroying the music industry" and chatting with friends and family.
Business 2.0 is featuring a fair article on AT&T Wireless' mMode, the US version of the highly successful Japanese mobile Internet service i-mode offered by NTT DoCoMo. I think they where a bit generous in giving them a C+. I've written up my criticisms of mMode in the past and little seems to have change in the recent months. My grade is a D.
One of my continuing criticisms is that mMode has offers small and independent developers no opportunity or support in leveraging their billion dollar network. It ignores the law of network value -- Metcalfe's Law.
"What remains unclear -- besides the confusing name -- is whether mMode offers anything that consumers would want or need."
Mobile operators lack the background necessary to develop the depth and breath of services needed to attract subscribers. Besides we have calendars, contact lists, news alerts, flight information, and restaurant guides when mobile from any number of existing sources. Attracting a substantial subscriber base will require unique high-value niche applications and services. The only way to possibly achieve this is by leveraging the creativity and entrepreneurial spirit of the developer community at large.
It astounds me that AT&T has ignored this most fundamental of laws. NTT "got it" with i-mode and opened their network and billing system to thousands of independent content services and applications. The i-mode service has been one of the few mobile computing successes. Could the openness of the i-mode service be a key factor? I believe so.
As a follow-up to my post last week I thought I'd point out that last week ZDNet published a special report on Bluetooth. For those of you interested in learning more about the technology these articles are an excellent starting point in addition to those I shared in my previous post. (Except for that tabloid piece from Reuters, of course.)
Here is a follow up to my previous post on this topic. ZDNet ran an opinion piece ("Dick Tracy rides again") on the potential of electronic ink technology.
I've long felt that personal area network (PAN) technology was a good idea that had a place in the marketplace, but I've been discouraged by all of the problems Bluetooth was plagued with and the lack of hardware support. Judging by the press stemming from last week's Bluetooth Congress & Expo 2002 in Amsterdam, the momentum could finally be mounting, but its success is long from assured. Issues of education, implementation, usability have yet to be addressed in addition to developer and user adoption -- the ultimate determining factor.
I think it is absurd to think Bluetooth and Wi-Fi (aka 802.11) are on a "collision course" with each other as this Reuters news article suggests. Besides trying to stir up some non-existent controversy, the article also glosses over the more interesting properties of Bluetooth technology to create personal area ad-hoc networks in favor of its more mundane cord replacement usage.
There are certainly similarities and a bit of overlap between Bluetooth and Wi-Fi, but they are clearly complimentary wireless technologies. Generally speaking, Bluetooth is to peer-to-peer as Wi-Fi is to client-server.
Bluetooth is focused on enabling ad-hoc networks (also called "piconets") of nearby devices in a low powered lightweight low-cost form factor. Unlike infrared beaming made popular by the Palm Pilot, Bluetooth enabled PDAs could transfer files and information without "seeing" each other and at greater distances. More far reaching prototypes include a pen that transfers your writing to a PC. As long as you have two bluetooth enabled devices you can form a network even if its in the middle of desert or on-top of a polar ice cap. (For more in depth technical information on Bluetooth see Embedded.com's "Bluetooth Basics.")
Wi-Fi was designed to provide a wireless alternative to LANs with greater range and capacity (also greater power consumption) by utilizing centralized antennas connected to wired line networks. Interestingly Wi-Fi is also being adapted into a means for community broadband networks and public "hotspots." Irregardless, setting up a Wi-Fi network requires advanced planning and a structured implementation with stationary coverage.
So there is no controversy or "collision course." Bluetooth and Wi-Fi compliment each other by offering contrasting feature sets that enable developers to choose the appropriate means to wireless communication. Though Bluetooth's acceptance is not as assured as Wi-Fi's, I'm hoping the industry moves quickly to establish closer and more seamless ties between the two in the future.
According to CNet a startup named E Ink recently demonstrated a .3 millimeter screen (the thickness of a credit card) using "electronic ink." The method does not require backlighting nor does it require additional power once its image is setup. This could really be useful in designing mobile devices with better battery life. The approximate cost the technology would add to a device was not disclosed. Sadly the technology is not expected to be available on the market till 2005. It would also seem that black and white (perhaps greyscale?) is only supported. I'm a RIM Blackberry user so I don't care really. What I would like are large eletronic ink screens that I can hang on my wall and wirelessly update the images. Then I'd care about color.
Steve Aglin: "I have not doubt that some of Qualcomm's woes come from (supporting BREW), and may have impacted the acceptance and sales of their cell phones in the market place. Perhaps, it's time to consider the adoption of J2ME where there are many more developers, solutions, and application implementations including productivity tools and games for its cell phone users. Just a thought."
Right on Steve.
Incidentally Sun's proclaimation of BREW being flat yesterday had a purpose. Qualcomm was to announce the release for the first major upgrade to BREW later that day.
CNET reports Sun is claiming victory for Java on mobile phones (via J2ME) over Qualcomm's BREW technology in the space.
I recently made similar comments on slashdot.org in a thread on mobile gaming platforms and reposted it here.
The article does not mention another potent advantage of J2ME: it is intended for many types of devices other then mobile phones like BREW. J2ME is not "write once, run everywhere" because of obvious differences in the varying interface, capacity and uses of such a range of devices. A significant amount of code reuse can be achieved if applications are developed properly.
J2ME still has its issues to work out and developing cross-device applications will always have its challenges. Technicalities aside, Sun has developed the right business relationships and models to gain widespread support and allow J2ME flourish. I expect this momentum to continue while BREW struggles and eventually withers on the vine. Its not the superior technology that wins out, its the one that has the widest range support. For instance, Betamax vs. VHS.
There are those who disagree with me, but they can enjoy their every last bit of performance in obscurity.
In response to a slashdot.org post regarding a CNN article mobile gaming and Qualcomm's BREW technology, I made this one of my own:
Many of these types of games and more where being demonstrated on JavaONE this year on J2ME devices so I would get too hung up on BREW. In fact I wouldn't even bother with that technology.
BREW is currently a CDMA only technology. The majority of the world uses GSM thought. (Americans sometimes forget this since CDMA has a larger, but weakening, footprint in the US.) The majority of carriers and handset manufacturers are committed to J2ME in someway. Motorola has gone so far as to pledge that all of its phones will ship with J2ME by the end of this year. Even CDMA carrier Sprint PCS have decided to forego BREW for J2ME [sun.com] when they launch thier new service this August.
If your a developers, where would you put your effort first?
J2ME has its limtiations though. Then again so do these devices -- With a screen not much larger then an airmail stamp we're not even talking game boy here. The limitations of J2ME are currently being addressed with initatives such as Project Monty [sun.com] (a new high performance virtual machine), Mobile Game API [jcp.org] and the Mobile Media API [jcp.org].
Carl Zetie discusses the unresolved issues and hurdles for Web services in mobile application with his article "Don't Hold Your Breath For Mobile Web Services."
I'm glad to finally see this recognized somewhere in the mainstream press. Its been on my mind for months now.
I differ with Zetie in only a few areas:
> I am more pessimistic to whether WSDL and UDDI have a place at all in mobile applications and WANs. Given the low powered nature of most devices in the foreseeable future and the issues of cost and network latency, I believe a less dynamic and more tightly coupled approach to mobile applications will be more appropriate. Dealing with mobile application updates will be marginal given the miniscule file size and the ability to install applications over the air. The ability to process WSDL and UDDI consumes processing power and battery life (a key concerned often overlooked) in addition to adding to the size of the application code.
> I am not as convinced that 3G networks are going to resolve as many issues as many such as Zeite suggest. Perhaps in theory 3G networks will. However carriers are charging subscribers based on bandwidth consumed thereby putting the onus bandwidth conservation on developers. Consideration also needs to be given to the potential worse case scenario of saturated mobile networks.
> I also think more attention could have been paid to the need for asynchronous Web services (messages queued and sent once a connection is available) versus synchronous Web services ("real time" request and response) that are commonly thought of today.
My concern is that the optimism in 3G networks and the more powerful devices will yield less streamlined or even bloated specifications that do not make economic sense and are simply not useful. Stay tuned.
