Eyes-Free: TalkBack And Shell Improvements

Here is a brief summary of updates to Android's eyes-free tools--- including TalkBack, and the Eyes-Free Shell from the last two weeks.

TalkBack

  • Speech during a phone call is now re-enabled.
  • Turning the screen on/off is spoken. This announcement includes the ringer mode/volume.
  • Changes in the the ringer mode - silent, vibrate, and normal are now announced.
  • Unlocking the phone is announced.
  • Other Android applications can programmatically discover if TalkBack is enabled.

Eyes-Free Shell

Now that applications can programmatically discover whetherTalkBack has been enabled, configuring Eyes-Free shell to become your default home screen has become a lot easier. In a nutshell,if you are a TalkBack user and install Eyes-Free shell, hitting the Home button will bring up the eyes-free shell, ---no configuration needed. Note that you can always get to the default Android home screen by long-pressing the Back button.

Share And Enjoy

Starting the 3.0 development of Microlog?

What should it take to upgrade Microlog to 3.0? A while ago I release V2.3.4 of Microlog. There was only one "small" change, the Microlog instrument and instrument example modules were activated once more. They had not been part of any previous 2.X release. But was it a good decision to make only a patch release for such change? I must admit that I think this was an incorrect decision. The change was big enough to make a minor release or even a major release. What should I do to solve the situation right now?

I think the best solution would be to make a major release, that is that I should make a Microlog V3.0. This makes it possible to make some other changes that I wants to do. The changes that first comes to mind are these:

  • Add the logging level NONE.
  • Remove the Android module
  • Remove the Amozon S3 module
  • Cleanup the PropertyConfigurator
  • ?
Some explanation might be in place. Adding the Level NONE gives the possibility to stop the logging without removing the logging from the code. This is sometimes used for production builds, with the possibility to enable logging after distribution. The feature has been asked for many times. To be honest I do not remember why this has not been implemented before.

Removing the Android module is for obvious reasons, since we have forked the Android parts this is no longer necessary to keep in the Microlog project. But is might not be obvious why to remove the Amazon S3 module. For me this was an experiment, but not something that turned out well. It is big and clumsy. A 3rd party library is used for the SOAP communication which also adds to the size. Fortunately it is kept in a separate jar. Thus only developers using the Amazon S3 modules are affected by this. Another drawback is that we need to maintain this module. I feel that I rather spend time on maintaining the core and other modules that are more important. But this is something that certainly is worth discussing. What do you think?

Cleaning up the PropertyConfigurator is something that I have wanted for a while now. When adding the hierarchical logging support in V2, I kept the original configuration possibilities. This is not wrong. However there are parts in the code that could be shared between the Microlog classic configuration and the new configuration. The parsing of attributes could be replaced by a separate StringTokenizer. All in all I think that the size of the configuration classes could be slimlined.

I guess that there are some more parts that could be improved and/or added to the list for Microlog V3. This was all that I could think of right now. Do you have any suggestions?

    Reading Properties Files on Android (Investigation for microlog4android)

    Today I have investigated the possibilities to read properties files on Android. In microlog4android there is no configuration possibilities via file as it is today. The microlog4android development team feels that we need to re-write the configuration from scratch. There are many reasons for this decision, for example there is the Properties class available on Android while in Java ME we use microproperties. These are my findings about properties files on Android.

    My first thought was to use the SharedPreferences class. My brain picked up this idea while using the SharedPreferences in another project. The SharedPreferences is used to read/write preferences for an Android application. The preferences are stored in an xml file that is put in the private directory structure of an application. You could edit the file by pulling it from the device or emulator using adb pull. After editing it you push it back using the adb push command. If you are using the Android Eclipse plugin you could use the file browser to do the same trick. But this is cumbersome to pull/edit/push the file and I do not really like to use XML for storing properties.

    But how do we do it in microlog? The properties are stored in a properties file that is put in the JAR or by setting properties in the JAD file. Both are easily edited in Eclipse without no need to pull/push the file. The same goes for NetBeans. The properties file is bundled with the jar. Why not do the same on Android? Time to Google again! I found out that there was primarily two ways of doing this:

    1. Using the AssetManager
    2. Reading a raw resource
    To test this I created a simple Android project in Eclipse and copied two microlog properties files. One was put in the /assets directory while the other was put in the /res/raw directory. The first thing that happened was that Eclipse complained about the naming of micrologV2.properties that was put in the /res/raw directory. It was kind enough to inform me that only [0..9][a..z] was allowed. Changing the capital V to a lower case v was simple. Now time to do some coding. The code for reading using the AssetManager looked like this:

    Resources resources = this.getResources();
    AssetManager assetManager = resources.getAssets();

    // Read from the /assets directory
    try {
    InputStream inputStream = assetManager.open("microlog.properties");
    Properties properties = new Properties();
    properties.load(inputStream);
    System.out.println("The properties are now loaded");
    System.out.println("properties: " + properties);
    } catch (IOException e) {
    System.err.println("Failed to open microlog property file");
    e.printStackTrace();
    }

    The code is dead simple and thank God for the Properties class, although microproperties would do the trick. The second way to do it is as simple as the first approach. The code looks like this:

    // Read from the /res/raw directory
    try {
    InputStream rawResource = resources.openRawResource(R.raw.micrologv2);
    Properties properties = new Properties();
    properties.load(rawResource);
    System.out.println("The properties are now loaded");
    System.out.println("properties: " + properties);
    } catch (NotFoundException e) {
    System.err.println("Did not find raw resource: "+e);
    } catch (IOException e) {
    System.err.println("Failed to open microlog property file");
    }

    Notice that I omitted the code for getting the resources, since this was part of the first example. Both ways seems to be good. But what to choose? Using approach 1) has the following advantages from a microlog4android perspective:
    1. You are not limited to name your file with lower case letters only.
    2. It is possible to use a default file name if the user does not specify one.
    But I probably will implement both solutions, since this gives the user a freedom to choose where to put the file. What do you think? Is there any other solutions that I have missed out?

    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

    Powered by Blogger