Thursday, January 31, 2008

So, you want to deploy a J2ME app in the US?

We are about to launch a new mobile service in the US. Sounds simple, doesn't it? Well, it's not...

You have two ways of deploying a mobile service in the US, and for that matter anywhere in the world. One is to go hand in hand with the mobile operators and launch your application on their deck. You can gain marketing cooperation that way, and the fact that you're on their portal, guarantees a fair share of success.

Why not go that way? Well, for starters the deal cycle can take about 12-18 months. And not only that, you have to convince the operator that it is even worth talking to you... And while I hate to admit it, it's quite reasonable... Operators (or carriers as they are called in the US) get a huge amount of noise from companies wanting to launch their services. Content managers there have more hits than Google has... So, even if you're a start-up with a brilliant solution, they will have a hard time getting you in unless you have some proof of getting revenues or an impressive userbase or an impressive brand etc.

Oh, and there's also the fact that they will take about 50% of your revenues...

The other option, which is taken by most consumer-oriented start-ups when they begin is going off-deck without any business relationship with the opertaor. This is very suitable for free mobile 2.0 products that operators don't like very much (50% of 0 is...), especially if those can be used as a substitute for messaging and voice. However the operator gets data traffic (And the application provider can't touch it), so you would think that in the big picture, operators would like to increase data traffic as they always state.

However, in the reality of things today, application providers find along the way a lot of barriers when they try to deploy their apps off-deck, and the situation in the US is much worse than Europe in which operators already understand that they should encourage data usage.

Anyway, there is also a big difference between the various operators in the US, and during the last few weeks I have come to learn the nuances both via extensive testing we've done on handsets in US networks (Using Mobile Complete's Device Anywhere) and the help of my colleagues at Mobile Monday Silicon Valley.

And here are the results:...

There are 4 big operators in the US: AT&T (which purchased Cingular), Verzion, Sprint-Nextel and T-Mobile. There are also smaller and regional ones, that we'll elegantly ignore for simplicity (I want to get this post done by 2010...)


Verizon

Our application is in J2ME, which is de-facto standard in Europe and also other parts of the world. J2ME is also gaining dominance in the US, however one (big) operator doesn't support it (yet) - and that's Verizon.

So Verizon was out of the picture from the start for that phase, and this is how a lot of start-ups start: First a J2ME version that can cover Europe and about 65-70% of the US. BTW - The Java "version" will have to be ported to about every device in those markets (read my post on that), but Brew is a complete rewrite, so the effort is bigger.

In any case, though we didn't test on Verizon, it is about the most closed environment, so much that you can forget about releasing something off-deck.

T-Mobile

From some reason I had the notion that T-Mobile would be a very open network. Maybe it is because I know it from Europe, maybe it's because it was an early adopter for J2ME and maybe it's because it was rather open up until a few years ago. However, today the situation is quite the opposite.

Users are able to download J2ME apps (JAD+JAR), so if you have an offline app, like a standalone mobile game, you should be fine. But if your app requires an internet connection - you'll be surprised to find out that that is not trivial at all. In the bottom line users will be able to access the internet if:
1) The application was signed with a T-Mobile certificate, or
2) The user has a $20 "total internet" plan instead of the regular $6 T-Zones one, or
3) The handset was not bought through T-Mobile.

Now, as you can understand (2) and (3) are major problems, since the majority of users do not have a $20 data plan and buy their handset from their operator, so you can't rely on those.

As for (1), in order to get a certificate from T-Mobile, you have to have some sort of a commercial agreement with them, which brings us back to plan A (on-deck) that can take 12-18 months as explained above.

Now you might have heard of 3rd party certificates (Verisign, the Java Verified program) - those will not do you any good here. T-Mobile alters the Java security domains and permissions on the handsets it sells in such a way that only a certificate by T-Mobile is considered to be trusted, and any thing that is not trusted does not have access at all to the network as well as to other APIs (SMS, Bluetooth etc - see the exact list here).

This is why users who bought their handsets through other channels have devices that are less restricted and do not block any API even in the untrusted domain, but rather prompt the user whenever there's an attempt to access resources (BTW - on the network side, these users may still have to configure a proxy to use the $6 plan, which is not trivial at all, but at least these menus are not blocked like they are on handsets sold by TMO...)

In short, if you are aiming for a mass-market consumer application, and not just one targeted at business users or tech-savvy users, your hands are pretty much tied... The only way to acheive that goal is to go on-deck with T-Mobile.


AT&T

AT&T appears to be (at least now, these things tend to change) a little less strict than T-Mobile. You can download J2ME applications from anywhere, and they have network access (HTTP), which is what we needed. However, it seems that although we didn't bump into a wall with AT&T, other applications that want to use socket communication, access to the file system, address book and messaging (SMS/MMS) will probably be blocked (See Hartti Suomela Forum Nokia Blog and the exact domains/permissions in AT&T. Hartti has done some research on the subject and answered my nags on Mobile Monday... Thanks Hartti...)

The blockng of those resources/API is done on the same way as with T-Mobile, by altering security domains on handsets sold by the operator. And again even if the application is signed by a third party, it won't make much difference, but at least in AT&T in this case SMS will be allowed in addition to network access.

So it seems that for unsigned applications "just" HTTP network access is granted compared to T-Mobile, but this is a huge difference, since most online applications need just that (sockets communication is less popular also because some handsets don't support it as well as other networks in the world). For example, GMail mobile, Google Maps and Opera Mini will run on AT&T but not on T-Mobile.

However, more advanced mobile 2.0 applications that interact with the content on the handset itself (address book, pictures, other files) will have a hard time running on both networks (hard time=they wouldn't run at all...)

And one more note about unsigned applications (which are considered "untrusted"), even if the operator allows them to install and access HTTP like in AT&T, the handset still gives the user several security alerts, but that's common procedure in J2ME.

Note that those alerts are sometimes quite nasty (For example, in Nokia's newest devices the message can be "This application may cause damage to your handset"...) so you might consider getting a certification from a third party such as Verisign.


Sprint-Nextel

Even though Sprint purchased nextel some time ago, there are still 2 seperate networks with different technologies. They may both be marketed under the Sprint brand, but since there are differences in their policy, I'll address them separately:

Sprint (CMDA)

Sprint is a CDMA network, which usually doesn't combine with J2ME. Traditionally GSM networks supported J2ME and CDMA supported Brew. However, you can understand that this doesn't have to be the situation since J2ME/Brew are high-level technologies that can be implemented over several OSs, while GSM/CDMA are the low-level transmission methods. It's like saying that Java works only on ADSL while .NET works only on WiFi....

The reason for this traditional coupling may be related to commercial aspects or simply to the fact that once handset vendors made specific devices for specific networks it became a standard in those networks.

In any case, while Sprint is a CDMA network it does support a wide variety of J2ME enabled devices, and as expected it has similar issues like its GSM "sisters". Again with the security domains and permissions alteration, but closer to AT&T: you don't have to sign your apps for network access, but other APIs are restricted and can only be used with a Sprint certificate (see the full details here).

Sprint does make it easier for developers and allow them to obtain a developers certificate so they can test their apps before even speaking with Sprint. This certificate is available at the custom WTK (Wireless Toolkit) that is available at Sprint's developer portal (This certificate is only good for testing). In addition I was told that it is much easier to obtain their production certificate, and it doesn't necessarily involve a marketing cooperation, so this process may be quicker.

And one more technical tip you should know: some of Sprint's devices are more sensitive when it comes to JAD definitions. At first we thought that the download itself is being blocked, but it's not. If you can't download an app, go over the JAD definitions and check the MIME type your server send JAD files as.

Nextel (iDEN)

The iDEN network in Sprint-Nextel (which I'll refer to as Nextel, since it was just that originally) is even trickier, but not only because of the operator's restrictions, but rather due to the technology itself.

iDEN handsets do not allow users to download J2ME apps unless it is from the carrier's portal (which means you have to get on-deck). However, you can download the application to your computer and from there transfer it to the handset using a data cable and a tool called openJAL. This is of course not an optional delivery for the mass market, as just tech-savvy users (or geeks as they are more commonly referred to...) can do that.

Note that this is even before we got to the permissions "bridge" - no application even if it's a standalone offline application can be downloaded over the air if it's not on the operator's portal/deck, and in that perspective it's the worst restriction set, but again it has also a lot to do with the technology itself.

So again, you are left with the choice of either getting a deal with the operator or deploying your app to users that can hack their way through (That would be me and some of the guys in the office here... definitely not a very promising demographics...)

Summary

So that's about it. As I said there are other operators in the states but these are the big four. As you can see the current state makes it difficult to deploy applications off the deck, and that's slowing down the industry in my opinion.

The operators themselves claim that the restrictions are for security reasons, and I can understand that partly, since no carrier wants its users to download apps that access their private data or sends messages/connects the internet without permission. But isn't the customer smart enough? I mean what's wrong with the normal security domains in which untrusted (unsigned) applications can access resources only after a system prompt to the user? These messages are scary enough that a user that doesn't understand will click "No", but those who do, can enjoy great apps, and the application providers can enjoy a growth in their revenues, as well as the operators in the end.

So get moving guys and unlock your networks!

Tuesday, January 22, 2008

MIDs, UMPCs and the iPhone

One of the trends in the CES show earlier this month was the rise of MIDs (Mobile Internet Devices). MIDs are basically ultra portable internet consoles. Unlike laptops or PDAs, they do not have to run any Windows (or other platform) applications - they can run only one application: a web browser.

The MIDs are in fact a branch in the UMPC (Ultra Mobile PC) family, and while UMPCs are designed to be just very small PCs (with operating systems, ability to install and run applications, store things locally etc.), the MID are less "ambitious" but in my opinion, more to the point of what most mobile users need.

The MIDs are small and lightweight (naturally), typically have a 4.5-7 inch displays, and some creative keyboard solutions (blackberry-like small keys, a sliding keyboard under the screen, touch screen keyboard etc.). Also, their processor does not have to be cutting-edge, and in fact Intel is developing several weak processors especially for MIDs.

Now, a few years back, this would have been a weak solution for on the go computing, since you can't do anything when you're offline, and also you cannot run applications such as Microsoft Office.

However, there are two things that changed over the last few years that make those two arguments obsolete:

1. Applications have migrated online

A few years ago, it was Sun Microsystems who coined the term "The network is the computer". Everybody was talking about online applications stored and managed centrally, accessed by users who pay per use or license it for a certain period of time instead of the model where you buy a piece of software, install it locally and use it indefinitely (or until the next version comes out...).

Sun did a lot to make that vision happen, but on the consumer applications side, it was Google that really made it. While reading emails online is old news (so last millennium...) Google's GMail was truly innovative for its time, and eliminated the slowness problem most webmails had (and still have). In addition with Google Calendar you can manage your calendar and with Google Documents you can read and write documents, presentations and worksheets. Now I know Microsoft's Office is still better - but give it time... And don't get me started on the killer app of them all - Google Maps...

Aside from Google there are a lot of other great services available online. Today with AJAX technologies you can make great fast apps that require just a simple browser. With the addition of two standard plugins - Java and Flash you can also play online games and have access to advanced applications.

In short, Sun's vision is no longer a vision, it is happening, and while people have been saying that for quite a while, today I can say personally that I use mostly web-based services. I find it very convenient as my data is accessible from anywhere and I don't have to sync computers, move files manually (disk on key) etc.


2. You can't be productive offline

When I find myself with my laptop but there's no WiFi around, I do all sorts of things: I am cleaning my desktop, removing installed applications, moving files from folder to folder - in short my productivity is similar to the productivity of a painter that has colors.

Today we read the news on the web, we communicate with our friends and colleagues (email, IM, VoIP, social networking), we search for almost about anything (and find it!), we read articles, make our travel arrangements, bid on and purchase stuff, check our financials and perform financial actions (bank accounts, stock portfolio, credit cards etc.), blog and more.

When your computer is offline - it is disabled. You can't do at least 80% of the things you would usually do. I will repeat once again Sun's motto: The network is the computer. As simple as that.

Another element that helped us get addicted to the internet is the rise of WiFi networks. If you are on the go, you would have no problem finding internet access in your hotel, coffee house or even in the train.


To sum it up, it seems to me that MIDs are about to get popular. They are definitely a great solution for mainstream users (and even advanced ones). In fact, one MID that got really popular although it wasn't necesarily sold as such is the iPhone...

The iPhone fits the criteria of MID, and is in-fact a very well-done MID, keeping things smart and simple, and focusing on the real things mobile user need. It also have the mobile phone functionality, which gives you extra mobility in the rare cases where you can't find WiFi... (By the way, voice calls is not something it adds - since you can do those in MIDs with various VoIP programs, today it's sometimes complicated, but it will get easier as more and more people will be always connected).

So it's no surprise Apple sold over 1 million iPhones in one quarter, and I do believe that this is certainly an indicator not only to the mobile phone industry, but also to UMPCs and MIDs (The borders are getting a bit blurry, aren't they?...)