Ego Surfing - Microlog4Eclipse

Sometime I do some ego-surfing. I check if there is anything written about Microlog or any other open source projects that I am involved in. One funny thing is that I found the podcast that I and Darius Katz was part of as a ringtone. Maybe it is a bestseller? :) But I just found a more serious project, namely the microlog4eclipse project. It is an Eclipse plugin to simplify the usage of Microlog. Or as it say on the project page "Plugin for j2me microlog logger based on android adt plugin". I wonder if they are using the Android part of the Microlog library. There is no download available at the moment. I will investigate this further. Curious to check it out. It is interesting that someone is actually writing a dedicates Eclipse plugin for Microlog.

Some Words about Microlog and Some Maven Stuff

As you faithful readers know, I am a believer in “Release early, release often”. Therefore I have tried to streamline the release procedure as much as possible. It must not feel like a burden to do a release. In fact it should be as fun as watching a comedy film, almost at least. But this time it was not very fun.

About two weeks ago, one of my fellow Microlog developers committed some changes. It was time to make a new release! I always start out with the deployment of Maven artifacts to the Sonatype repository. Ever since I changed from using the website at SourceForge as a repository, to the Sonatype repository this is a process that works like a charm. It usually takes a little more than two minutes to do this. After that point the artifacts are available on a Nexus staging repository. If something is wrong, you can drop the release. If  the release seems to be ok, you have to close and promote the artifacts. When you close the staging release, a validation takes place. It checks if everything is ok.

The validation process has always worked for me since I first got it right. But not this time! It was complaining about missing information in all the module, information that is available in the parent module. As a coincidence, or not, a discussion about this was started on the Sonatype forums. As it turned out, this was a bug in a new validation scheme. There was a workaround, but I did not feel that it was worth it. From my experiences I could conclude that the folks at Sonatype usually fix this in a day or two. This time it took some days more.

When the validation bug was fixed it was time to give it a try again. This time the validation was complaining about a file not being signed (site.xml). A file that should not be signed, at least not according to me. This was part of the parent module. To get rid of this problem I decided to make a new sub-module for the site generation and try if I could sign the file this way. After a while I was able to sign the file. However now the site was not generated correctly. Not good! I moved the site.xml file back to the parent module, but kept the module since I thought the site generation was good anyway. The site generation worked again, but the file was not signed. Time to google. Now I found a solution that should work; disable the deployment of artifacts from the parent module. It worked, almost anyway. Now none of the artifacts was deployed. More googling. Aha, it is possible to disable the inheritance of some build plugins. Now it worked the way I wanted. Nice! The process of finding out how this should be done took me “only” about 4 hours. But there was one bonus; I could now disable artifacts modules that was not very useful to deploy. For those who wonders how to disable artifacts deployment, take a look at this helpful article.

Finally I managed to make the release and deploy the artifacts to the Sonatype repository. The artifacts are there in Maven central as well. For those of you who are interested, the version is now 2.3.5. Enjoy!

Eyes-Free Updates: Marvin And TalkBack Simplified

We routinely push updates to our access tools on Android; usersget these updates automatically via Android Market updates. Wejust pushed out updated versions of TalkBack, our Open Sourcescreenreader for Android, and Marvin, the Eyes-Free shell. Hereis a brief summary of these updates:

  • Android applications can now programmatically discover ifTalkBack is running, thanks to the latest changes inTalkBack. From an end-user perspective, this means that you nolonger need to configure Eyes-Free shell via EyesFreeConfig tobe the default home. If you run TalkBack, and have EyesFreeShell installed, then pressing Home automatically givesyou the EyesFree Shell.Remember, you can always get to the default Android Home bylong-pressing Back.
  • EyesFree Shell now includes a touch-based shortcutsmanager. Until now, shortcuts needed to be explicitly configuredby editting an XML file on the SDCard. With the recent EyesFreeupdate, you can interactively define short-cuts via a touch-basedShortCuts manager. By default, we have assigned shortcut1 to the ShortCuts manager; so to invoke this newfeature, do:
    1. Stroke left (4 using stroke dialer notation) toenter the shortcuts screen.
    2. Stroke up and to the left (1 using stroke-dialernotation) to invoke application ShortCuts Manager.
    3. Use the trackball/D-Pad to configure each of the 8 availableshortcuts.

Marvin: We hope this gives some minimal relief to the painin all the diodes on your left side.

Silencing Speech With A Wave Of Your Hand On Android 2.0

Update To Android Access: TalkBack

Smart phones tend to be short on physical buttons --- evendevices like the G1 or MotoRola Droid have very few buttons when thephysical keyboard is not open. This provides interestingchallenges when designing an efficient eyes-free interface ---especially given the old maxim Speech is silvern, but silenceis golden!.Said differently, once you have built a systemthat talks back, the first thing you want to build is anefficient means of silencing spoken feedback.

Early versions of TalkBack on Android skimmed by without astop speech button --- you basically moved from one activity toanother,and the speech produced by the new activity effectivelystopped ongoing spoken output. However, as we make more and moreapplications work seamlessly with our Access APIs, it's alwaysbeen clear to us that we need a global stop speechgesture! Notice that I said gesture --- notkey --- stopping speech is a critical function that we'dlike to enable without having to pull out the physical keyboard,and something we'd like to have devices without a physicalkeyboard.

In the spirit of the dual to every access challenge is an opportunity toinnovate, we recently launched a new experimental TalkBackfeature on devices running Android 2.0. Devices on the Android2.0 platform have a proximity sensor on the top frontleft corner of the phone --- this is typically used to lock thescreen when you're holding the phone up to your ear when on aphone call. As the name implies, the proximitysensorfires when you get close to it --- you can activate itby waving your hand close to the top left corner of the phone. Asan experimental feature, we have configured the latest version ofTalkBack to silence ongoing speech if you wave your hand infront of the proximity sensor.

Note that this is a new, experimental feature --- it'ssomething that we welcome feedback on our public Eyes-Free GoogleGroup. We'd like to know if you accidentally activatestop speechbecause of this new feature. In having usedit for a few weeks, I find that I am not triggering itaccidentally --- but that might well be a function of how I holdthe phone.

What Devices Does This Available On?

Note that at the time of writing, the devices that have aproximity sensor that I have used this on include:

  • MotoRola Droid from Verizon
  • Google NexusOne

Note that the G1 and other older Android devices did not havea proximity sensor.

R.I.P. Kenai - Microlog4Android has been Moved

I admit it. I was wrong. It is not business as usual for microlog4android. Yesterday I got an e-mail explaining that Kenai will be shutdown. But fortunately there are other hosting options. I wanted to move the project as fast as possible and have a simple solution. I was recommended by my esteemed colleague Hugo about using Google Code together with GitHub. Google Code allows a project to use other service, such as GitHub, when Google Code  is not sufficient enough. Moving the source code was rather simple. The part that took time was to generate a new SSH key for my new computer. The nice thing with git is that all the history is preserved.

To move the source code from the Kenai git repository I did the following:

git pull git://kenai.com/microlog4android~source-code-repository

git remote add git@github.com:johanlkarlsson/microlog4android.git

git push origin master


It was as simple as that. The first line was needed to pull the source code out from Kenai, since I had no backup copy on my new computer. So for a user with the code on his computer, it would be even simpler.

Right now it is time for me to relax a little. I know I have a lot of things to do tomorrow at work. Please stay tuned for more updates about microlog4android.

The project:
http://code.google.com/p/microlog4android/

The source code:
http://github.com/johanlkarlsson/microlog4android

The Future of Kenai?

As I wrote in an earlier article, the Android part of Microlog has been forked into a new project. The project is hosted on Project Kenai beta. This is Suns offering for open source project. With Oracles acquisition of Sun this project seems to be endangered.  But I am not sure how it will be affected. If it is going to be changed, I sure hope that the projects will get support for the migration if any. For more information, read the article about the subject on Kenai's blog.

I guess we have to continue with business as usual for microlog4android.

1Vox --- Your Query Is Our Command

Video: 1Vox --- Your Query Is Our Command

1 Video: 1Vox --- Your Query Is Our Command!

Device Used: Motorola Droid on Verizon

Speech interface designers often express surprize at the the factthat the average blind user rarely if ever uses spoken input. Butwhen you come down to it, this is not too surprizing --- giventhat the eyes-free user has speech output active, the overall system ends up talking to itself!

To show that these conflicts can be avoided by careful user-interface design,we demonstrate 1Vox --- our voice-search wizard for the Marvin Shell.

  1. You activate 1Vox by stroke 9 on the Marvin screen.
  2. You hear a spoekn prompt Search
  3. You hear a little auditory icon when the system is readyfor you.
  4. You speak oft-used queries e.g., Weather Mountain View.
  5. You hear a short spoken snippet in response.

We called this widget 1Vox --- in honor of the Google onebox foundon the Google Results page.

Author: T.V Raman<raman@google.com>

Powered by Blogger