iPhone App Store: Let's Hope It's Not All Fun and Games

The iPhone phenomenon seems to be a kind of Rorschach test, where you can find whatever you're looking for ...

There are all sorts of posts on data from the App store, looking at, for example, pricepoints in the app catalog, or the kinds of apps available.

These data are far from perfect (though worth a look), and in any case I hope that VentureBeat's post on the prevalence of Game and Entertainment apps turns out to be wrong.

Why? Mobile apps and mobile net usage have been waiting to "break out" in the U.S. for nearly 10 years. It's tempting to agree with the sentiment that mobile net use is reaching critical mass thanks to iPhone, but everyone in the industry has made that mistake many times before.

Successful off-deck software on phones in the U.S. has been more or less limited to games. So when I read the headline "Fun! Nearly half of all the iPhone App Store apps are games or entertainment," all I could think was "let's hope that it doesn't stay that way!"

I have no problem with Super Monkey Ball per se. It's just that if all the top app activity is in games and entertainment, then the mass psychology around the iPhone / App Store ecosystem is in danger of slipping irretrievably in the direction of "diversion" and not the enormous opportunity it really is.

Before you say I should just chill out about the Monkey Ball, consider:

Blackberry, because of its email device pedigree, was pigeonholed as a "corporate email/organizer device" years ago, even though it could do many other things. Despite RIM's attempt to sex up the brand, boost the hardware, cut prices and improve the design, it looks now like the window is closing for RIM to make any big gains. The enormous deployed base of Blackberries never translated into a general platform for mobile net-based computing.

At the moment, all of the top 10 -- and 18 of the top 20 -- paid App Store apps (over the last 24 hours) are Game/Entertainment apps. So right now, when the frenzy is at a peak, with mass media coverage of sold-out stores and consumers showing acquaintances their hot new gadget, the eyeballs are on the Super Monkey Balls.

To a lot of people, who have never seen a 3rd-party app on a phone, and who don't totally get what this is all about, the demonstration is going to look more like a Nintendo DS than a handheld computer.

Which raises a possibility: perhaps Apple was wise to restrict iPhone 1.0 to Safari-based apps, thus forcing consumers to view the device as a mini-web-tablet, rather than as a portable entertainment device.

In Blue Trunks, Skyfire and ISPs; In Red Trunks, Multi-Core CPUs, GPUs, Smartphones, iPhone and Laptops

Skyfire is a mobile browser that has been exhibited at DEMO and has just closed a $13 million B-series funding round (they had received $4.8 million total prior funding). The elevator pitch is that Skyfire brings any web content to the mobile phone, including Flash applications, YouTube videos, Ajax, etc.

I've been trying the Skyfire beta, and I have to say that it's a neat piece of engineering, even if it's just a stripped down VNC-style screen/audio scraping client for a server-side browser session.

But I'm stunned that it has received this level of venture backing.

My surprise isn't because the software is buggy, slow, and has a bad interface on my Samsung Blackjack. Since I'm running a beta in the 0.6 or 0.7 version range, I feel I should be charitable and I'll pretend that all the bugs will be fixed by 1.0, the interface will be great, and it'll run 10x as fast as it does today.

Instead, my surprise is because Skyfire is really about a great periodic function known as "thin client, no, fat client, no, thin client, no, fat client ..." and Skyfire is the epitome of the thin-client position.

Instead of running a browser (which ironically was once considered the thin client, but is now just the universal fat client, consuming hundreds of MB of memory on a desktop to run several Flash or Ajax apps) on a small device, they punted. They'd run the browser in a data center with memory, CPU, and bandwidth, and hand the phone a 2008 equivalent of a green-screen terminal.

This is a losing proposition. For a long time now, all signs have pointed to the fact that fat clients win. And not just because they happen to offer a better user experience (thin-client proponents insist that will change 'someday' although I doubt it).

The economics and technology lean toward the fat client: Although bandwidth has gotten cheaper on an absolute dollars-per-megabit basis,

• Bandwidth has gotten more expensive relative to the speed of "local" hardware buses: USB 2.0, eSATA, PCI-X, 1333MHz memory, gigabit Ethernet etc.
• Bandwidth has gotten more expensive relative to the cost of local computation: a midgrade Intel proc costs the equivalent of a few months of home DSL or cable ISP service, and this equivalent has been stable for a number of years ... and the computational power of that midgrade CPU has gone up severalfold, while the DSL/cable bandwidth has stagnated ... and now is threatened by both metered-pricing and traffic-shaping schemes. On the GPU side, the differential has changed by orders of magnitude to the advantage of the fat client.
• A given "bandwidth experience" has gotten more expensive as users expect to be connected in multiple contexts: To have the same "experience" I have to buy the same bandwidth several times, once for when I'm home, again for when I'm on my cell phone, again when I need to use WiFi somewhere, and maybe a fourth time for a 3G laptop card.
• Cheap powerful computation has innovators, while bandwidth has innovation obstructers.

Sure, raw dollars-per-CPU-cycle and per-kWh can be optimized in a data center somewhere.

But as long as the cost to connect me and that computation dwarfs the inefficiencies of just carrying the computer with me, Skyfire and its investors have bet on the wrong horse.

Whee! AOL Leaps Into the Whirling Saw Blades

You know that cliché about horror movies where the ingénue ends up off by herself in creepy surroundings, and the audience is saying "What are you thinking? Don't go in there!" ?

Well, I'd like to start a MST3K takeoff where the "film" is a tech show off of G4TV or a clip reel from the vlogosphere, and we have, say, a VC, a computer scientist, Ted(!), and a couple o' engineers who have done their time at Initech in the audience.

They could all yell "sure, why not go in there... looks like fun" when someone (like AOL this week) does something colossally foolish, like try and build yet another abstraction platform so everyone can write little apps that run on every cellphone, everywhere, like magic.

AOL says:

"The new open platform will help stimulate innovation by providing developers with ready access to the tools and source code they need to build and distribute applications across all major mobile device platforms and operating systems including BREW, Java, Linux, RIM, Symbian, and Windows Mobile."

Anyone who's ever done anything with cross-platform mobile knows that this is a really hard problem, and not the software kind (where solid R&D might yield results), but the business/social kind, where even the resources of megacorp like AOL are a drop in the ocean.

That's ok, because they have a plan for exactly how it's gonna work. If you're playing along at home, stop reading. Close your eyes and guess the innovative architecture for pulling this rabbit out of the hat. Ok, now you can look:

"The platform will consist of three components:

• an XML-based, next-generation markup language;
• an ultra-lightweight mobile device client;
• and an application server."

I think the secret sauce must be the next generation markup language. See, the next generation markup language will become sentient, take what you write, process it into extraordinarily cogent Powerpoint, email it to all the VPs of all the mobile carriers, device manufacturers, and mobile OS vendors in the world, and then wait on a queue until they all agree to change their businesses so your stuff will work.

I've written lots of times before about the mobile app ecosystem and why, for now anyway, this kind of idea is just a complete non-starter. At least startups fail fast, since they have vaguely limited resources. Then you have players like Yahoo! that find themselves in a deep hole, and say "hmm... this is so big and so deep, we can roll an excavator down here and start the real digging!" They do things like deploy an implementation of J2ME in .net bytecode, so that people can run a mediocre (I'm being polite here, guys) MIDP app on their brand new Blackjack or HTC Touch.

In my new MST3K show, I'll keep the video clips short, so we can watch, laugh, and get on with our lives.

Blackjack / WinMo 6 Upgrade: More Baby Steps Toward Smartphone-as-Computer

I upgraded my Samsung Blackjack to Windows Mobile 6 via the new official ROM, and the upgrade pointed out a few things indicative of where the mobile industry is going.

I was actually surprised that Samsung released the upgrade -- it had been promised for the better part of a year without showing up -- rather than just force customers to buy the new Blackjack II. Eventually I realized why they had gone through with it, and why doing a full-version upgrade (not an update) of the OS on your smartphone will become commonplace: This wasn't done for me. It was done for enterprise customers who bought (or committed to buy, or were thinking of buying) hundreds or thousands of the devices.

Consumers -- especially the kind who buy smartphones -- are interested in getting a new phone every year or two. The whole free-with-contract-extension system helps that keep that flowing.

Businesses, however, buy their handsets differently (often via a more complex deal) and account for the costs of maintaining a "fleet" of mobile devices (management, email, VPN support, etc.) differently as well. For a business, cycling the devices every year or two could well be prohibitive because of the overhead, not just the equipment cost itself.

I've never been tasked with executing a smartphone rollout for a large business. But if I were, I would probably want to create a system where the average device had a lifespan from 2 to 4 years: 2 years for the high-level execs and the techies who need more power, up to 4 years for employees who travel but are not particularly sophisticated or needy when it comes to mobile email. Beyond 4 years or so, the hardware gets so outdated it's not worth the legacy hassle; it's time to buy something new.

So a regimen of solid, easy-to-install full-version OS upgrades becomes a sine qua non for device makers (Samsung) and software companies (Microsoft) who want to sell into the 3-4 year lifespan device market. RIM figured this out a long time ago, and have pushed the envelope when it comes to keeping old models (e.g., Blackberry 7250) alive for years, offering not just OS-level upgrades, but software radio protocol upgrades: an early-model 1xRTT 7250 can become a 3G EV-DO rocket with just a firmware update.

Windows Update ... on Mobile 6

Now, with Windows Mobile 6, Microsoft can also deploy updates to our phones via Windows Update. So they can be more proactive than the hardware maker or the carrier when they need to fix a serious bug or security hole, or release a new feature.

Although other devices have provided updates before, the Windows Mobile Update feature is breaking new ground because the OS runs on so many devices made by so many companies ... and on nearly every carrier on earth. The updates had better not brick too many phones; on the other hand this could be a strategic advantage in the smartphone wars.

Other Stuff

There's lots more to say about WinMo 6 and device evolution ... from Internet Sharing to more Bluetooth support to the GPS "intermediate driver" ... and those were covered well when the OS was initially release.

Android? Give Me a Call When (If?) Phones Go On Sale

In this era of cluetrains, agile, getting real, perpetual beta, and all the rest, I would have thought that FUDly tactics like announcing big game-changing vaporware just to assert your position couldn't be taken seriously.

Not that Google's Android phone software is vapor (you can download it today) -- rather, the proposition of a viable phone ecosystem (devices, carriers, software -- in short, something you can actually use) is vapor.

It pains me to write this. After all, I proposed an platform-oriented MVNO (which Google may become with its possible spectrum bid), and I also stated that, to change the game, Google should support J2SE (and more), which Android does. And Google's challenging the carriers, who are the big problem in wireless software.

But I gotta call it like I see it, and announcing a big platform initiative when the first real handsets are at least a year away is a movie I've seen before.

There's an ALP announcement like this every six months; Palm announced the mythical Cobalt (with SDK!) over and over; Motorola made a big deal about its Linux phones. To be fair, Moto does ship a number of phones running Linux under the hood. But they're not really open, and neither developers nor consumers have taken much note. In early 2006 we were told MIDP 3 devices would be shipping by, er, now. Oh, and Sun's magic wand is going to bring us JavaFX mobile devices.

It's old-school (bad!) tech marketing at its worst. At best, these announcements need a bogo-coefficient to convert, say, "Just 12 months away!" to "Just 36 months away!" ... but really it's best not to believe in anything you can't buy at your local Sprint store.

Producing the SDK for public consumption now is not necessary to provide development lead time (how long did it take developers to build apps for the iPhone?). Plus freezing APIs now just makes it that much harder to alter the them when unforeseen issues crop up closer to mass production.

Although Apple is famous for taking a haughty approach toward their developers and customers, there is something to be said for putting the hardware and carrier together first, releasing the phone second, and then when you see what people really want to do with it, release an official SDK to help them.

I wish Google the best of luck with 700MHz, the carriers, the handset makers, the FCC, and the public. I'm just not sure this is off to an auspicious start.

Gratuitous Post: Gmail + IMAP = Sweeeeeeet

Ok, this is neither news nor particularly clever-monkey opinion writing.

But Gmail has been opening up full IMAP access on accounts, and it is truly a beautiful thing. Web mail is fine when it's all you've got, but whether it's stripped down (Gmail, old Yahoo! interface, etc.) or supa-deluxe JavaScript (new Yahoo!, Hotmail, er, I mean Windows Live) it can't beat the smart client.

And email clients are the original smart client: rich client with offline capabilities + access to network resources.

I'll still use the Gmail web interface sometimes, so it's not like Google won't get a chance to present me with plenty of ads, but having access from Outlook and especially Outlook Mobile on my Windows smartphone (sorry, guys, it just works better than the J2ME Gmail client) is absolutely killer.

I didn't think the free-online-email game was going to change a whole lot at this point, but this is a game-changing move by Google.

Writing Javascript on a Phone, on a Phone

I'm on vacation, so I'm writing some less, um, in-depth posts. Hopefully. Like this one:

I've gotten bored waiting in lines, on airplanes, etc., and I thought it would be a fun way to waste time if I could program my phone.

I wanted to be able to do it without a PC, just with the phone itself. And I didn't want to do it over the network (i.e., edit some code, send it off to a web page or network app to compile, run, etc., and return results, even thought that could be a fun way to tinker when you're on a good connection).

I thought there must be some kind of compiler or interpreter for my Blackberry or, now, Blackjack. And yes, I know, if I had a real Linux phone, then I could just download any tools I wanted. But Linux smartphones with QWERTY keyboards are hard to come by.

Enter Javascript.

I used to hate Javascript. A whole lot. Then I watched Douglas Crockford's fabulous lectures on Javascript, and it turned my whole attitude around. I realized I had never understood what Javascript was about in the first place. And here was a really smart guy who knew all of the problems, and didn't say "get over it," but talked about finessing your way to the true nature of Javascript. Which, incidentally, are lambda expressions. Crockford asserts that Javascript is more or less the only "lambda language" to organically receive mainstream adoption in the development industry.

Now I only hate the browser hosting environment for Javascript. And with enough plug-ins, even that isn't so bad.

Since Pocket IE has Javascript support, and I can edit text files and save them on my phone, I can build up a library of the functions that do what I want, and this library becomes the web page that I run and hack in with PIE. This is where having a real smartphone, not a crippled one whose manufacturer tries to deny me access to the local filesystem, is helpful.

Goofy? Kinda. But it keeps me out of trouble.

Lifecasting will be Prevalent, and has a Down-To-Earth Future

Lifecasting is one of those things that is interesting on a theoretical, academic, political, and artistic level. Yet, right now, it's pretty boring in "real life."

But there is a big bourgeois, commercial opportunity coming for lifecasting, and with that will come low prices, ubiquity, and all sorts of new content also relevant to the avant-garde. In the same way that cellphone cameras now catch politicians off guard and police beating protesters, the surveillance (sousveillance?) society will take a quantum leap forward.

Walgreen's sells a low-end USB web cam for $14.99 today, and for well under $100 one can get a higher-end unit. I predict that in 2-5 years, I'll be able to drop $40 in Walgreen's and get a wearable cam/mic with an 8-ounce belt-clip battery that will plug in to my cell phone ... and I'm in the game with justin.tv.

This is not live-without-a-net futurism here, either. I'm making a modest argument by extrapolation on the hardware side. The original justin.tv rig was a hassle to put together with today's technology. The biggest challenges involved upstream mobile bandwidth, battery power, and data compression.

With EVDO Rev B, HSUPA, and WiMAX, bandwidth looks to be less of a problem than giving customers a reason to buy it. As MPEG-2 fades away in favor of MPEG-4 flavors like H.264 and 3GP, cheap hardware compression is already becoming less of an issue. In fact, many of today's low-end smartphones are most of the way there in terms of a basic lifecasting rig. Battery power will remain an issue for anyone wanting to go live 24/7. But for a few hours at a time, several ounces of lithium-ion will keep the camera, compressor, and radio humming.

So what are the bourgeois, commercial applications?

• Conferences: organizers won't love broadcasts of the content, but, at least in tech, they are desperate to find some way to keep the shows compelling. I can see a lot of organizations sending one delegate to lifecast while others back home watch and interact, including talking to vendors, visiting hospitality suites, etc.
• Meetings: an interactive lifecast of a remote meeting would be a more productive way to participate than just a conference call or even a traditional web/videoconference.
• Social events: suppose your school reunion is far away and not nearly exciting enough to make the trek. But a friend who lives in the area goes, and you can ride along via lifecast? That could be a riot. And if it isn't, just close the browser.
• Education: how cool would it be sit in on some virtual flight lessons, tuned in to a lifecast from a CFI giving a real student a real lesson.
• Remote Personal Assistant: Instead of a worrying about wearable computers with smarts, you go about your business while a remote assistant tracks your lifecast. Need directions? a pickup line? a reservation? instant info on anything? Your assistant, sitting somewhere comfortable with easy access to all things cyber can do the virtual legwork and send you what you need in real time.

The monetization platform is already here, as early adopters have jumped out ahead. Phone hardware (which will serve as the workhorse for the system, just as it does now for millions of phone-cam snapshots, videos, and mms messages) is moving at a rapid pace. That just leaves a few more parts to design and sell to complete the picture. With the amounts of VC money flowing today, I don't see that last part as a problem.

Sun CTO: JavaFX Mobile Stack Aims to Clean up J2ME Disaster^H^H^H^H^H^H^H^H Issues

It's only mild hyperbole to call J2ME a disaster. If you've depended on ME to make a profit, it might not be hyperbole at all.

But good news may be somewhere in the pipeline. This morning I heard Sun CTO Robert Brewin speak at AJAXWorld. His talk largely concerned enterprise services, but when he mentioned that one argument in favor of Java is its ubiquity, and that Java runs on about two billion phones, I couldn't help but stand up and ask for the mic.

Since Robert was ready to acknowledge the existing hassles, my question was: does Sun plan to fix it -- e.g., by becoming more stringent about how devices are certified as Java-capable?

In his response, he punted on the J2ME aspect, suggesting developer could put pressure on device manufacturers to standardize their Java behavior. Since cellphone carriers are players in the equation, I'm awfully skeptical about that. But the cool part was that Mr. Brewin said that the place where Sun plans to really make an impact here is with JavaFX Mobile.

Since JavaFX Mobile, adapted from the Savaje Java-based OS acquired by Sun, is a full kernel-to-app stack, it should provide much better -- perhaps even 100% -- compatibility between devices.

Now let's keep our fingers crossed for full J2SE support on it.

The Google Phone Should (Will?) Run Your Regular Java SE Apps

Om's rundown of supposed Google-phone details was picked up today by engadget mobile. If the rumors are on target, and the phone is really based on a Java-on-Linux OS, with a Java API for apps, then I have one thing to say. And hopefully all those PhDs at Google thought of this a year ago.

Wanna make be a real disrupter in the smartphone world, not just a me-too? Java SE.

Here's why it makes so much sense that Google's probably already done it:

• Sun bought SavaJe in April
• Sun's JavaFX mobile is based on the SavaJe tech
• Google can get help from Sun on this Java-based OS (similar to what RIM built on their own)
• But, being Google, they're in a position to ask for full J2SE support...
• ...which exists, performs well, and which Sun can now provide, because SavaJe built and owns it! (even though they later focused more on a J2ME++++ approach)

Google and Sun can ship the device with a J2ME environment layer (similar to the J2ME-in-an-applet environments that exist online), and probably the JavaFX mobile layer too. But allowing anyone to crank up plain old Java code (of which Google already has quite a lot) on the phone would be a game-changing move.

When Building a Smartphone App, Resist the Siren Song of J2ME

I'm tempted to comment a bunch on the Yahoo! Go smartphone app with its secret J2ME porting layer. But I just don't have enough of the business context around the project to draw solid conclusions. So I'll spare you the half-bakery and instead share something that you can use.

If you're building a mobile productivity app, think realistically about who your principal user personas are. If your user is on a Windows Mobile phone, a Blackberry, or a Symbian-based smartphone, don't even think about writing a J2ME app. Just don't. If you haven't been down this road, you're probably thinking, "Of course I wouldn't do that.. why do think I would?"

Here's why, sooner or later, you're going to be tempted to do it. And if you're not, another project stakeholder will, and you're going to have to talk him or her out of it. The argument is going to go like this:

1. The J2ME / MIDP platform offers a lot of functionality (graphics, networking, threading, PIM integration)
2. The vast majority of phones support J2ME, even ones that also offer an OS-level API, like Symbian or Windows Mobile
3. Therefore, if an app is built on J2ME/MIDP, it will have an enormously larger potential market size in terms of device compatibility. Like an order of magnitude (or more) larger. And, heck, it's easier to write one app than a whole pile of them, right?

The problem is not that you're going to be have to do a lot of adaptation, since no two J2ME implementations do the same thing. Although it's something to keep in mind.

The real problem is that if your customer is a smartphone user, the J2ME app is going to stink. It will be clunky, trouble-prone, and will not match the level of user experience that the user is accustomed to on their device. Compared to the native apps on the device, yours will be the "weird" one that somehow just doesn't work quite right. (Incidentally, this is exactly how Yahoo! Go looks next to the couple dozen native Windows apps on my Blackjack.) So just when you think you've got a killer app figured out for mobile, you're guaranteeing it won't be.

And you're not really going to attract those hundreds of millions of J2ME-capable feature-phone-users because they weren't your target in the first place. Not to mention, those users generally don't understand how to install apps on their devices, don't have unlimited data plans, and don't understand how incremental data charges work on their plan, so they are terrified of the cost of using networked apps.

Bottom line: it sounds cliche, but know your market and build what they want to use.  Build a Blackberry app for your Blackberry users and a Windows app for your Windows users. It's easier than building hacked-up J2ME apps. It's enormously easier to test and support, because those operating system APIs you're using are actually tested and supported (unlike J2ME). And if you're secretly nervous that there aren't enough customers on these platforms to support your business plan, admit it now and make some adjustments before you write a line of code.

Now You Can Start Porting All Your Killer J2ME Apps to .Net CF

Yes, that's a joke.

After discovering the J2ME implementation shipped with Yahoo! Go's Windows Smartphone implementation, I felt compelled to take one more little step and make sure that you could actually build and deploy your own (or someone else's) MIDlets on the framework.

So I grabbed ye olde Hello World MIDlet which -- at one point anyway -- was part of a Sun tutorial on MIDP 1.0 programming, and wanted to see if I could get it to run on the javaxnet10 layer. Purely for research purposes, of course, because deploying other apps against the Y!Go runtime is likely against the EULA/license.

This exercise turned out to be pretty trivial, and it goes like this:

1. Create a new C# Smartphone project in Visual Studio (VS). Using J# would obviate a lot of small C#/Java syntax changes, but by default J# isn't supported for "smart device" projects. In theory it should be fairly easy to flip compiler switches and get it working (it's all IL, after all), but the fastest route for me to try this out was with C#.
   
2. Make a lib folder and bring in the javaxnet10.dll, platfom.dll, and interop.dll libs from a Windows Mobile distro of Y!Go. As of today, all of the available Windows Mobile devices are ARM-based (as is the MS Smartphone emulator), so you'll have an ARM interop.dll, which is fine.
   
3. In VS, add references to javaxnet10.dll and platform.dll. Add interop.dll as an "existing item" and mark it to be copied through into the output directory for your app.
   
4. Delete the Program class that VS generates (which has the Smartphone app entry point) and the Form1 class (MIDP handles the display; you won't be using System.Windows.Forms directly).
   
5. Add in the Hello World (or other) MIDlet class, and perform C#-ification. (C# is explicit about virtual/override, string and bool vs. String and boolean, etc.)
   
6. Add a .Net-suitable entry point. I used the following code, which is taken from the decompiled Main entry point in Yahoo! Go:
   
   private static void Main()
   {
              MIDlet midlet = new HelloWorld();
              MIDlet.Start(midlet);
   }
   
   
7. Click "debug" to do a build-deploy-run. If this is the first .Net CF app you're debugging on this emulator image, be patient -- it takes a little while for VS to deploy the compact framework to the device. My HelloWorld C# MIDlet source produces this output:
   
   

   

 

Ok... so we have the ability to import MIDlet code and run it in on the .Net compact framework runtime. Pretty cool.

If we wanted to try this with a real J2ME codebase, we'd almost certainly want to build it with the jsc, the Visual J# compiler, or else run it through a Java-C# syntax conversion tool, so as to avoid creating a entire C# variant of the code.

I'm still curious where this J2ME implementation came from (I'm about to shoot an email off to Jeremy Zawodny with Yahoo's developer group / dev relations to ask) ... If it's not an in-house creation, my best guess would be the mobile game industry, since that's the one area where MIDP apps have been successful enough that it would be worth the investment to be able to sell them on Windows phones.

And I still plan to comment on what this all means in terms of an architecture choice for Yahoo! Go ... (and no, the last post about NIH and crackpots was not the promised commentary about it).

Reverse Engineering: Finding the (Not So) Secrets of javaxnet10.dll

When I was restoring my Blackjack from backup last week, I noticed a file with an interesting name in the Yahoo! Go application folder: javaxnet10.dll

Eh? ... some kind of Java library? or a JVM? or maybe just a Microsoft runtime DLL for using J# with the .Net Compact Framework? Running J2ME apps on .Net CF would be a kind of cool... Ok, off to Google. A Google search for "javaxnet10" (over the web and newsgroup archive) produces several links to this single discussion thread where someone speculates on this exact question.

So I did some research. I'll save my conclusions and speculation for my next post; here, I'll tell you how I did my 10-minute analysis of this app. Old news to Win32 developers, but I think there may be a few .net/mobile/Web2.0 devs out there that might find this useful.

First, I used ActiveSync to pull all the DLLs and EXE for Y!Go off of my phone and onto my desktop. Then I right-clicked on the files to see if there was any metadata I could view that way. There was nothing -- either because it wasn't published, or it was removed at some point.

So I opened up a Visual Studio command prompt and cranked up dumpbin.exe. Dumpbin is a command-line PE format file processor. Since Windows Mobile is built on Windows CE and uses PE format for binaries, dumpbin doesn't care that these files are for a phone with an ARM processor rather than a desktop with an x86. Dumpbin will tell you which libraries a file loads, what it exports for other files to use, and all kinds of other fun stuff, including disassembly and -- get this -- it will disassemble an ARM binary into ARM assembly (the register names are the giveaway). I wonder how many instruction sets it understands?

But that's not relevant here because javaxnet10.dll is not a native code library at all.

It's a .Net assembly. How do I know? It reports a single import of mscoree.dll. mscoree.dll, short for "Microsoft component object runtime execution engine" is the .Net virtual machine. Or, as Don Box more poetically put it, "mscoree is the last COM DLL." He meant that metaphorically, not literally, of course. "mscorlib," he continued, "is the first .Net DLL," since that's the base library that mscoree loads to do anything useful.

Ok, let's look at all the files from Y!Go and see how they break down: javaxnet10.dll is .net, platform.dll is .net, ygonet.exe is .net, interop.dll is native (it imports a handful of OS binaries, and not the .net runtime -- try dumpbin /dependents to see).

So this is looking like a .Net CF app, with a native interop helper library for things that are hard or impossible to do with .Net CF. But we still haven't answered the question of what javaxnet10.dll is about.

Since it's a .Net assembly, we can bring in the magical MRI machine of dot-net, Lutz Roeder's .NET Reflector. This tool is an amazing free application that allows you to fully explore the insides of a .Net assembly, from the class-and-namespace level down to full decompilation. And, since .Net IL is much richer in metadata than native assembly, the decompilation produces intelligible code in the .Net language of your choice!

Point the .NET Reflector at javaxnet10.dll, and the mystery is revealed: it's an implementation of most (maybe all) of the J2ME and MIDP APIs. It does not run Java bytecode (it's not a JVM, interpreter, or cross compiler). Instead, it implements Java platform interfaces the way WINE implements Windows APIs. Here's a screenshot... the namespaces read like a tour of the MIDP API.

Just to confirm our understanding, we can basically browse the source of the whole application, and see the use of Java types and patterns everywhere. For example, StringBuffer is the classic Java equivalent of .Net's System.Text.StringBuilder. Although the waters have been muddied with the recent introduction of a Java class called StringBuilder, J2ME/MIDP predates that API by years. Which is to say, if the app were being written in a .Net CF style, we would see StringBuilder in high-level functions even if Java libraries were leveraged down below. In a Java mobile style, we'd see StringBuffer. The fact the we see StringBuffer (and many similar cases) argues that, in fact, this is basically a Java app. Heck, com.yahoo.go.app.YGo extends javax.microedition.midlet.MIDlet.

'Nuff said. Next time, we'll talk about the significance or usefulness of our discoveries, and where javaxnet10.dll might have come from.

Minimo and Blackjack: Destruction, Repair

On my Blackjack phone, I use Pocket IE, Opera, and the pseudo browsers in Yahoo! Go and Windows Live Search for Mobile. But none of them deliver the Firefox-level experience I really want. So today I grabbed the latest build of Minimo, a Windows Mobile build of Mozilla that has been in development for a few years now. I installed it, it started, it stopped, it completely trashed my Blackjack smartphone. Ouch.

I'm not complaining about Minimo, since it's a 0.2 product, it's open source, and I'm thankful folks write software and give it away as early as possible. Stuff happens, especially when it's v. 0.2 and mobile (since true smartphones give the user full power over the device and there is rarely a root vs. user privilege distinction).

Instead, I figured I'd share the symptom and the solution.

Symptom: After rebooting, the home screen was missing graphics, the Start Menu was empty, and the whole device was relatively non functional.

After freaking out for a moment or two, I plugged in my ActiveSync cable and opened the device file explorer from my desktop. The filesystem seemed mostly ok. The biggest problem I immediately saw was that, in the Windows directory, all of the folders were gone. Bad for Windows. But not so bad for me, since the rest of my data looked to be still there.

Fix:

Step 1. Make a folder on my desktop, and copy off My Documents, My Pictures, etc. from the Blackjack.

Step 2. Copy off interesting folders in the Application Data folder from my device to the backup folder. In my case, this was a Google Maps for Mobile data folder.

Step 3. Copy off application folders from under the Program Files folder. Actually, I could have skipped this step and installed the software anew. Moreover, there's no guarantee that copying an application folder ("xcopy deployment") will work. But many mobile apps play nice and keep all the necessary binaries in their folder. Some of these same ones also play not-so-nice and put configuration data in their app folder too. Ideally this should go in a data folder (like under Application Data) or user settings folder. But it doesn't always work that way, and I wanted to preserve this data if possible. So... grab the app folder for things like Yahoo! Go, Live Search, etc.

Step 4. Factory reset! Unhook from PC. Power off the Blackjack. Holder the "up direction" on the directional pad while powering back on. Answer the prompts indicating you do want to format (the flash memory).

Step 5. Wait a few moments, and you're looking at the baby fresh Blackjack that greeted you when you first took it out of the box.

Step 6. Plug it back into your PC. If you use Exchange ActiveSync and/or DirectPush, enter your account and password data. The phone will sync and all of your contacts, calendar, mail, etc. will automagically re-appear on your phone.

Step 7. Copy the stuff from steps 1, 2, and 3 back onto the device in the appropriate locations.

Step 8. Reinstall any OS extensions that you need, such as the .Net Framework. In particular, the Blackjack doesn't ship with .Net Compact Framework v. 2. So if you use any software that depends on .Net CF2 it, you'll need to reinstall it. Easily enough done.

Step 9. Adjust device settings the way you like -- things like sound profiles, choice of home screen, and which app lives under the right-side-soft-key.

All in all, only a minor hassle.

Here's a vaguely clever idea in parting: Microsoft should provide an API (as part of the Pocket Outlook / Exchange Sync services) that lets apps store their data (and backup images of themselves) with a mechanism that syncs to storage on the Exchange Server. Maybe with some kind of unified store API like Core Data. Preferably with versioning.

This would be good for Microsoft, because it would be a great phone feature and a great way to sell Server and Exchange licenses, and maybe even work SQL Server and SQL Server CE. It would be great for the end user (me) because if things go badly, I can wipe my phone, re-create my pairing to the Exchange server and -- just like my contacts and mail -- all of my apps and config data would show up.

Yahoo! Go: Nice Product, Sorry Testimony to the Horrific State of Mobile Dev Standards

I finally got my Yahoo! Go on this week, when the client for my Samsung Blackjack became available. I had been watching this project because it's one of the more ambitious mobile initiatives in a long time. You wouldn't know from the press coverage, but that's because it's in the middle of the land of purple, a giant doing everything and nothing, well and badly, all at the same time.

Let's pass over Y! Go's features and design for a sec. In terms of software architecture, we're looking at a smart client app: its content and features are network-oriented (mail, flickr, search), but it also runs offline, saves stuff locally to make that work, and masks fluctuating data rates and request latency under a locally controlled UI.

It's effectively got an embedded web browser (although it looks like page transcoding is happening on the server side, to save bandwidth and reduce complexity on the phone) and server-side support for viewing PDF, Microsoft Office documents, HTML email, etc. This strategy is a lot like the Blackberry's server-side translation, with the exception that Yahoo's actually works.

So Yahoo has basically built a 1990s-era AOL client, a monolithic app that provides a controlled experience and mediates access to the Internet. And they've built it on at least four platforms (Windows Mobile, Symbian, J2ME BlackberryOS, J2ME/MIDP vanilla) with countless versions and quirks. Which is why even versions for "similar" phones have trickled out over the course of months.

Why would Yahoo do an AOL? Because they want to take over the world with their platform, and control where users go? Nope. They did it because they didn't have a whole lot of choice. The phone development platforms remain extraordinarily fragmented across OS, API, version, and hardware install (!), and the carriers are more of a hindrance than a help. The worst part is that within six months there will be enough new devices and OS changes that the entire QA cycle and maybe even dev will have to be at full throttle just to keep this app viable.

Most likely, the original mission was to bring Yahoo to mobiles in a more consistent and usable way than the old mobile web site. And most likely they looked at mobile web options before realizing that those would require nearly as much customization for different devices as rolling their own app (plus mobile web would lack critical offline/low-data-rate functionality). So they did what everyone has to do: build their own native application to serve as platform and abstraction layer over the other APIs.

Who wins in this scenario? It's not the Yahoos, Microsofts, or Googles, who would rather not rebuild, test, and maintain the same app over and over. It's not startups, who kill themselves trying what only GYM can really afford to do. It's not the carriers, who want to increase revenue per sub by selling data plans, and who need compelling network-intensive apps to do that. And it's probably not the hardware folks, who don't care too much what's happening four levels up the software stack.

No one wins this game of 52 Pickup. It creates "small value" in the short term, while stifling "big value" in the long term, the same way a tornado wrecking a town brings a bunch of contracting and insurance dollars in the short term, but doesn't make the town a creator of value in the long term, the way building infrastructure like fiber-to-the-curb, or a decent university extension campus might.

I built a push-mail system in Perl in 1998, the same year RIM started shipping the precursor to the Blackberry, and I started reading my Yahoo mail on my phone in 2000 via WAP. So we're nearly at 10 years of mobile productivity apps and the trend is still toward more chaos rather than less. So... how can we reign this in, hopefully still preserving some biodiversity in phone DNA at the same time?

Microsoft to Turn Your Windows Mobile 6 Phone into a Sideshow Device

Gadgets on the desktop are a little gimmicky ... But gadgets on ... gadgets are a lot cooler.

I love Windows Sideshow, the technology that gives lets you browse and control your media right on your remote or digital picture frame, or read your email on a watch or a digital fridge magnet -- even (especially!) when the "media" or "mail" apps are really running on your PC and your PC is powered down!

But I don't run Vista on my laptop (a post for another time). And anyway, I don't have any Sideshow compatible devices.

I find myself simulating Sideshow though, with my Windows smartphone: typically email pops up on the phone (via DirectPush) before it gets to my desktop. So I monitor my email on my phone, even when I'm at my desk. It's great to have that extra screen on the phone, so I don't need to bring up Outlook when I'm coding. Same thing with calendar items, contacts, and my notebarn list o' lists. The phone is always more "up-to-date" than desktop Outlook.

Admittedly, though, this isn't the full Sideshow experience.

So I was psyched to come across this thread where Microsoft contributor Dan Polivy writes

"Windows SideShow support is not built in to Windows Mobile 6, but we will be
releasing an application which will enable your WM6 device to work as a
Windows SideShow-enabled device. It's a software-only addition, assuming
your device already has a Bluetooth radio in it. Stay tuned for more
information; our current release target is the 3Q of this year."

This move is a brilliant way to tap into a ready-made pool of millions of powerful devices and enthusiastic users.

Sideshow is only supported on Vista, not XP ... but if I can get Vista in VMWare to see my Bluetooth radio, I might be cooking with gas...

Building the "Not Real" Internet: an On-line WYSIWYG Mobile Site Builder

The iPhone's browser renders the "real Internet" (after sucking the data through a pipette, and assuming your Internet doesn't include Flash applications). But notwithstanding the iPhone, it's a safe bet that making your application or data accessible to phones will involve publishing some kind limited type of html, xhtml, chtml, wml, etc. Probably all of them, using an adaptive rendering mechanism.

To take some of the alphabet soup out of casual mobile site creation, Sprint is promoting a free on-line wysiwyg mobile site builder, powered by mobiSiteGalore.

This page composer loads slowly and doesn't impress at first glance. But wait … keep going… it’s got templates ... AJAX editing ... limited forms support … an image resizer … a page hit counter … 1-click SEO-er-izer ... and automagic versioning with the ability to easily rollback to an earlier version.

In addition, there's a "wizard” that lets you add useful pseudo-widgets to mobile pages with one click -- things like launching a phone call from the browser, getting driving directions, viewing audio/video clips, even making payments via bango.

Then it generates slick reports (by ready.mobi) on how compliant the resultant site is, including running it in multiple emulators right in the online report.

Finally, there’s an integrated publishing workflow, where you can check your work and publish to your own site, publish to a free site provided (yourname.websiteforever.mobi – which is prolly a bit much to type on a phone!), or download your files. For complex sites with any kind of application functionality, you'd probably have to employ this last function and add use that output as template material for your ASP.net, PHP, etc.

If you are too lazy to press any buttons, there’s a demo movie.

Sprint and mobiSiteGalore call this “the world's first standards compliant mobile website design tool” with a “Guaranteed test score of 5/5 on MobiReady Report” that is based on w3c standards.

Which is nice. Now if only the mobile phone browsers were standards compliant too …

Pac-Man on your Smartphone? Ghosts are Chasing Your Game Download

Remember Bad Idea Jeans? That's what came to mind after TechCrunch told me Namco is releasing classic arcade games for AT&T smartphones, and I checked it out.

Pac-Man on my Blackjack is not a bad idea at all. But here's the ordering page:

Notice you can choose how many copies you want to but, but not whether you want "Download Protection" ... Interesting .. My downloads have never been injured before. I wonder why I need protection? If you click the protection link, you get this popup:

This is obnoxious on so many levels. And no, I'm not complaining about the money. The problems are these:

First, the market for off-deck software for mobile devices is in its infancy. While the general population is slowly realizing that the phone is a computer and can run programs (if the iPhone does nothing else, its TV spots will help communicate this fact), most folks have still never installed an off-deck app, let alone paid for one.

The smartphone users are at the vanguard, the evangelists that get their friends and companies onto mobile apps. So why even suggest that the software downloads are any different from a PC software download? Why suggest there's some special problem with mobile software, so you'd better pay $3 for "insurance" in case your stuff gets screwed up?

At this market's stage of maturity, users need to be told that if they're ready to start buying mobile apps, there is no risk, and the vendor will do 100% whatever it takes to make sure the software is available in case a device gets broken, hard reset, etc. Compare the early days of e-commerce: a number of companies promised extraordinary customer service to overcome anxieties about returns, using credit cards online, etc.

The second problem is that it undermines the whole idea of software sales as IP licenses. If I've bought a permanent license to Pac-Man for my device, why does it cost $3 to make sure I can download it again later? Is the $14.99 for a conditional license, that only gives me the right to use the app until such time as my device gets reset? Then $3 buys me a permanent license? Of course this is absurd.

Bottom line: if Namco want another $3, just call it a handling fee, or a one-time provisioning fee, or just toss it into the price. My downloads don't need protection.

Notebarn: Launching URLs and International Phone Numbers (Includes Crash Couse in Numeric Regular Expressions)

A lot of visitors to this blog and the Notebarn project page (where you can download the app) are from outside North America, and all of those folks got a raw deal from my last update.

I added the ability to dial numbers from a note, but the phone number recognition was based on a hard-coded pattern that looks like a North American phone number (basically, 10 digits with some optional delimiters).

So I've got an update that moves the phone number recognition out to a configuration file, where you can put in a localized phone number pattern.

I also found it really frustrating to put a URL in a note and then have to key it in later to browse. So this update recognizes URLs in notes and lets you launch them just like dialing a phone number from a note.

URLs / web browsing works straight out of the box. For localized phone numbers there's, um, a small catch.

The Catch

I did not set up a list of international phone number patterns. So, in this release, if you're outside North America, you'll need to add your own phone number pattern to the config file. Here's how it works:

1. Install the new Notebarn with the latest OTA installer. The install will place a config file called notebarn.config.txt in the Program Files/Notebarn directory on your device, right alongside the executable.
2. If you have a regular text editor on your device you can edit the file in place and skip to step 3. Otherwise, use ActiveSync to grab the file, pull it over to your PC, and edit it there (with an editor like Notepad). When you're done you can push it back to the device with the changes.
3. In the config file you will see two lines like this:
   

   #Add a RegEx for your localized phone number format here:

   PHONE=\d{3}\D{0,2}\d{3}\D?\d{4}\D
   

The beast on the right is called a regular expression, and your .net-enabled Smartphone has a great engine for processing them. Microsoft has docs on the format. But you don't need to read all that. The cheatsheet for phone number patterns works like this: \d means a digit. \d{3} means exactly 3 digits in a row. \D means a non-digit. Specifying non-digits is how you look for delimiters used between groups of numbers, like a period, space, dash, parens, etc. And \D{0,2} means anywhere from 0 to 2 non-digits in a row. The \D? is shorthand for \D{0,1}, or "zero or one non-digit."

So all together, the North American pattern above means 3 digits (the "area code") followed by 0, 1, or 2 non digits (think of 415-555-1212 or (415) 555-1212), then 3 digits, optionally a nondigit, 4 more digits, and a non-digit to mark the end. How does the phone dial if we've recognized an extra non-digit at the end? Well, the phone app in Windows Mobile is smart enough to drop the non-digit parts of the phone number when it dials.

If you put together an expression for your locale (or borrow one from another program), feel free to email me or post it in the comments. In the next release I'll include all of them in the config file to make it easier to set up.

Notebarn Update: Dial Phone Numbers from Notes

Once I gut a bunch of phone numbers in my Notebarn notepad, I started getting frustrated that I couldn't dial a phone number in a note just by viewing the note and clicking on the number. So I've updated the app to include this capability.

If you want this feature, and don't want to read any more geek ramblings, you can go right to the project page and download the app.

I missed this feature acutely because I used to use a Blackberry. On the Blackberry, whenever you come across an email address, URL, or phone number, the device recognizes the format of the text and creates a sort of smart tag. The trackwheel menu gets new tasks related to the data. If you move the cursor over a phone number, the wheel menu will include Call, Send SMS, and, if the number is recognized as matching someone in your address book, clever things like "Send an email to [name]", "Invite to meeting", etc.

It's not accidental that most Blackberry apps support this functionality: the folks at RIM supply classes in their platform API (net.rim.device.api.ui.component.ActiveRichTextField and net.rim.device.api.ui.component.ActiveAutoTextEditField to be specific) that do pretty much all the work for you. Use these classes, and you get this functionality for free.

Despite many strengths relative to the Blackberry platform, the .Net Compact Framework on Windows does not include such a class (at least as of 2.0).

Making this kind of an implementation harder, the Smartphone version of a multiline textbox has a "clever feature": In order to allow multiline textboxes to fit nicely onto a small screen, play nice with directional tabbing, and still accept a lot of text, they have two states. The base state shows one line of text and a little "expand" triangle. You can edit the text, the control responds to events, etc. If you click "Enter", triggering the expansion, the textbox switches into a fullscreen state where you can put in all the text you like.

The problem is that in fullscreen mode the component does not respond to all of its events (it doesn't even fire an event when switching modes), making it very hard to do context-sensitive stuff, such as "look at where the cursor is, extract the nearby phone number, and allow the user to dial it." Which is what I really wanted to do.

I implemented two workarounds instead. When notebarn finds one phone number in the note (using a RegEx that looks like a U.S. number), it adds a "Dial 415-555-1212" command to the main app menu. If there are multiple numbers, it opens a new window with a list showing each number and some of the context around it (so you can tell which number is which). Pick the one you want, and click to dial.

Happy calling!