Aliens Ate My main()

talkLock Project Page

Or, Aliens Ate My main()

talkLock F.A.Q. (Frequently Asked Questions - 常见问题)

I've only been asked one question about talkLock, but I thought it would be fun to pre-emptively answer questions that I may someday be asked in the future, and apparently fairly frequently.

Why did you think it would be fun to write an FAQ?

If you worked on mobile java programs, you would understand. I frequently require distractions and long rests from working on talkLock, up to five or six weeks. I couldn't bear working on talkLock tonight, as I'm so pleased with the progress I made a couple days ago. So I'm doing this instead. Whee!

What about that one question you were asked?

I was asked what platform I used to write and develop talkLock. This could be a long story, but I'll make it short by saying that I use NetBeans with the Mobility Pack. If you can run Netbeans and create a new Mobility project, then you are probably all set to rock talkLock style.

What is talkLock?

talkLock is a sociological experiment that aims to cure people who think that it would be neat to write a program that runs on their cell phone. Graduates then can go on with their lives, secure in the understanding that they don't ever, ever want to do that. Folks who leave the program still believing that they want to work on programs that run on cell phones are then put under observation by scientists in a facility of our choosing, to be subjected to further sociological experiments.

Whatever.

Yeah, okay, talkLock is really a program that runs on cell phones. It is a work in progress, but the idea is that it will allow anyone running talkLock on their phone to have an encrypted conversation with another person running talkLock on their cell phone. The idea is that folks can have a conversation without being eavesdropped on electronically. It depends on a server component, a simple php script currently, that acts as a mediary between the two phones.

Why would people care if their conversations are eavesdropped on?

I know it's not very modern to make value judgements or make declarative statements, but my parents taught me that it's wrong to listen to people's conversations without their knowing. There's also another old idea that used to be popular in the United States that was called a Right to Privacy. I'm not really a fundamentalist, and cryptographic technologies have always been a debated subject. Some people care, some people don't. The point is that folks should be able to choose to have a private conversation if they want to, and I'm trying to help with that.

Can't Bad People use this to secretly talk about Bad Stuff?

This is the big debate about the privatization of crypto, and it was talked about a lot in the early 1990s. It still goes on, but basically the genie is out of the bottle. In societies where folks enjoy personal freedom, they are free to choose to do good things or bad things. That's pretty much the deal with freedom. Everyone has to live with the consequences of their actions.

Why are you giving talkLock away?

Call it a random act of benevolence. I like making things and sharing with other people. I've been given a lot and I try to return the favor. The GNU Project has lots of great programs available with source code, such as Java and the Linux operating system, that folks have given away to the rest of the world. I use the same license for talkLock that is used for most of their programs, a license called the GPL, the GNU Public License. A copy of the license is distributed with the talkLock sources. You can read about the GNU philosophy on the web.

So what do I do with this stuff?

Thanks for enrolling in our sociological experiment, and welcome! The easiest and most fun thing to do initially is probably just to point the browser on your phone to http://marmot.dudeabides.net/talkLock/talkLock.jad and install talkLock. Play around with it. If you want to try some development, install Netbeans with Mobility Pack from http://www.netbeans.org on a computer. There is a tutorial on the Netbeans site for starting a Mobility project. You have to name it "talkLock", because Java cares about project names, program names, file names, and things. Then download the talkLock.png and talkLock.java files from marmot, and copy them into your NetBeansProjects/talkLock/src directory. Boom! You are ready to start editing the talkLock source code, doing builds, and testing in the emulator. You can also get everything from the Sourceforge download area in a tarball, but the newest stuff is on marmot.

Are there any better instructions?

Sorry, not yet. Every time I think about writing documentation, I think about the fact that talkLock doesn't have basic functionality yet, and do some more coding instead. Once I get to 1.0, I will try to flesh out the docco.

Okay I'm messing with this thing on my phone. Does it do anything?

talkLock is truly pre-alpha, so you might just have to try some of the options and see what happens. Here are some things to try at the time of writing of this FAQ: If you choose "record test", your phone should record some audio and play it back. Which build you try and the speed of the cpu in your phone might vary the length of the recording, usually it's less than 10 seconds. If this works, then talkLock will probably work on your phone when it hits version 1.0. If that works, try "testing whatever". That will send the audio you just heard to the marmot server. When that's done, try "get audio", and your phone should download the audio from marmot, and play it back. At the time of writing, this isn't working yet. The audio is getting fubared when it gets http POSTed to the server. **UPDATE 10/10/08** This is no longer true, "get audio" works now. **UPDATE 11/05/08** None of this is true any more. Check out the release notes in the download area on the Sourceforge project page, or my blog, for updates.

Hmm, I ran talkLock, and now my phone doesn't make sounds anymore. WTF?!

Yeah, this happens. talkLock labs has generated a lot of flipper babies. This is actually due to buggy MMAPI 2.0 implementations on different phones. Try warm booting or cold booting your phone, or taking the battery out and putting it back in, and running a different program other than talkLock to make sure audio is happy on your phone. WELCOME TO THE WORLD OF THE FUTURE.

I ran talkLock and now my daughter is pregnant and the money is missing out of my underwear drawer.

*shrug*.

What phones do you test talkLock on?

Mostly a Blackberry Pearl 9130. We try it sometimes on an LG CU-500, there are some hacks in the audio handling code to make it work on both, but that will probably need a lot of work to work on lots of other phones...

What is the current status?

Watch the news area on the Sourceforge page, or my blog, or email me.

I compiled talkLock on my PC. What do I do now?

Put the talkLock.jad and talkLock.jar files on a web server, and point the browser on your phone to the .jad file, and it will install if you have a J2ME, or mobile Java, phone. If you don't have a web server get ahold of me and I'll put it on marmot for you.

I'm running talkLock in the Sun/Netbeans emulator or the MPowerPlayer emulator. It doesn't do very much.

Neither emulator has implemented MMAPI 2.0, which is the part of mobile Java that lets you record audio. The emulators don't do network stuff on my machines either. They are handy for GUI development though.

So how do you test then?

Edit code in Netbeans, and then use the "Deploy" feature. This compiles a build and scp's it to your web server with one click. Then I point my phone at the .jad on the web server, download and install, the phone reboots, then run talkLock and try stuff. It's a slow build-test-debug cycle, but it's the only way to do it.

How do you cope with this psychologically?

With varying success. Lots of Diet Coke, coffee, and Marlboro Lights have been consumed to aid this. Riding a bicycle or shooting guns seems to help too. I recommend graduating from psychotherapy *before* doing any mobile Java programming.

Do you have any kind of human support structure?

Yes, it's a necessity. My girlfriend is always encouraging and talks me down when necessary. I also have a Guru. This is the person who knows nothing about mobile Java code, but yet can look at my code and say, "Oh, dude, just do ..." and it works.

Tell me more about this Guru.

The Guru got me unstuck many times, yet the empty POST issue was the sickest. talkLock POSTed successfully to my web form, but the POST was always 0 bytes. When I POSTed from a PC web browser, it always worked. So the Guru grabbed the sniffs of the two POSTs, and changed the web browser headers. I had been experimenting with this for 6 weeks or so, but it never occurred to me to echo the sniffs to telnet to speed up troubleshooting. He started echo'ing them to telnet to port 80 on my web server, making scientifically controlled changes until he found the header setting that broke POST. echo'd the talkLock sniff POST to telnet with that change, et voila, talkLock POSTed the Base64 encoded audio data to the web server.

Sounds technical. So when I run talkLock, and choose the "show recording size" option, I get a screen that says, "Had an exception...", and in the middle it shows the byte size of the recording.

It's not really an exception. In mobile Java, it's easy to put something on the screen for a few seconds by using an Alert(). I wrote an Alert() to give me debugging info when the code hit an exception. I found it so handy that I made it a method so that I could just dump something to the screen real quick using the ExceptionAlert("text that I want to print") call. It even runs in it's own thread so that "The System" leaves it on the screen long enough to read.

What is "The System"?

In mobile Java, your program isn't a standalone program, it's a MIDlet. Your program can only do what its inheritance as a MIDlet lets it do. This is neat for things like event handling, as MIDlets are pretty much forced to be event-driven, and event handling is for free. But you are also often forced to move processor-intensive work out of your main program loop and into separate threads. If you do not do this, "The System" will clobber the job that was in your main loop that was taking too much time/cpu. It must have to do with task switching, try Googling for the IBM paper on the MIDlet life cycle.

What does "Zap Gremlins" do?

If you ever have to use that option, you will know. For BBEdit users, it doesn't do what you think.

Where is the main() loop?
Yeah, I know, right? This has to do with the MIDlet lifecycle thing. If you define a class that implements Runnable, then make the run() method do stuff that is CPU intensive, and define a quit() method or similar, you can move your big jobs into a new thread. This lets you then start something that has a while() or main loop of some kind, and your MIDlet can kill it by calling YourRunnableClass.quit(). It's sick, I know. The trick is, your MIDlet constructs an instantiation of your class, then constructs a new Thread and feeds your Runnable class to it. Like what? Like this: Thread MyMainThread = new Thread(MyRunnableClassInstantiation); Check out my blog or the sources, they might help. It took me about 10 months of screwing with MIDlets to figure that one out.

What does the "Big Red Button" option do?

Do not push the Big Red Button.