Or is it?  I was seriously hoping to break the megabit barrier with this, but it doesn’t look to be true:

The card operates on the current Sprint Power Vision Network and will support faster average download and upload speeds (450 -850 kbps and 300 - 400 kbps, respectively) of Sprint’s upgraded network when it becomes available. 

So not only does it not break the barrier, but the network isn’t there to use it yet.  OK, OK… False alarm.  Go back to what you were doing.

Anyone going to be out at the Mobile Monday LA CTIA Mixer?

It’s sad that I’m not in LA much anymore, so I don’t get to go to these things.  But AdHoc will have a few people there so say hi if you see them.

Mario has done a great job resurrecting Mobile Monday LA from the slumber it has been in.  I’m glad to have been part of it when it first started, and even happier that it’s continuing on so well now.

Update:  Looks like AdHoc might be flying me out there for some meetings we have.  So I’ll post again when I know what functions I’ll be attending.

Update2:  It’s confirmed.  I’ll be at the MoMoLA CTIA Mixer!  Let me know if you’ll be there and want to hook up.

I’ve said many times in the past that I think MMS is going to drop out of the equation in favor of email.  It’s just the carriers’ need to keep control over content that keeps it alive.

Dean Bubley wrote a nice commentary on what seems to be a marketing spin piece on MMS - trying to turn very kinda sorta increasing trend numbers into a success.

Verizon’s one of the leaders, at 62m per quarter (ie 21m per month), while another big advocate Telecom Italia Mobile made a grand total of €49m from MMS in 2005. Scaling that up means MMS is (optimistically) a $2bn business in 2006. Yeah, great success, given a cumulative investment of the order of $20bn+

Let’s say you want to develop a proof of concept streaming mobile video app.  We’ll also say that you’re not in a position to go through the whole BREW authentication process and don’t want to buy all the Qualcomm tools needed to actually get your BREW app on a handset.

Well, you can go with Symbian.  But if you’re in the US and want to do a streaming video app that will most likely work where you’re demoing, you’ll want to stick with the Sprint or Verizon EvDO networks - and there’s a severe lack of S60 phones on those carriers.

J2ME?  Totally possible with MMAPI, but I would be afraid of performance on many phones.  Has anyone played with this enough to give a little assessment?

With these points in mind, Windows Mobile suddenly sticks out as a possibility.  But what are the options there?  

Well, you could try getting the good ol’ standard FFMPEG to compile and work on Windows Mobile - I did.  After some hours of sifting through various instructions, installing MinGW to compile the damn thing, and struggling with problems with the Visual Studio 2005 commandline linker, it turns out you need to do a lot of source work to make the thing work under Windows Mobile - a ton of effort.  I was soured very
quickly.

I then started looking at projects out there already.  One of which is TCPMP.  They formed a nice little company around the project, bringing their codecs to market.  I spoke with them on the phone, and they have some very cool products for people who want to get serious about H.264 across multiple mobile platforms.  But they are commercial, and we’re just doing a demo for now.  So they stay on the list for the production model.

Getting a little discouraged, I came across this: the Windows Media Player ATL Object.  Bingo!

Unfortunately, there’s no wrapper for .NET for it yet, so I was stuck coding in Win32 - something I’ve gone to great lengths in my career to avoid.  But this was just too much work done for me already to pass up.

So Visual Studio 2005 and me are slowly becoming friends acquaintances.  After going through the hell that is Windows COM, figuring out how to arrange dialogs to place it neatly in an app with my own widgets next to it, and generally just learning how to code Win32, the object works as advertised.  You get all the file formats that WMP standalone supports on the device, and you get access to network streams as well.  It really is a time saver.  From not knowing Win32 at all, I was up and running with my own custom app in less than a week.  If you know Win32, it’s like a day.

There are surprisingly few broken bits.  The blue player control bar at the bottom can be removed, so that you just have a black screen.  However, it doesn’t work in the emulator, or on PPC 2003 devices.  It’s only worked on two different WM5 devices that I’ve tried.  But I can deal with that.  It’s a demo after all.

If this was going to be produced for real, I’d be leaning toward the Core Codec library above, and would get down and dirty writing my own portable player.  But for this demo, I don’t think it could’ve gone any faster than using the WMP Object.  Anyone care to differ?

Now if they just include the control in .NET - we’ll be all set.  They already have a web browser control that gets you pocket IE in your app in two seconds.  I’d love to see WMP10 in there too.

Nokia and J2ME - bedpartners as usual - are moving forward together with the release of JSR 248 (and 249, but that’s another enterprise-level story).

What is in JSR 248?  In short, all the stuff we’ve wanted for a long time:

Mobile 3D Graphics API [JSR 184]
Mobile Media API [JSR 135]
BlueTooth API [JSR 82]
SIP [JSR 180]
Payment API [JSR 229]
Content Handlers [JSR 211]
Web Services [JSR 172]
Security and Trust Services API [JSR 177]
Location API for J2ME [JSR 179]

With all these amazing APIs, producing compliant handsets must be a real challenge for manufacturers.  But combining all of these services under one compliance spec is absolutely necessary if J2ME is going to remain a contender.

I’ve been taking a look at the Web Services API here.  JAX and SOAP bindings on
the handset.  Brilliant.

Sick of using the carriers (PSMS, etc.) to do your billing?  Here comes the payment API.  Now you can make
that social networking app, mobile MMORPG or whatever micro-payment app you’re dreaming of and charge people intuitively and independently .

I’ve been keeping track of these JSR’s but haven’t let myself get too excited until finding out they’ve been bundled under one spec.  If the implantations are consistent (fingers and toes crossed on that one), and support becomes widespread, J2ME developers can finally get serious.

Ajit Jaokar at Web 2.0 Journal distills the defining characteristics of Mobile Web 2.0 down to the following:

a) Harnessing collective intelligence through restricted devices i.e. a two way flow where people carrying devices become reporters rather than mere consumers

b) Driven by the web backbone – but not necessarily based on the web protocols end to end

c) Use of the PC as a local cache/configuration mechanism where the service will be selected and configured

I think these sum it up very well - especially the emphasis on the phone as an input mechanism.  Ironically, it seems that in the US, the only carriers putting this power in the users’ hands out of the box are MVNO’s.  Helio’s MySpace integration for example.  Nokia tried to do it right from the factory with their LifeBlog package, but that hasn’t taken off at all here.

Will the major carriers try to establish relationships with Web 2.0 companies?  What if Cingular integrated with Flickr on all their phones and provided a special discounted data plan to upload and view photos?  What about a Verizon EBay plan for those crazy sellers and buyers out there.  Run around your garage and post to EBay from your phone!

Are these carrier-sponsored Mobile Web 2.0 services a good thing?  Some would say it’s another attempt at sandboxing, but I think the mass market needs spoon-feeding like this in order to bootstrap more sophisticated use.