News at last

Finally there's a little bit of forward movement on the Masters course - we've got the dates for the seminars sorted. Of course, the first one is scheduled for one of the few days in the next few weeks where I have something on that cannot be cancelled or moved at all, but I guess that's life...

But at least there's stuff going on. In other news there, the collection of papers to do with SOA and the application of genetic algorithms thereto continues. There's been a bit more work done on this field than I'd anticipated, which was a little surprising, and it falls into two general streams.

One takes a composed service, made up of lots of interchangeable component services, and tries to work out the best combination of services given a specific set of requirements. This is pretty similar to work that I've done already in this area, so that's encouraging.

The second uses the genetic approach to try and combine services efficiently into a single component service. This looks fantastically interesting and useful, but it would mean learning a whole new mathematical language of combinatorial algebra, and then trying to code it into Java. Which is unlikely to take place over the course of a single, part-time year.

But hey - I'm meeting up with my supervisor soon enough, and we'll have a look through the papers to see if he thinks that the gaps I've spotted are (a) actually gaps at all and (b) big enough gaps for a research project.

7th Sea Dice Roller

Version: 1.0

Description

A dice rolling application for the now-defunct AEG game 7th Sea (website unavailable: domain has lapsed).

Users choose a number of dice to roll, a number of dice to keep, and

whether the dice explode. The results are displayed and the user can choose to add Drama Dice to increase the total.

Availability

Android Marketplace (search term: 7th Sea).

Requirements

OS: Android 1.6

Hardware: screen resolution 320x240 or higher (recommended 480x320 or higher).

Data usage: none (may be updated in future versions to use Random.org's randomiser)

Storage usage: none

Known bugs: none

Known issues: on altering screen orientation, current dice roll is removed.

Recent changes

Updated portrait mode layout to stop the Add Drama Dice button disappearing on some smaller screens.

Release Candidate #1

So, I've opened up the wallet and shelled out for the developer login over at Android Marketplace. Now it's time to put my mouth where my money is, so to speak, and actually get some content up there.

Now it gets to that point, it's all very intimidating! But sure, what is there to worry about? Apart from, you know, having any mistakes I made exposed to the general public? Um...

I've also been wondering quite heavily on the testing of apps. This first one, see, isn't really going to need that much testing: it doesn't do a great deal, see? But I've only tested it on the Android emulator bundled with the SDK, and then on one handset (and a powerful one at that). I know several people who would almost certainly help with the testing (and might even use it from time to time!), but none of them can easily connect their phone to my PC with a USB cable for debug purposes. The only real solution here, it seems, is to release it as quietly as possible, and hope that people won't flame me horribly if it doesn't work first time round. Not ideal, but hey.

You know what? A blog post would probably serve as a useful standby page for the app website. I should fix that up now...

Rather random

Someone got me thinking earlier about the random number generator that I've been using for the various dice rollers that I've written. Now, usually I'd just go with the default RNG for whatever platform I've been writing for, and that'd be that. I realise that randomisers can only generate pseudo-random numbers, though, but most of the time that's plenty good enough for our purposes.

However, I found a useful looking site today: http://www.random.org/, being operated from Trinity College Dublin. They generate truly random numbers from atmospheric noise, and there's an API to plug into to that can be used to pull sequences of random numbers over the Internet. Now combine that with a smartphone's data connection, and that would be a perfect dice roller! Of course, I'll have to think about things like user permissions (and give the user the choice to go online or not - particularly if they happen to be roaming at the time), but this could be an interesting little project to make sure that I'm reading data correctly from Android's http connections.

Not sure how much of a rewrite this'll end up being, though. Possibly fairly extensive...

Fragmentation

Usually a problem considered to occur to hard drives, I'm beginning to hear this addressed at the Android OS as well. It's a totally different context, mind: in this case it means the difficulty in developing applications for a supposedly unified operating system that in fact runs on many different devices of wildly differing specifications.

Take, for example, the dice roller app I'd worked on for a while. It was developed for a pretty standard screen resolution of 320x480, and the interface seems to fit quite nicely that way. Scale this up to the oh-so awesome HTC Desire, with a resolution of 480x800 (or whatever it is: it's ludicrous, for a phone!), and it looks even smoother.

The other day I tried to pop the same app open on the emulator running the specs of the HTC Wildfire. Oh dear. The screen is a tiny 240x320, which seems minute for a smartphone, and the app is unusable. Having looked at average screen sizes when I began the development, and settled on 320x480 as a useful size, it's a little frustrating to now discover that a newer device can't run the app. I can only imagine what other development teams who have put weeks and months of work into apps, now to discover that the new range of budget smartphones will require them to rewrite sections of the interface to make sure that they fit onto them cleanly, or they'll just have to put a minimum resolution requirement onto the app itself (I'm lazy: that's the approach I'll be taking, I'm afraid).

Service composition

Electronic journals are both big and clever, it seems. It's also very useful to be working from within the library, and thus gaining instant access to said journals from my own laptop: technology is a marvellous thing!

I've started looking into service composition techniques now, and they're looking to be really quite a complex beastie, particularly when you begin to factor in dynamic service composition which, for my sins, is what I'm attempting to research. Obviously, when you have a group of x services that can e combined in a variety of orders to achieve a variety of results, searches to try and combine them are going to need to be heuristic to some degree: the mind-boggling number of combinations rapidly rules out a brute-force search for all but the smallest number of systems. However, the number of combinations and techniques available for a heuristic search is also beginning to hurt my brain ever so slightly.

Fortunately, it appears that not many people have looked into the method that I'd like to look at (genetic algorithms). Unfortunately, this means that I'll have to start this all from scratch!