It looks like there’s another third party deployment solution being touted. Nokia is offering deployment services for distribution of wireless applications called Preminet Solution (found via Tom Yager). After viewing the hideous Flash presentation and browsing around the site (why oh why is the FAQ a PDF?) this solution appears to be very much like BREW, with perhaps a few more platforms supported (java and symbian are two that I’ve found so far). Apparently the service isn’t launched yet, because when I click on the registration link, I see this:
“Please note that Preminet Solution has been announced, but it is not yet commercially launched. The Master Catalog registration opens once the commercial launch has been made.”
For mass market applications, it may make sense to use this kind of service because the revenue lost by due to paying Nokia and the operators is offset by more buyers. However, if you have a targeted application, I’m not sure it’s worthwhile. (It’ll depend on the costs, which I wasn’t able to find much out about.)
In addition, it looks like there’s a purchasing application that needs to be downloaded or can be installed on new phones. I can’t imagine users wanting to download another application just so they can buy a game, so widespread acceptance will probably have to wait until the client is distributed with new phones.
It’ll be interesting to see how many operators pick up on this. It’s another case of network effects (at least for application vendors); we’ll see if Nokia can deliver the service needed to make Preminet the first choice for operators.
Anyway, wonder if this competitor is why I got an email from Qualcomm touting cheaper something or other? (Didn’t really look at it, as I’ve written brew off until a J2ME bridge is available.)
I think that NextBus is a fantastic example of a mobile application. This website, which you can access via your mobile phone, tells you when the next bus, on a particular line, is coming. So, if you’re out and about and have had a bit much to drink, or if you’ve just forgotten your bus schedule, you can visit their site and find out when the next bus will be at your stop. It’s very useful.
This is almost a perfect application for a mobile phone. The information needed is very time sensitive and yet is easy to display on a mobile phone (no graphics or sophisticated data entry needed). NextBus has a great WAP interface, which probably displays well on almost every modern phone. The information is freely available (at least, information on when the next bus is supposed to arrive is freely available–and this is a good substitute for real time data).
And yet, there are profound flaws in this service. For one, it abandons a huge advantage by not knowing (or at least remembering) where I am. When I view the site to find out when the 203 is coming by next, I have to tell the site that I’m in Colorado, and then in Boulder. The website is a bit better, remembering that I am an RTD customer, but the website is a secondary feature for me–I’m much more interested in information delivered to my phone.
Also, as far as I can tell, the business model is lacking (and, no, I haven’t examined their balance sheets). I don’t know how NextBus is going to make money, other than extracting it from those wealthy organizations, the public transportation districts. (Yes, I’m trying to be sarcastic here.) They don’t require me to sign in or pay anything for the use of their information, and I see no advertising.
So, a service that is almost perfect for the mobile web because of the nature of the information it conveys (textual and time sensitive) is flawed because it’s not as useful as it could be and the business model is up in the air. I can’t imagine a better poster child for the mobile Internet.
Here’s an interesting 20 page paper examining some of the issues surround context and computing.
A few choice quotes:
“…answering the telephone has something of a moral compulsion.”
“…as much of this problem [a phone that understands context] reduces to that of building an intelligent computer.”
“…it is better to have machines which act in predictable ways so users can understand how they work” rather than unpredictable machines that ‘do the right thing.’
“A technology, like mobile phones, with its combination of voice mail, text messaging and the like, is something we dwell with in that it becomes part of the fibre of our practices and lives, even for those without(sic) reject them.” As someone who swore off mobile phones for a long time and now doesn’t know how life continued without them, I can sympathize with that sentiment.
“When people use a technology over time, and get used to seeing other people
using the technology, the actions of the technology come to be seen not as actions of technology but of the user themselves.”
When I gave my talk about J2ME to BJUG a few weeks ago, one of the points I tried to address was ‘Why use J2ME rather than WAP.’ This is a crucial point, because WAP is more widely distributed. I believe the user interface is better, there is less network traffic, and there are possibilities for application extension that just don’t exist in WAP. (Though, to be fair, Michael Yuan makes a good point regarding issues with the optional packages standards process.)
I defended the choice of using MIDP 1.0 because we needed wide coverage and don’t do many complicated things with the data, but WAP is much more widely support than J2ME, by almost any measure. If you don’t have an archaic phone like my Nokia 6160, chances are you have a web browser. And WAP 2.0 supports images and XHTML, giving the application almost everything it needs without learning an entirely new markup language like WML.
So, we’ve decided to support XHTML and thus the vast majority of existing clients (one reason being that Verizon doesn’t support J2ME–at all.) So I’ve gotten a quick education in WAP development recently, and I just found a quote that just sums it up:
“As you can see, this is what Web programmers were doing back in 1994. The form renders effectively the same on the Openwave Browser as it does on a traditional web browser, albeit with more scrolling.”
This quote is from Openwave, a company that specializes in mobile development, so I reckon they know what they’re talking about. A couple of comments:
1. WAP browsers are where the web was in 1994. (I was going to put in a link from 1994, courtesy of the Way Back Machine, but it only goes back to 1996.) I don’t know about you, but I don’t really want to go back! I like Flash, DHTML and onClick, even though they can be used for some truly annoying purposes.
2. “…albeit with more scrolling” reinforces, to me, the idea that presenting information on a screen of 100×100 pixels is a fundamentally different proposition than a screen where you can expect, at a minimum, 640×480. (And who codes for that anymore?) On the desktop, you have roughly 30 times as much screen real estate (plus a relatively rich language for manipulating the interface on the client). It’s no surprise that I’m frustrated with I browse with WAP, since I’m used to browsing in far superior environments.
3. Just like traditional browsers, every time you want to do something complicated, you have to go to the server. You have to do this with XHTML (but not with WML, I believe. WML has its own issues, like supporting only bitmap pictures). That’s not bad when you’re dealing with fat pipes, but mobile networks are slow.
4. Fitting in with the carrier is an issue with WAP. Since the browser is provided, you have no control over some important issues. For example, one carrier we’re investigating requires you to navigate through pages and pages of carrier imposed links before you can get to your own bookmarks. It’s the whole gated community mindset; since the UI sucks, it’s harder to get around than it would be with Firefox.
In short, use WAP 2.0 if you must, but think seriously about richer clients (J2ME, BREW, or even the .Net compact framework). Even though they’ll be harder to implement and roll out, such clients will be easier to use, and thus more likely to become a part of your customers’ lives.
Update 2/25/07: added Amazon link.
I go to Java Users Groups (yes, I’m struggling to get in touch with my inner geek) once every two or three months. Sometimes there’s an engaging speaker, but most of the time the fellow up front looks like he’s just swallowed a hot pepper, speaks like he has a permanent stutter, and answers questions like I’m speaking Greek. (I’m not making fun; I had a hard time when I was in front of a JUG too.) Regardless of the quality of the speaker, I gain something just by watching the presentation–he points out interesting technologies and usually has a list of resources at the end that I can use for further research.
I think Michael Yuan would be a great speaker at a JUG, as he seems to have a masterful understanding of Java 2 Platform, Micro Edition (J2ME). However, the true value of his book, Enterprise J2ME, was in its introduction of new ideas and concepts, and the extensive resource listings. This book is a survey of the current state of the art in mobile java technology. Whatever your topic is, except for gaming development, you’ll find some coverage here. Securing information on the device or network, XML parsing strategies, messaging architectures, and data synchronization issues are all some of the topics that Yuan covers.
My favorite chapter was Chapter 7, ‘End to End Best Practices.’ Here, Yuan covers some of the things he’s learned in developing his own enterprise applications, and offers some solutions to five issues that differ between the J2ME world and the worlds familiar to most Java developers: J2EE and J2SE. He offers capsule solutions to the issues of “limited device hardware, slow unreliable networks, pervasive devices, ubiquitous integration [and] the impatient user.” Later in the book, he explores various architectures to expand on some of these capsules.
However, the strength of this book, exposing the reader to a number of different mobile technologies, is also its weakness. JUG speakers very rarely dive into a technology to the point that I feel comfortable using it without additional research; I usually have to go home, download whatever package was presented, and play with it a bit to get a real feel for its usefulness. This book was much the same. Some of the chapters, like chapters 12 and 13, where issues with databases on mobile devices (CDC devices, not CLDC devices) weren’t applicable to my kind of development, but you can hardly fault Yuan for that. Some of the later chapters felt like a series of ‘hello world’ applications for various vendors. This is especially true of chapter 12, and also of chapter 20, which is a collection of recipes for encryption on the device.
Additionally, I feel like some of the points he raised in Chapter 7 are never fully dealt with. An example of this is section 7.3.3, “Optimize for many devices.” The project I’m on is struggling with this right now, but I had trouble finding any further advice on this important topic beyond this one paragraph section. However, these small issues don’t take away from the overall usefulness of the book–if you are developing enterprise software, you’ll learn enough from this book to make its purchase worthwhile.
However, I wouldn’t buy the book if you’re trying to learn J2ME. Yuan gives a small tutorial on basic J2ME development in Appendix A, but you really need an entire book to learn the various packages, processes and UI concerns of J2ME, whether or not you have previously programmed in Java. Additionally, if you’re trying to program a standalone game, this book isn’t going to have a lot to offer you, since Yuan doesn’t spend a lot of time focused on UI concerns and phone compatibility issues. Some of the best practices about limited hardware may be worth reading, and if it’s a networked game, however, you may gain from his discussions in Chapter 6, “Advanced HTTP Techniques.” In general though, I’m not sure there’s enough to make it worth a game developer’s while.
I bought this book because I’m working on a networked J2ME application, and it stands alone in its discussion of the complex architectural issues that such applications face. It covers more than that, and isn’t perfect, but it is well worth the money, should you be facing the kind of problems I am. Indeed, I wish I had had this book months ago, as I’m sure it would have improved the my current application.
Here is some advice for any of you thinking about doing any development for J2ME. I’ve written before on J2ME considerations, but the project I’m working on is a bit further on now, and I thought I’d share some hard earned knowledge.
1. Get Windows.
Make sure you have access to a windows box, running a modern version of windows. While Sun’s Wireless Tool Kit supports Linux and Solaris, and IBM’s WebSphere Device Developer supports Linux, no other emulators do (nor do they work under wine).
Whether you want to support Motorola, Nokia, or NEC, you are pretty much need windows to run the emulator. And an emulator is crucial, because it allows you to rapidly develop an application. And testing on as many emulators as possible means that your application will be as tight as possible. However, when you get something that is close to finished, you’ll need a real phone to test it on.
2. Get (a) real phone(s).
While emulators can tell you a lot, they certainly can’t assure you that an application will run on a real phone. One project I worked on had an emulator that ran the app just fine, but the app was locking up on the real phone. It turned out that the networking code needed to run in a separate thread. There are many things that differ between an emulator and a real phone. Installation of a midlet is different (and differs between phones as well). Instead of accessing a file on disk, you have to use OTA provisioning (sure you can emulate that with the WTK, but that’s just an emulation. I’ve run into issues with DNS that just don’t show up on the emulator). Also, as mentioned above, the networking capability differs, and the connection is much slower. The amount of memory that you can use while developing on the desktop is effectively unlimited (some of the emulators let you monitor the amount used, but I don’t know of any that lets you limit it), but phones have hard limits. Don’t you want to know what happens when you try to use 101KB of memory on a device that only has 100KB? The limitations you face on user interface are also more real on a phone, when you can’t use the keyboard to enter your username or the backspace key to fix errors. For all these reasons, you should get a phone as soon as you can.
3. Explore existing resources.
A couple of good books: Enterprise J2ME is a great survey book, with some very good ideas for building business applications (with large numbers of users) but not a whole lot of nuts and bolts. Wireless Java: Developing with J2ME, Second Edition is a good nuts and bolts book (it explains how to do your own Canvas manipulations, for example). Check out what else Amazon suggests for other ideas.
4. Have fun.
“1. The move to mobility is inevitable in the enterprise. The IT revolution has to reach hundreds of millions of mobile workers in order to realize its promise. There is no other way. However, the real question is how and when this will happen. With the IT over-investment in the last decade, this might take several more years.”
Agreed. Allowing mobile users to access the corporate datacenter is an inevitability. When it does happen, however, it certainly won’t have the sexiness or big bang of the internet revolution. In fact, it’s much more an evolution than a revolution. Folks already have access to corporate databases right now; the mobile revolution simply combines the portability of paper with the real time nature of laptops. However, letting knowledge workers such as sales people and truckers have real time information on such a cheap, reliable device really will change the nature of the business. But we won’t see sock rabbits or dot.com millions, since such changes will favor existing businesses.
“2. When enterprises move to mobility, a key consideration is to preserve existing investment. Fancy flashy J2ME games will not do it. The task is often to develop specialized gateway servers and J2ME integration software to incorporate smart mobile frontends into the system. That requires the developers to have deep understanding of both J2EE and J2ME. I think that the “end-to-end” sector is where the real opportunities are in the next several years. That is also what “Enterprise J2ME” is all about. :)”
Now, don’t be so quick to judge. Gamers pushed the boundaries of the PC in terms of computing power, and I wouldn’t be surprised to see the same thing happen on the MIDP platform. That said, I’m not a gamer. However, I still have issues with the idea of folks paying to play a game on a cell phone. I play snake, but that’s a simple, free game, and I’m certainly not dedicated to it. Fred Grott claims that MMORPGs are going to drive J2ME game development–I just don’t see folks doing that when you can get a much, much richer experience from the XBox or Game Cube or PC sitting at home.
And I don’t see why Michael ties J2ME and J2EE so tightly. The whole point of web services is to decouple the server and the client. I dont’ see any reason why you couldn’t have J2ME talk to a .NET server, or a BREW client talk to a J2EE server. To me, the larger issue with the mobile revolution is the architecture of the J2ME applications, since I think that such small, non networked, memory constrained applications (with either extremely limited portability or extremely limited user interfaces, take your pick) are going to be a world apart from the standard java developer’s experience (which is HTML generation, not swing).
I’m going to leave his third point for another post, as the outsourcing issue is…worthy of a separate discussion.
I’m working on a project that uses J2ME to display and interact with data from a remote server on handheld devices, specifically cellular phones. We are coding to the MIDP 1.0 specification, because that’s prevalent right now. The MIDP 2.0 will have some nice additions, and I’m looking forward to its widespread implementation. J2ME is nice because it has a lot of the same capabilities as java on the PC (J2SE). The specification states that J2ME is a strict subset of J2SE, that is, any class that is in the J2ME spec has to have all the methods of the J2SE class. The user interface of J2ME is also similar–there are forms, with various items that are added to them (choice groups, which are like radio buttons, and text fields are the main user input controls). In addition, a developer gets all the niceties of java–garbage collection.
While the transition from ‘normal’ web development (servlets, jsps) has been fairly painless, there have been a few hiccups. I wanted to cover some of them. This isn’t a colossal project, but we do have about 60 classes in 10 packages on the client communicating to ~150 classes on the server, so it’s not a stock ticker either.
Handheld devices, and particularly cell phones, are different than the browser. They are much more under the control of the folks who build the devices and install the initial software on them. If you thought it’s difficult to install the new JVM on your PC, try installing any kind of JVM on your cell phone. This means that the carrier (AT&T, Verizon, etc) matters in a fundamentally different manner than the OEM of your PC. This immediately jumps out when deciding on a platform. There are two main platforms out there for cell phones: BREW and J2ME. I don’t want to go into what BREW is here; Colin Fahey does a good job of covering the differences. Suffice it to say that, for both non technical and technical reasons, we decided to pass on BREW for a while. This means that Verizon, the largest US carrier, is off limits to us, as they only support BREW. We’re in the unenviable position of telling paying customers that they have to switch cell phone service if they want to use our app. Luckily, there’s hope for the future. J9 is a plug-in for BREW that will allow J2ME apps to run on BREW devices. However, it’s my understanding that we have to wait until BREW 2.0 is widely deployed to use this capability.
In addition to dealing with different support from different carriers (even with the same handset), developers of J2ME apps also have to deal with developing on a different platform. Only the foolish actually compile applications for a cell phone on a cell phone. They have slow processors, limited memory, no floating point support, etc. The MIDP 1.0 specification only requires you to have 128KB of memory and 8KB of persistent storage! This lack of resources means that you are going to cross compile: work and compile on your PC, download and test on your device. There are a couple of different solutions for this: IBM WebSphere Device Developer [WSDD] (which is based on Eclipse) and Sun’s Wireless Toolkit [WTK]. Each of these also provide an emulator so a developer is not continually downloading to their phone. I happen to have a non J2ME capable phone, so an emulator was a must for me. But, as ever, there are complications. Emulators aren’t perfect, as we discovered the first time we downloaded the application to a real phone. Our application makes a number of network hits to get information. This was working fine on IBM’s emulator, but when downloaded to the phone, the application locked up. After some investigation, it was determined that this was because the phone was asking for user permission to access the Internet, but our application wasn’t well enough behaved to let the phone have the system thread to ask the question. Luckily, this article set us straight. The Sun emulator was less forgiving. So, what I’ve ended up doing is using the ‘best of breed’ solution for each problem. I use vi to edit the source files, WSDD to compile and build that jad (WSDD makes it much easier than WTK), and the WTK emulator to test.
Information architecture is also a different beast on mobile devices. Rather than having 1024×768, 800×600, or 640×480 pixels, a developer has a 150×150 screen (of course, this depends wildly on the phone, but none of the phones I know of get anywhere close to the PC screen). This means that each piece of information must be carefully chosen. If there’s a ton of information, this also means that sometimes one has to break it up across screens. But, one should also minimize network hits and the amount of clicking around a user needs to do. Have you ever text messaged someone? Wasn’t entering text tedious? So, there’s this constant tension between having the application displaying useful information and minimizing the user input needed to get that information. Add to this the fact that we don’t really know how folks are going to use our device, and you have a coding headache. This article has some good suggestions. Of course, Jakob Nielsen has an answer–test it! Put it in front of some actual users and see what they do. And we will. But, when coding for a handheld device, I hold it as a general principle to minimize user input. In addition, there isn’t the nice MVC framework that I’ve grown used to. Instead of having an explicitly defined state machine, our application has a stack of previously visited screens. This works well currently, when information traversal is fairly linear (take me to the information I want!) but I’m leery of what will happen when the application grows more complex. Having each screen ‘know’ where it should go next doesn’t seem to scale very well.
Versioning for J2ME applications is new for me. It is similar to versioning for desktop applications, rather than web applications. I guess I’m spoiled–I’m used to being able to change the application at the server, and have those changes ripple out to all the dumb clients. J2ME is different–since you’re downloading a client to the user, changes to the server need to be coordinated with changes to the client. Not all changes, just those in the interface (which in our case is get parameters and XML over HTTP). But still, when you change that interface, you have four options: leave the old server up and running, break the older apps, have the features of the new server be a strict superset of the old one, or forcibly upgrade the older clients. This is a problem we haven’t faced yet, because we’re still in development. But, I can see it looming on the horizon. And as far as I can tell, this problem hasn’t been solved for the desktop (DLL hell, anyone), and they’ve had a heck of a lot more time and money to throw at it than I will.
The last concern about J2ME that I’m going to touch on today is performance. We haven’t gone through any kind of performance testing, and are still green enough to not have any experience that might guide us. So this section is just questions you should think about, rather than any kind of answers. There are several different types of performance, and they obviously aren’t orthogonal: number of threads, storage, memory, and network trips, and, perhaps most importantly, perceived. What are the limits on the number of threads on a mobile device? What is the cost of the context switches that happen? Should you keep a thread around, or dispose of it when you’re done? What should you store? How often should you verify it hasn’t changed on the server? MIDP 1.0 gives you the ability to store raw bytes–how do you want to abstract this for your application? What’s the speed of reading from ‘disk’? How much memory does your application use? Is it constant, or does it spike? How many new objects do you create? What’s the effect of this on the user experience? How many network trips do you make? What is this costing your user (both in dollars and in time)? How robust is it? What happens when you don’t have a crystal clear connection? How are you communicating with your server? How can you minimize your network connections? What feedback do you give a user when the device is waiting? What can you cache to speed up their experience?
J2ME is very cool, and I’m really enjoying learning more about it. As you can see from above, I’ve plenty to learn. There are several differences that you need to be aware of when doing mobile development in java, and I hope I’ve outlined some of them.