Archive for the ‘hardware’ Category
I just noticed this past weekend that I can read this blog from my handset!!!
The cool thing is that if you’re reading this on your handset right now, you can click on this link to my games page and from there download the sample games and programs right onto your handset and try them out!!!
I’ve made a new HTML version of my games page (the above link) since my current handset is capable of reading and displaying html. For those whose handsets support only WML (not HTML), I have two WML pages available that link to the same sample programs: http://frog-parrot.net/hello.wml and http://frog-parrot.net/checkers.wml. Please feel free to link to any of these pages.
Even though I’m now mobile-blogging 😉 , it somehow feels like I’m not getting the complete mobile blogging experience since I’m only reading the blog from my handset (posting from my hopelessly non-mobile PC…)
I could probably remedy this by using some tips from this introduction to mobile blogging article by
I’m a little skeptical of this idea since the most interesting photo blogs tend to be written by serious photo hobbyists (if not professional photographers) who have real cameras. And in my own case, I’ve mostly been posting photos of my handset, which are tricky to take using the handset’s built in camera… But who knows? Maybe this idea will become popular.
Actually I’m tempted to combine this “mobile photo blog” idea with the following handset bug I read about recently:
Q: My Nokia 6131 keep taking photos whilst in my pocket – Why?
A: Unfortunately the camera button is on the side of the handset and there is no lock for this. this cannot be changed.
Lots of handsets have strange bugs, so I don’t know why I find this one so hilarious. “My handset keeps taking pictures of the inside of my pocket!” “Um… There’s nothing we can do about that, sorry.” lol
I think this would make a great experimental / performance art blog: “photosMyHandsetSpontaneouslyTookOfTheInsideOfMyPocket.wordpress.com”
Don’t any of you steal this idea before I get around to doing it. 😉
“Why won’t my MIDlet connect with my Servlet?”
It’s such a simple question, isn’t it?
Unfortunately, there are so many layers of communication and so many places to make a little (yet fatal) error, that there’s no simple answer that solves the problem every time.
In my experience, establishing the initial “hello world”-level back-and-forth communication between the client and the server is one of the most frustrating steps in client-server programming. Once you’ve established a complete and correct communication circuit, you’ve got your foundation to build on. Before that — even if you know your networking and protocols well — you’re kind of tossing your message into the black void and hoping it comes out the other side…
But troubleshooting — tracking the problem down wherever it may be — is something every good engineer should be ready and able to do. So let’s talk a little bit about strategies for narrowing down where the problem may lie in a simple case such as a MIDlet that fails to connect with a Servlet via HTTP.
1. Does it work locally, on the simulator?
Getting it running on the WTK simulator is the first step to making sure it isn’t your MIDlet or Servlet that are the problem. Unfortunately, even if it works on the simulator, it still may be that your MIDlet is wrong. Sometimes the WTK is excessively lenient about things that your handset might not like such as reading the body of the message before getting the response code.
If it’s not even working on the WTK, what can you do?
As a general rule, at this point, I would strip my example down to the simplest possible example — a servlet that returns “hello world” and a MIDlet that displays the response code and the message recieved — to reduce the number of places where things can go wrong.
Be sure you know where your server logs are, and check them for clues. Try your URL in your browser and see what the browser returns. If you’re running the client and server on the same machine, you can substitute 127.0.0.1 for the IP address to see if it’s some sort of routing issue. If none of that yields any response from the server, try your server’s “Hello World Servlet” tutorial.
On the client side, note that the WTK has a built-in profiler. You can find it under Edit > Preferences > Monitor > Enable Profiling. This will display for you the raw data exchanged between the client and the server. I’m a little wary of this profiler because it starts some processes that sometimes interfere with installing a MIDlet using Project > Run via OTA for some unexplained reason, but when you really need it, the profiler is useful.
Now, let’s suppose it’s working on the WTK simulator but not on the handset.
2. Can the handset successfully make any HTTP communications from Java?
Generally a handset has a configurable profile which gives information regarding proxy servers and whatnot that tells how to get from the operator’s network to the open Internet. Sometimes the handset has a separate profile for Java and for WAP. They’re usually careful to make sure the WAP profile is right, so if they’re separate, one thing to do is to copy the data from the WAP profile to the Java profile, if you can find the right menus to do it…
One way to check if your Java profile is correct is to try some other working MIDlet that makes a connection via HTTP. For example, I ran the MobileZoo MIDlet the other day, and it succeeded in contacting MobileZoo, so I know that my handset is correctly configured to use HTTP from Java.
3. Is the server accepting requests from the outside?
You know the old story: internal routing is different from external routing, and those lovely firewalls… Try your URL on a computer outside of your local network.
Now once you’ve done all that, it should work!!!
Unfortunately for my “Hello World” MIDlet/Servlet it doesn’t…
I think we’ve narrowed it down to the fact that I’ve set up my server to use a non-standard port for HTTP, and some step in the network chain doesn’t like it.
Hopefully it will be up and running this weekend. I’ll keep you posted!!! 😀
My planned post for today was going to be some interaction exercises (either HTTP or SMS — I hadn’t decided), but it looks like I won’t have anything post-worthy on that front before Wednesday at the earliest (I got sidetracked this weekend by some household tasks), so instead I’ll tell you about playing with the new alpha download from MobileZoo. It should be kosher to blog about this since I don’t see any way this could be a competitor to MobileScope.
I’ve chosen this topic not only because I find MobileZoo’s concept intriguing, but also on the principle that — since this is a new blog — I give preferential treatment to anyone who leaves a comment on my blog. Even if the comment is just an ad for your new start-up. 😉 (As long as the comment is relevant to my post of course.) My goal is to get so many comments that the welcome default comment from “Mr. WordPress” drops out of the “Recent Comments” section of my sidebar. Sure I could just delete it, but that would be cheating…
The idea of MobileZoo appears to be the creation of a centralized database of all of the precise specs a Java developer might need to optimize an application for a given handset (including which JSRs are supported with version numbers if applicable, plus screen and canvas size and colors, etc.). All of this information is harvested by a MIDlet along the same lines as the MIDlet I posted the other day only more extensive, gathering up every bit of information about the handset that is accessible via Java. Then the MIDlet sends this information to MobileZoo. It looks like the revenue model is to offer a premium service and/or a stats-gathering library to registered developers. (Or maybe they’re just planning to get paid through putting ads on their site?)
So, I downloaded their jar of goodies to try it out.
The first thing I noticed was that the download is a jar file alone. I guess that’s okay since this product/service is aimed at developers, and one can reasonably expect that a Java ME developer would know how to take a jar file from his local PC and get it installed on a handset. However, personally I don’t have a cable or other simple way of connecting my handset directly to my PC, so I ended up writing my own jad (descriptor) file for it. For that I had to open the jar file and copy a bunch of lines out of the mainfest file and then add the jar size and jar url attributes by hand. Then I uploaded the files to my site so I could download them onto my handset from there. Since this project depends on persuading as many people as possible to run this program on their handsets, MobileZoo might want to make their MIDlet available on a WAP page (if it isn’t already) and post the URL on their main page. There’s no reason not to do that since it would only take a few minutes to add this feature to their site, and it might make it easier for some novice developers and other random users.
It’s pretty clear that it’s an alpha. Some of the links on the site don’t work, the “français” page is the same as the English page, there are grammatical errors, etc. (Of course I’m hardly one to taalk — I’ve noticed that my previous blog entry is riddled with typos, but I can’t go back and correct it without screwing up the formatting on the code sample because of the screwey blog editing software. But that’s an unrelated minor squabble between me and Mr. WordPress. 😉 .) Anyway, every good idea has to start somewhere.
I was almost a little hesitant to run this program on my handset, since it’s an unknown application that I just happened to download off the Internet that’s going to read information from my handset and then send that information to some unknown site on the Internet. However — given Java’s security system — I don’t think there’s really much danger that a MIDlet running with the “untrusted” security level can do any harm. (I know it’s running as “untrusted” since there’s no digital signature in the jad file I wrote for it…) I double-checked the PIM API JavaDoc to make sure that an untrusted MIDlet can’t read information from my addressbook without asking for permission, so I know they’re not even trying to harvest my contacts’ phone numbers for some nefarious marketing purposes or something. Even so, since I’m not much of a trusting soul I guess, I ran it first on the WTK to see what it was going to do. (There it had a strange Exception, but ran anyway.)
And here’s the result.
Amusingly, the program failed to identify my handset as a Sagem — it looks like this is the first Sagem they’ve captured stats for.
All in all, this looks like a fun idea. My one concern would be to wonder how they’ll persuade enough people to install and run their program. It costs the user effort and network time, and the user doesn’t get much in return except detailed developer-level information about the local handset. I guess that’s enough to make it interesting for me, but for how many others? Maybe they should reward the user by showing an animation of a dancing monkey during the upload? Hehe, just kidding, but it seems like it would be a good idea to somehow make this little procedure more cool and fun so kids will recommend it on forums or mySpace or whatever… 😉
The first step was to install the games from my book on my new handset.
This was a pretty simple exercise — the only glitch was that some of the built jar files I had lying around on my machine were earlier versions (with a bug, unfortunately), so it took me a couple of tries to get the correct version built, uploaded to my website, and from there downloaded onto the phone.
I had of course already played my MIDP 1 games (Maze and Car-Voiture) on my old Nokia 6100. Here’s what they look like on my new Sagem:
Now I hate to admit this, but I didn’t get a chance to test my MIDP 2 games on an actual handset before the book went to press. This is because at the time MIDP 2 handsets weren’t available on the market. There was one Nokia that almost came out in time for me to buy it as my game-prototype handset (but didn’t quite make it). And though I was working for a mobile gaming development firm during the corrections phase, I was working with the simulator myself, not actual handsets. Of course I’ve had my hands on tons of MIDP 2 handsets since then, so I suppose the fact that I never bothered to upload these games on any of them shows a deplorable lack of curiosity. But I’m here to make up for it now!!!
I feared the worst, especially since another blogger who said some nice things about my book here noted that the screen-size restrictions I’d placed on my game prevented it from running in his environment. I assumed I’d run into the same problem and have nothing to see. So I was pleasantly surprised when my Dungeon game ran great on my Sagem, and was more fun than I’d remembered it (if I do say so myself 😉 ).
I ended up just sitting around playing this one for a bit. I’d forgotten how much care I’d put into designing these boards to be built of simple building blocks and described by a very small amount of data, yet tricky enough that you always need to use at least two keys to solve each board and not always obvious which key will be useful when. That’s my excuse for why I limited the screen size by the way — if you see the whole dungeon at once the solution is obvious. (That’s my excuse for this game anyway — I don’t remember what my excuse was for doing that on Tumbleweed.)
This one really is kind of an absurd game, but the animated jumping cowboy and waving grasses are entertaining. The music track I invented for it is a bit less amusing. My husband stopped by the computer room to tell me how annoying the music is, but it was hardly necessary to point it out. So we learn that while it’s possible to write music for a game using a tone sequence, it is a pretty rudimentary tool — it’s difficult to get something that sounds professional from it. I’m pretty sure all of the games produced by the company I work for use real sound files.
I’ll test the Checkers game later because of the networking involved…
You can download these games onto your handset at the following address: http://www.frog-parrot.net/hello.wml
I normally think of myself as a person with very little graphic design ability, and I’d set these games aside on the shelf for the past few years while working exclusively with games produced by studios that have at least a few graphic and game designers in addition to just programmers, so I kind of expected to find these absurdly clunky — just prototypes to illustrate programming techniques. I was pleasantly surprised to see they’re actually not too bad as games. The thing is that even as these devices increase in computing power and memory, you’re still fundamentally limited by screen size an ergonomics, which means that often a simple game ends up being more fun and popular than something more complex.
That said, there are some fairly simple things you can do to take your game up a notch from the design level illustrated by these examples and turn it into something that looks polished and professional (in addition to the obvious “be a good artist or hire one” 😉 ). That’s one of the topics I hope to discuss in this blog.
First things first, though. My next installment will be setting up the latest wireless toolkit and maybe some other emulators as well.
There, I’m finally ready to begin!!!
After more than a month without posting (or even looking at this blog), I was worried I’d find it had been deleted or overrun by blogspam comments, but nope! Here it is waiting for me.
I’d like to work into this whole Java-blogging thing slowly, so for the moment I’d like to treat this almost as a notepad to jot down little notes on my projects rather than waiting until I have a beautiful, finished article worthy of a magazine. Because you can see where waiting for that perfect article has gotten me — just look at my posts here for the past month!
So I’ll just write whatever until I get into the habit. ;^)
Now, my Nokia 6100 that starred so prominently in my book died pretty quickly after serving that role. It developed a problem where it would sponteneously freeze up (not just during Java apps — really any time I had to enter stuff in the keypad there was a freeze-up risk), but since it would correct itself after about five minutes each time, I never bothered to replace it until just now.
Lately, I’ve bought myself a lovely new Sagem myX700!!! I seem to be having a little trouble receiving calls sometimes (perhaps because I’ve switched networks?) but the fun part is the new Java potential!!! My husband took the opportunity to get himself a Java handset at the same time (a Samsung, I think), so I have two new devices to play with.
Now I know I can just go straight to Google to find out all of the details on the specs of these two devices, but for fun I’d like to start by installing some test MIDlets on them to see what they can do.
Stay tuned for results!!! I’m planning to tell you all about it in my next post!!! 😀