Starting Mobile Development

Posted Monday, January 6, 2003 7:26 am
image

You'll have to excuse this normally pro Java weblog as I veer into mainly mobile based development for a while. Not only is it where I think the future of technology is going, but it's also what gives me the most buzz. That's what I want to focus on, new technology that excites me. Back a few months ago, I was in a job where I was really going to be digging deep into server-side technologies. I had a plan laid out. I was going to get knee-deep in J2EE both at home and at work, get certified as an Java architect, learn Weblogic inside and out, etc. It was future-proofing my skills, but you know what? I hated the idea. It wasn't where my heart was.

This mobile stuff, however, is jazzy and fun. I'm bewildered by all the new tech I'm getting into, but I can't wait to get it all into my little pea brain. C++, Symbian, SMS/MMS, WAP/WSP, XHTML, J2ME and more. Oh boy!

The truth is that I've been waiting several years for the technologies to come to a point where I could start playing with them. When I first came to Spain as a consultant, we had a couple big telecom operators as clients (Airtel, which became Vodafone and Amena) and they were deep in the middle of the 3G and WAP hype that hit in 2000. We spent MONTHS creating a white paper about the "road to 3G" which talked about how to take today's technologies and start developing for a day when more people accessed the internet via their mobile "device" rather than their PC. Well, that was in 2000 and two years have passed pretty much uneventfully and finally in 2003, we're starting to see higher speed networks become common and smartphone clients become available. I'm dying to start working on this stuff finally!

Okay, so where to begin? Well, having finally gotten the offer code from my sister-in-law, I'm going to go buy a Nokia 7650 tomorrow. It's not my first choice, but it's a good place to start. My wish would be to start using the other Nokia Series 60 phone, the 3650, immediately because it's a version newer, has a little better OS functionality like video, more memory and a slot for a memory card and will be triband, and thus it'll be launched in the U.S. as well as Europe. However, it's supposed to be launched sometime in Q1 if it's not delayed, and that means waiting probably two months at least. And it'll probably be expensive at first, so it'll be out of my price range anyways. The Nokia 7650 will allow me to start developing for Symbian, with J2ME apps and MMS immediately and that'll be fine. I'm behind the curve of the die hard Symbian developers, but I'll still be ahead of a lot of developers, and that's the idea. I give it another 9 months to a year before we start seeing mobiles with phones everywhere, and that should give me time to get some experience with this stuff.

The comparision between the Nokia Series 60 phones and the SonyEricsson boils down to this. Right now, I'd prefer the P800, because I need a PDA as well as a mobile and I like the giant screen and Sony name. However, Nokia owns more than 50% of the mobile phones market, has licensed the Series 60 to all the other big manufacturers and there's now at least 20 Series 60 phones ready to be launched in the short term. So besides being $500 more expensive than the Nokia, the Series 60 platform is going to be much more widespread and that's where I want to target my efforts.

By the way, I explained this before, but I'll say it again here for clarity: There's no true emulator for the Symbian OS right now - you can't download a .sis Symbian program file from the internet and run it on your PC to test (like you can, for example, with the Palm emulator which uses the real ROM files from the device). What Symbian has done is create a bunch of Win32 mappings to the Symbian API, so you test your code at first by compiling your app with these Windows specific bindings which you run in the "emulator", then you rebuild it using the gc++ tools provided to be used in your phone (which has an ARM processor). Thus, it's ALSO impossible to test the true response and performance of J2ME and the XHTML browser as well. Right now, you need a real device to start development, there's no way around it. So that's why I'm getting the phone.

Okay, in case you want to follow along with me, here's my train of thought. First, in my mind there are FOUR types of applications you can write for this platform:

  • Native Symbian C++ Apps
  • J2ME Apps
  • MMS Apps
  • WAP/XHTML Apps

I think that I'm going to be playing with them all, and see what I can do. They all have their limitations in terms of figuring out what to do. Native Apps need to be downloaded and installed and need lots of time to write/debug/test and bullet proof. J2ME Apps live in a sandbox and have limited access to the local data and hardware - even the address book is off limits. MMS Apps are interesting - they'll have multimedia, but beyond that the functionality will be limited (and how many Photo home pages can you have?). WAP/XHTML sites will be the easiest to set up and thus have the most competition - especially later from established big web names with lots of content like Yahoo or AOL. It's still not going to be very easy or cheap for users to use the Web at first, so these type of apps are going to be a shot in the dark.

So, in my mind, the best apps will be those that use the connectedness of the phones, yet not rely on a constant connection to the Internet, which will cost users too much money. I want to explore exactly what MMS can do and doesn't do. I want to see what boundaries I can push with J2ME and I want to see what neat stuff is possible via Bluetooth using the Native API. Reformatting my blog for XHTML is also on the list, but not a huge priority right now, though mobilogging also seems cool. I haven't seen a news aggregator for the Series 60 yet... so there's a thought. There's more and more apps out there every day, but still there's nothing like what's out there for the Palm, so that leaves a lot of opportunity. Actually, that may not be a bad idea. Check out what's popular for the Palm, see if someone's made it for the 7650 yet and go for it... That doesn't really do it for me because the Palms aren't interconnected like smartphones - better to develop something unique.

Okay, here are some resources that I'm starting to delve into now, mainly from Nokia Forum's Tools & SDK page. Many of these seem to overlap... as I find the tools that do what I need, I'll be more specific. As for now, I've downloaded ind installed these:

And there's lots more.

As for documentation, I'm using the Symbian books I bought a month or so ago to start doing development, but most of the specs have a ton of documentation on Nokia's site - there's a lot and mostly in PDF format though some of the newer documentation is in HTML (look for the small "view online" link below the PDF link).

Just recently Nokia published this very interesting document about Mobile Game Development. Here's a snippet:

In an "act whenever" game, the game persists for a long period of time (days, weeks, months, possibly forever). Players can sign into the game at any time, and perform actions in the game. In some games, they might only be able to interact with (attack or perform other actions against or in concert with) other players who are also signed into the game at the same time; in other games, they might be able to interact with the positions of other players in the game even if they are offline.

In order to prevent obsessive players from gaining a large advantage over casual players, it is useful to limit the number of actions a player can take during a period of time. This encourages players to sign into the game for short, frequent sessions, but not too many. This reduces the load on your server as well.

Massively multiplayer games like EverQuest are, in a sense, act whenever games; the world persists even when your character is offline. Dataclash (www.dataclash.com), a WAP game from NGame, is another example: you are a hacker, and you build your defenses when signed in, and can attack the defenses of other players, also. But defense against attacks happens even when you are offline.

...

Another approach is simply to accept a high level of latency, and attempt to justify its existence through the game rationale itself. For example, most starship combat games feel like World War II air combat, with ships zipping around and shooting at each other. Instead, it might be feasible to do a game that feels more like World War I naval combat, with starships maneuvering slowly, firing volley after volley at each other, with missiles moving slowly across space toward their destination. You could conceivably hide a few seconds of latency with such an approach.

An example here is Quake, which hides the 200 to 400 millisecond latency typical of the wired Internet by ensuring that, in most cases, it takes several hundred milliseconds for bullets to reach their target-thus the firing player's machine knows whether or not the target was hit before it must display the appropriate animation.

Neat stuff. And there's an article on starting development using J2ME that was just published at O'Reilly's OnJava that's good too.

Okay, foof! That's the goods. Much more later...

-Russ

< Previous         Next >