Note for future self :) (and yesterday's self)

On a GWT ListBox widget, it is natural to write 

listbox.addChangeHandler(new ChangeHandler() {

@Override
    public void onChange(ChangeEvent event) {...}

}

But do not forget to 

listbox.addKeyUpHandler(new KeyUpHandler() {
 @Override
 public void onKeyUp(KeyUpEvent event) {...}
}

for else, the event "the listbox has been selected and value is modified with the keyboard arrows"
 will not be handled even though the value "changes".


Now, shouldn't the ChangeHandler be called ChangeByMouseHandler ? No ?

• use TLS props.put("mail.smtp.starttls.enable","true");
• use port 587  (not 25, not 685)
• use a javax.mail.Authenticator
• add the necessary certificates to the keystore used by your VM
  
  On a *nix system, try   find / -name cacerts |more
and find / -name .keystore |more

• You will find the certificates from your browser settings

As I was installing an Alfresco on a Linux machine, I learned AGAIN.
Damn Alfresco, I know it since the "not yet 1.0" version (was 0.6??) and everytime I use it, I learn new stuff.

Problem:
It all started with my test user seeing mixed languages, English and French in the web interface despite the choice of English at login time. 


OK, problem is solved but it was a pita as I had to "DROP DATABASE alfresco;". Was empty, fortunately.

Short version :
As the "system spaces" like "data dictionnary" are created upon first boot of the webapp, you must not leave YOUR language packs (.properties files) in the .war file. Main culprit was bootstrap-spaces_fr.properties in alfresco.war\WEB-INF\classes\alfresco\messages\

Long version :
I installed on a Linux machine, not using the 1-click installer provided by Alfresco but it would not have changed a thing considering it's the .war file the guilty.

I am not a US resident, nor EN.
I use a Linux VM that I have not set up, physically located in fr_FR, which I tend to forget as I mostly write/code in english (sometimes frenglish).

On first start, the .war file deployed in Tomcat is unpacked and its content is used by the initial process -- including the deadly bootstrap-spaces_fr.properties. 

This process creates what I'll call the "system spaces" (like "data dictionnary") and they are created accordingly to the locale whenever the files are available. If not, the default are used and they are plain English, which is better for a system to be used by people around the world.

The culprit file can be found at alfresco.war\WEB-INF\classes\alfresco\messages\bootstrap-spaces_fr.properties. I moved all _fr.properties files to a subfolder -- just in case.

My advice is to remove all I18N files from the .war before to use it.
Or, you'll have to drop the database and empty the alf_data folder and of course, bear with another looong first start. 

Hint: Setting the JVM's locale to "en_US" could be an option (not verified) at install time.

This post is not about teaching a phone to eat all your waste :)

What to do of "old" phones

As time goes by, one (developper) gets more and more smartphones and specs evolve, leaving older phones behind in terms of daily use.

Thus the question that arises is what to do of "old" phone ?

Of course, the quick and easy answers are :

• let it rest in a drawer for ... hum ... future use.
• give/sell it to someone

What else ... ???

HACKING !

There is a computer in the phone ! Remember ?
Depending on the phone model and the work done for it by the wonderful community, you can :

• install another system, like Ubuntu on a Nexus One
  
• install uncommon services
  
• use as a remote home-monitoring system (camera to take pics periodically and upload to web if delta)
  
• Experiment (roms, ...) : nice way to learn
  

To give an example to that second point, it would be to install a web server with a few pages, tie it to a dynamic dns (you'll need to configure your box/modem of course)

There is web servers for Android, you are not forced to install Ubuntu + Apache :) or even to cook your own.

It all depends all your available time

That is how innovation happens.

Maybe one day, we'll see Tomcat running on a mobile phone without slowing it to death.

Today,
I have decided to publish a small app dedicated to spoonerisms (in French).

It is titled "Contrepeteries".

Another day, another occasion to learn.
I built apps mostly for myself so this was the occasion to 'market' an app.

From my coder point of view, it is quick but not as direct as should be.

Guess what, after all the ProGuard errors solved (thx to Guillaume of Capptain), I had errors on installing my own app !

"not signed correctly"

"Damn how can it be ?" I thought, considering I was using the very last version of the tool provided.
Isn't it checked right after I upload the apk ?

Based on what I've read on the web and this experience, what one must do is :

• clean the package before signing (remove useless files)
• uninstall from your test phone before to install from the market.

Coming back to the ProGuard point, as I use Capptain and AdMob on this app, a working proguard configuration can be found at https://docs.google.com/document/d/1r-zv0XDsJNDmkuhQYTNRW2Tv46WOSBV0QAA3hHcN3IM/edit?hl=en


Find Capptain at http://pages.capptain.com/homepage_01/

Find my app at https://market.android.com/details?id=org.wadael.contrepeteries

I have read a post from Eric Vetillard (javacard expert amongst all and a colleague), about smudge attack against android terminals.

To quote his post :

this attack targets the authentication pattern that is used to unlock an Android phone. .... owners also know that smudge really is dangerous for this authentication technique. I have tried it with a colleague: after picking up my phone, it took him 3 tries to get my combination

Why that ? Because :

• fingers are sweaty or greasy or both (weather is good in the south of France, isn't it Eric ?) so they leave traces on our shining screens
• there is only one path to unlock the phone
  
• this path 'looks' always the same on the phone
  

So, that post triggered some thinking. I think I've found possible solutions :)

First proposal
The pattern has to not be static. To reach that, my proposal is to have the dots or equivalents to be in a circle that will rotate.
Not randomly but more like a compass.
Just like a compass has an arrow, an arrow is used so that the user has a landmark and not get lost
Then either link the dots to unlock. (5 tries are allowed instead of 3)
With that, you will never not touch the screen at the same place (unless you unlock only at the very same place, with the same position of the body)
Derivated proposal :
A keyboard which keys are never at the same place, used to enter PIN code.
Most of us already know that, as this is used by online banks. The proposal is to integrate it as a proposed unlocking system.

Third proposal, I call it the psycho-camembert :)
It looks like a camembert (or pie chart) with equal parts coloured differently and having patterns (stripes, dots, etc ..).
This camembert is centered on the screen. Those parts are displayed in a random order.
To unlock, parts have to be dragged toward the exterior. Therefore, the traces on the screen are all lines from the center to the outside.
Of course, its a memory thing and one will have to memorize a colour order. Sorry for those who cannot distinguish colors, thats why patterns can be added.

I hope this contribution will find its way to the good ears.
Let's be frank, all the better if it brings me an all-inclusive invitation to IO 2011 !
I really liked San Francisco and have no idea on how to deserve an invite for next year.

Feel free to indicate me the classes of the API to look at in order to implement it.


Cheers,

Jérôme


Eric's post is here http://javacard.vetilles.com/2010/10/18/smudge-attacks-on-android
You can follow Eric on Twitter : @evetillard http://twitter.com/evetillard

Hello,

There is now a wave about the wave robot framework ! But, as scripts do not work in this blog, got to Wave and search for WadRobotFramework