new milestones

Well I pushed a new build of talkLock out to Sourceforge. There are some new event-driven things happening, but mainly I successfully got talkLock to cope with the fact that different phones sometimes use different audio encodings.

It is ugly and hacky, but by using Manager.getCapabilities, I was able to tell whether talkLock was running on a blackberry or an LG CU500. The blackberry just does straight up wav audio, while the LG does amr. With this code audio recording and playback works on the LG as well as the Blackberry :)

This is cool, since in order to have conversations between phones with different encodings, the program will have to know what type of audio it is playing back. I really hope the LG will be able to play back wav that was recorded on the Blackberry. I think that playback is much more mature than recording in MIDP, so I am optimistic.

Now I am starting to work on the networking code. I won't really comment much on it, but after being mocked for a couple of days by Tomcat and trying to do things the servlet way, I have decided not to inflict that on others by writing the talkLockServer component in Java. Instead, I already have a little experience working with HTML forms using PHP, so talkLockServer will have a .php suffix.

Also I think that I will use some kind of database, maybe MySQL, to store and retrieve the hunks of audio data. Since it does some smart caching, I don't think the audio will actually get flushed to disk very often. If everything happens in RAM, it should be pretty quick.

I hope to finish "processing" and mulling soon and get some more code written.

slow on the uptake

Well, I've been fighting with talkLock, trying to figure out why my records get created in the RecordStore, but they are empty when I read them.

Then I remembered that the "Submit Form" command on the Setup page is what triggers writing the values to the Record Store. Aha.

So I fought with that for a while, trying to get the main program thread to wait for the Command Listener thread so that values are not read before they have a chance to get written by hitting the "Submit Form" command.

Finally I started reading about using threads to handle asynchronous things in MIDlets. It dawned on me that I am trying to do batch programming here. I started programming in the 80's when you had to do all of your event handling yourself.

Light bulb appears over my head.

In MIDlet land, event handling happens for free. But unless you do a lot of thread handling stuff, you are chained to using their event driven model. That is why all of the MIDlets that I have read code for have a basically empty main method. You let the Command Listener fire off events.

My problem was that I wanted to get things going without a Command event. I might look into that eventually, but for now, I am going to let the user kick things off by hitting the "Connect" command :)

Yay! I learnt something. It happens, but it sometimes takes a while. Maybe now I am prepared for an exciting career in javascript or gui programming of somekind.

bringing up the ui; using persistent storage; &c

Last evening was cool and rainy. I started the program "from the beginning", in other words, the end user experience that will be the release version of talkLock. So at start time there is the logo, and your server name, user name, and password are fetched from persistent storage, the "RecordStore". If they are not there, I wrote talkLockSetup(). talkLockSetup will give you a form (Form) with TextFields to edit your server name, username, password, and submit the form. On submission, the CommandListener will blow away any existing persistent records, and add your new settings. It's starting to feel like it does stuff and is a real program :)

I did have quite a bit of trouble with the damn RecordStore. It only takes one datatype (byte array), and though it claims to read and write to it, my byte arrays that I get from it are empty. I was assuming that the record IDs for a store that has 3 records would be 1, 2, and 3. That was probably not a good assumption to make. But we'll get there.

Once I get this RecordStore API down, I think it will be time for networking :)

recording and playback working

I pushed out a build and sources to Sourceforge.  Moved audio handling into it's own thread.  The "test recording" option records and plays back audio now :)

It worked great for a while on my Blackberry, however at one point the audio completely wedged and I had to pull the battery.  The implementation bugs I'm encountering are very discouraging.  I wonder how things would work on Openmoko.  It's C, and GTK.  Very tempting.

But I've invested a lot in this, so I'm going to keep plugging away.  Next is the network communication.

still poking at setRecordStream

I posted a question about the setRecordStream threading issue on the Sun CLDC and MIDP forum:
http://forum.java.sun.com

It's a very active forum, and I've started to post some hopefully helpful comments to others. Hopefully the open source newsgroup/mailing list/forum style of collaboration will help. I have also talked to folks on the Netbeans forums, but they are not very active as of Spring '08.

more experimenting - new release

There is a new release. I've been working on cleaning up the code and trying to take all the stuff that was working asynchronously (in separate threads) and pull it together. I still can't get setRecordStream() to work unless it's in a separate thread from the main program. Makes no sense yet.
I started playing with some UI stuff too. There is a spiffy icon now, and I'm using the logo image when the program isn't at the main List screen.

talkLock is on Sourceforge

Well the code is at a very premature stage, but now that spring is here I have temporarily lost some momentum. So in case anyone wants to help do some beating on these J2ME things, I went ahead and put up the sources and a build on Sourceforge. talkLock has a home now on Sourceforge. It's GPL so download the source and NetBeans with Mobility Pack and start hackin'. If you need an account to publish your builds and test on a web server, write me. marmot is where I usually publish my test builds and suck them down onto my phone. marmot will have a new home this week, so there may be some dns confusion at some point.
There is experimental audio recording and playback, no network code, and a very simple List interface. Also I went crazy with the threads, so everything is very asynchronous and bizarre right now. Enjoy.