Wednesday, July 30, 2008

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.

Thursday, July 10, 2008

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.

Wednesday, July 9, 2008

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 :)