It was the ability to change what prefix to remove. As i live in Denmark, whenever i make a call on a land-line there is no reason to dial +45, which is the danish country code. Actually the plus is converted into 00 as well.

But Eli needed the prefix 08 to be removed.

And i guess that there are a lot of other prefixes that could be removed and + shouldn’t always be converted to 00. So I decided to implement this feature.

Whats new

• It now remembers your settings
• It possible to choose a prefix to remove
• its possible to decide what + should be replaced by.
• I slapped a GPL V3 license on it

The files

dtmfdialer jad file

dtmfdialer jar file

dtmfdialer source code

Unfortunately it wasn’t just a 5 min hack. There were two major challenges.

Persistence

In J2me access to the filesystem is restricted and requires all sorts of security permissions, but every application has access to a “RecordStore”. The RecordStore (RMS) only allows byte[] to be stored, so you have to marshall/unmarshall every piece of data at quite a low level. I haven’t persisted any data in the first version, as this is indeed tedious to work with. But not having persistence for a prefix remover functionality wouldn’t be of any use. You would have to enter the same data every time you used the application and then it would be faster to just edit the number to call.

Netbeans mobility pack

It was supposed to be so eays.

But the floweditor somehow did mess up and didn’t generate the code, so the flow diagram and the sourcecode were out of sync, and i didn’t see any way to “resync”/”regenerate code/diagram”. This was cause for a lot of frustrations.

Originally i made it with netbeans so compiling and editing the generated code were best done in netbeans. But if i ever were to mess with it again i would seriosly consider “porting” it to J2me Polish or just “vanillia” j2me. As i really really don’t like the netbeans editor.

update : Eli found a bug in the prefix substitution, i fixed and uploaded the new version (June 27, 2009, 21:17)

I got around to hacking some code together for a simple DTMF dialer on the mobile.

Its functional and simple. Enter a number, click ok and it will play the correct sequence of tones. It’s even possible to tweak the duration and pauses.

I have only tested it on my own Nokia 6300, but as far as I can tell it should run on most java enabled mobile phones.

Here are the jad and jar files. If you want to run the program download them to your mobile and have fun.

• dtmf jad
• dtmf jar

At the moment it converts + to 00 and removes +45, as this is appropriate for a danish setting.

Here is the sourcecode if you need to make changes.

DTMF sourcecode

Using Netbeans

I used netbeans 6.0.1 and it was a mixed pleasure. Creating the the flow using a drag’n’drop interface, is well nice for something small and simple as this, but I found that it soon got frustrating. There’s no API to look in, and you have to use the mouse all the time.

This is the basic flow of the midlet. It was very quick to set this up, and it were indeed a pleasure to start with. Somewhere along the way a made a mistake, which the flowdesigner and codegenerator couldn’t handle. And no matter what I tried I couldn’t get rid of it, I knew exactly what i was. I had misnamed a variable and managed to let the generated code go into a never-ending recursion. (something along the lines of: private TextField foo() { return new TextField(Foo);} ). But no matter what I tried it just wouldn’t get back to normal. In the end I just created a new project, remade the flow stuff to what you see above, and copied a few functions over.

And the flowdesigner is quick to work with, but I get a nagging suspicion that if you are going to make something a little more complicated than this it will be an annoyance. You might know exactly where and what to change in the source code, but do you remember where to point, click and edit in the designerinterface? Another critique is that even when you know what to do, your workflow gets abruptted by having to constantly shift hands between keyboard and mouse.

To Netbeans defence i must say that I am used to using Eclipse, and changing to another IDE is in it self a frustrating experience. Whats the shortcut for blah, where do I set this. And its quite possible that I just didn’t know enough about Netbeans structure and shortcuts to feel at home.

Credit goes out to : openclipart.org for the image of the phone and dialabc for the soundfiles.

So I started to recreate the classic oldskool game Xonix, it’s a game I really like. So simple and addictive. It’s not the first time I’m coding it, I have made it as an applet about a year ago (Xonix applet). As well as being a fun game to play I find it a fun game to code too. Though I have had my share of frustrations. The basic functionality is a fillalgorithm, that has to fill an area on both sides of the line / trail you make with the ‘pilot’. This has to be fast and efficient – nobody likes a game where you have to wait for updates.

When I first made the game i found a neat fill-algorithm. (flood fill wikipedia). So it should have been a piece of cake to implement it in J2me, its java… I deliberately choose not to reuse old code, as I feared it would be horrible ugly. And a course in datastructures and algorithms should have given me some tools to make a better / cleaner implementation. Then the woes began. J2ME, has no ArrayList it has vector and a stack, and the are not generic so no typecasting. I made a version using Vector, but somehow i managed to use all the memory. When I look back I have a nagging suspicion that the Vector isn’t to blame – but rather me that somehow feed it to much data. No matter what it was I got rid of the Vector and started using arrays, and using indexing like in images or c-“double”arrays (index = x + y * WIDTH). Finally it could fit in memory.

And then I started looking for graphics, a nice game really depends on nice sprites – much more than a beautiful algorithm. I couldn’treally find any and its quite painful, at least for me, to make sprites. It gets real ugly, real fast – hmm no it gets real ugly real slow, because i’m no good at creating graphics. Well the frustrations grew and I ending up abandoning the project. The basic gameplay works, but is buggy and as mentioned the graphics sucks.

All in all it was quite fun programming, and some day i might give it another go.

I bought myself a new mobile, a Nokia 6300, it’s got all the bells and whistles. Hmm well at least those I could afford. I choose this mobile because it has : Java, mp3 -player, bluetooth and memorycard.

• specifications from nokia
• review from mobilereview.com

I must admit that i might be a bit of a nerd, so I just had to code something for it. And after “hello world” I found a small and some would say useless application to code.

FreeVibes

I must say I got inspired by vibelet and the article in wired ( Hold the Phone, It’s a Sex Toy ). As the title suggest, its well vibrating. I think that vibelet – though i haven’t seen their program, must be making quite an profit. Because getting a java-enabled phone to vibrate constantly, is quite easy.

So now its Time for FreeVibes, a free software version.

That’s the fancy splash screen	And when its in vibrating mode, this little duck is there. And now why a rubberduck ? ( answers )

If you want to try it out, here are the jar and jad files. Just put them on your java-enabled mobile phone. I have just tested it on my telephone, It should work on any new mobile (with java) :

Jad File
Jar File
Source code

Installation

1. Download the jar and jad file and place them on the phone in the same directory.
2. Run the applet
3. Have fun

Technicalities

Getting things to work with ubuntu feisty fawn.

I use SUNs java 6 and the wireless toolkit for the J2me.

Nokia has a nice area with information about coding for their phones (forum.nokia.com). But i didn’t have any success using their eclipse plugin and carbide.j seems to be a windows application. But eclipseME worked like a charm.

When setting up a device for EclipseME i had to make sure that it was MIDP 2.0 and CLDC 1.1. It wasn’t the default and the Nokia 6300 can’t handle MIDP 2.1.

They code and design is inspired by Nokias tutorial on making MIDP 2.0 games.

The images I used are from the openclipart collection, hacked together with GiMP and Inkscape, and I use obexftp to transfer the files to the phone.