All remaining notes are now being written up into my final report. This blog is to serve as an archive for the earlier development of the project.
For more recent updates and information please visit the SumAntics website.
All remaining notes are now being written up into my final report. This blog is to serve as an archive for the earlier development of the project.
For more recent updates and information please visit the SumAntics website.
Apologies for the lack of these, there’s been various developments in different areas but none are complete as yet so I’d rather save it all for a longer explanation.
In one of my previous posts I mentioned about errors visible on the video screengrab. The first attempt to combine bluetooth, web search and image search resulted in this error concerning the image search code:

Basically, (and rather frustratingly) the image no longer exists, though Yahoo is still indexing it in their results - this results in the Processing app throwing out the error when it has no image to print and doesn’t know what to do.
I hadn’t spotted this error earlier as when I was testing the yahooImage search, I was using single word phrases such as ‘thomas’ and ‘volkswagen’ which returned a large number of (i assume reliable) results. The test combined with bluetooth queried “graeme old phone” which has only 7 yahoo image results (as opposed to over 1 million google image results, but I’ll discuss that later) with the 2nd one of those being one that no longer existed: (from yahoo image search in browser)

Additional code was necessary for the application to check if the image still existed before it displayed it. This operation was achieved with the NetUtil.exists() function, part of the Switchboard library.

This has prevented any further errors of this kind, and this function will likely be used again to ensure no old or expired links are used.
Through my last problem it became clear that I needed more than the one mobile phone I had been previously testing bluetooth on. As I’ve previously mentioned my personal iPhone is relatively useless for testing so I used 2 of my flatmates mobiles in addition to the normal K750i test device:

(left to right)
I noticed some differences in how quick the processing application was to recognize name changes of a device, if at all (the C902 required bluetooth to be switched on/off for the change to be recognised).
This is something I need to research in greater detail and ideally get some reasonably scientific results of update times and observations. I would also like to test out more modern smartphone devices likely to be used by my potential audience.
Through previous testing I noticed that the device name of my test phone (see this post) always resulted in ‘Graeme old phone’ in processing, despite me changing the name of the device a couple of times. Initially I put this down to the age of the device and although seemingly reliable was not updating it’s device name correctly. It was moreso highlighted when testing another phone - instead of the device name it displayed the model code ‘C902’ (the phone was a Sony Ericsson C902) - so I became suspicious that the Processing application was not reading the device name correctly.
To test this I ran bluetoothview software I had previously tested (see these posts) as it displayed all data available about detected devices,.

As the processing application always displayed ‘Graeme Old Phone’, it was obvious it was choosing to display the Device Description rather than Device Name. This was confirmed by additional testing of the Sony Ericsson C902 as mentioned before, which displayed Device Name = Alex and Device Description = C902.
This was initially quite a worrying decision as I’d been heavily relying on the bluetoothDesktop library within processing, and in reflection is an issue I should have looked at sooner. I checked over the code of the early bluetooth detection versions I’d used (as the bluetooth code was near identical in the later more complex apps with websearches) and could see no explanation for the program to choose the device description instead of the name.
This meant I had to delve deeper, into the java code of the bluetoothDesktop library. I was skeptical I would be able to do much as I know very little about the inner workings of libraries, but scanning over the code of the ‘device’ file I noticed a search command which initiated through an array of ‘…SERVICENAME, SERVICEDESC (highlighted below), PROVIDENAME’

I removed the latter 2 strings, leaving only ‘SERVICENAME’, hoping that this would command the search to find the Device Name only.

Success! through part fluke and some investigation the processing application now successfully reads only the Device Name of the surrounding devices.

And checked the modified libraries in my latest application code:

Previously the processing results from a web search have been ‘printed’ out as one long string, this was satisfactory in testing but to achieve the desired visual (flash prototype to come) changed needed to occur.
My next target was to separate each individual results separately so they could be positioned in different (random) places, rather than in a list.
When the request is passed to the switchboard library to execute the yahooWeb search, the results are passed into an array, where they are visible in the console printed as:
[1] Result one name
[2] Result two name
[3] Result three name
Previously those strings had been joined together and printed using the ‘join’ function. Using the following code the results now print separately in random places:
for (int i=0; i != word.length; i++) { text(word[i], random(width), random(height)); }
This is succesful and achieves what I wanted. The next step was to hide older results so the screen did not become cluttered with results (as pictured) Ideally I wanted old results to fade away, so a transparent layer was printed inside the for loop. This combination of code resulted in the desired visual I had set out to achieve for the text results.
The next stage was to combine this with the bluetooth search, so the executed search was of the nearby bluetooth device names. To do this I implemented the new code into the existing bluetooth/web search split application, and to take advantage of the random positiong, designed a larger lower area to display the results.