Android IMAP clients review

My Galaxy Tab was run­ning Android 3.1 since I bought it. The includ­ed EMail client (not the GMail APP) was fine for me. Not as com­fort­able as a real desk­top EMail client (I use Sylpheed-Claws), and not as good as my web­mail inter­face (Horde/IMP), but OK to han­dle 100 – 300 EMails a day. I liked the split into day/week/month in the list-view for the EMails, being able to select a whole day (and des­e­lect a sub­set) for quick actions (delete/move).

Yes­ter­day I updat­ed the Tab to Andorid 3.2. While there is now a nice trans­parence effect avail­able in some places, and the Play-Store has a dif­fer­ent user-interface, the big dif­fer­ence for me is, that the behav­ior of the EMail client changed. When I view a mes­sage the message-list moves the message-list in a way that the select­ed mes­sage is in the first posi­tion of the message-list. This is annoy­ing, and I have not found a set­ting how to change this. This way I can not view the last dis­played mes­sage, select it (or not), view the sec­ond last, select it … and so on … and then delete all mes­sage at once.

I also noticed that the folder-list is mov­ing. I have not noticed a spe­cif­ic pat­tern, but when I return to the folder-list I found the incom­ing fold­er being the first one dis­played, even if I was in a fold­er sev­er­al pages down. This is annoy­ing too.

Well… this gave the oppor­tu­ni­ty to have a look at oth­er EMail clients. The first one was K‑9 Mail. The first bad impres­sion was, that the box­es to select EMails are too small. I select a lot of EMails to either delete them direct­ly (a sub­set of ver­sion con­trol com­mit logs), or to move them to a dif­fer­ent fold­er. It is a nice app, but as I need to select a lot, it is not real­ly suit­able for my workflow.

For the next app, Mail­Droid, I did not had the pos­si­bil­i­ty to accept the self-signed cer­tifi­cate of my IMAP-server, so I delet­ed it immediately.

The next app was Mel­win Mail (tri­al ver­sion). It is based upon K‑9 Mail. The message-selector box­es are big­ger, but the mesasge-list does not dis­play the full sub­ject. This does not allow me to see if I can delete the EMail unread or not. I also did not find a way to enlarge the message-list to see more of the sub­ject (and I want to have the font-size not too small). Well… this means it is not suit­able too.

I also want­ed to look at Kait­en. It is based upon K‑9 Mail too. Unfor­tu­nate­ly I do not find a tri­al ver­sion. Based upon my expe­ri­ence with Mel­win Mail, I do not want to pay for some­thing, I may not want to use. On the web­site I do not see a link to screen­shots or sim­i­lar, only a change-log.

All the “best EMail app” postings/articles I was able to find (and have a look at) told that K‑9 Mail, is the best free one, and a lot of peo­ple rec­om­mend Mel­win Mail or Kait­en. I can not agree for my work­flow. EMail apps have to go a long way until they reach a niveau which allows to han­dle more than a hand­ful of mails per day and a not so sim­ple work­flow like “read all EMails as they flow in”.

Based upon this, I switched back to Android 3.1 on my Tab. While the includ­ed EMail client is not per­fect (e.g. I can not select all EMails at once in search-results), it is still bet­ter suit­ed than what I have seen so far.

Unfor­tu­nate­ly I can not real­ly test 4.0.x on my Tab, the cam­era does not work in community-based Android 4.0.x ver­sions, and I do not want to miss the pos­si­bil­i­ty to do a video-call with my deaf brother.

Algo­rithm to detect repo-copies in CVS

FreeB­SD is on its way to move from CVS to SVN  for the ver­sion con­trol sys­tem for the Ports Col­lec­tion. The deci­sion was made to keep the com­plete his­to­ry, so the com­plete CVS repos­i­to­ry has to be con­vert­ed to SVN.

As CVS has no way to record a copy or move of files inside the repos­i­to­ry, we copied the CVS files inside the repos­i­to­ry in case we want­ed to copy or move a file (the so called “repocopy”). While this allows to see the full his­to­ry of a file, the draw­back is that you do not real­ly know when a file was copied/moved if you are not strict at record­ing this info after doing a copy. Guess what, we where not.

Now with the move to SVN which has a build-in way for copies/moves, it would be nice if we could record this info. In an inter­nal dis­cus­sion some­one told its not pos­si­ble to detect a repocopy reliably.

Well, I thought oth­er­wise and an hour lat­er my mail went out how to detect one. The longest time was need­ed to write how to do it, not to come up with a solu­tion. I do not know if some­one picked up this algo­rithm and imple­ment­ed some­thing for the cvs2svn con­vert­er, but I decid­ed to pub­lish the algo­rithm here if some­one needs a sim­i­lar func­tion­al­i­ty some­where else. Note, the fol­low­ing is tai­lored to the struc­ture of the Ports Col­lec­tion. This allows to speed up some things (no need to do all steps on all files). If you want to use this in a gener­ic repos­i­to­ry where the struc­ture is not as reg­u­lar as in our Ports Col­lec­tion, you have to run this algo­rithm on all files.

It also detects com­mits where mul­ti­ple files where com­mit­ted at once in one com­mit (sweep­ing commits).

Prepa­ra­tion

  • check only category/name/Makefile
  • gen­er­ate a hash of each commitlog+committer
  • if you are memory-limited use ha/sh/ed/dirs/cvs-rev and store path­name in the list cvs-rev (path­name = “category-name”) as storage
  • store the hash also in pathname/cvs-rev

If you have only one item in ha/sh/ed/dirs/cvs-rev in the end, there was no repocopy and no sweep­ing com­mit, you can delete this ha/sh/ed/dirs/cvs-rev.

If you have more than … let’s say … 10 (sub­ject to tun­ing) path­names in ha/sh/ed/dirs/cvs-rev you found a sweep­ing com­mit and you can delete the ha/sh/ed/dirs/cvs-rev.

The meat

The remain­ing ha/sh/ed/dirs/cvs-rev are prob­a­bly repocopies. Take one ha/sh/ed/dirs/cvs-rev and for each path­name (there may be more than 2 path­names) in there have a look at pathname/. Take the first cvs-rev of each and check if they have the same hash. Con­tin­ue with the next rev-number for each until you found a cvs-rev which does not con­tain the same hash. If the num­ber of cvs-revs since the begin­ning is >= … let’s say … 3 (sub­ject to tun­ing), you have a can­di­date for a repocopy. If it is >=  … 10 (sub­ject to tun­ing), you have a very good indi­ca­tor for a repocopy. You have to pro­ceed until you have only one path­name left.

You may detect mul­ti­ple repocopies like A->B->C->D or A->B + A->D + A->C here.

Write out the repocopy can­di­date to a list and delete the ha/sh/ed/dirs/cvs-rev for each cvs-rev in a detect­ed sequence.

This finds repocopy can­di­dates for category/name/Makefile. To detect the cor­rect repocopy-date (there are maybe cas­es where anoth­er file was changed after the Make­file but before the repocopy), you now have to look at all the files for a giv­en repocopy-pair and check if there is a match­ing com­mit after the Makefile-commit-date. If you want to be 100% sure, you com­pare the com­plete commit-history of all files for a giv­en repocopy-pair.

Wikipedia links to my site

Today I noticed that an arti­cle in the Ger­man Wikipedia is link­ing to my site. The arti­cle about mul­ti­me­dia tech­nolo­gies is link­ing to my page about audio com­pres­sion (Ger­man only). I wrote this back in the days when I was in the uni­ver­si­ty (and I got a good grade in a mul­ti­me­dia course for it, MP3 was new stuff back then).

A minor amount of the Wikipedia arti­cle seems to be tak­en from my page (accord­ing to a search engine which is sup­posed to detect pla­gia­rism). This is sort of cool (and the way it is done 100% valid use of my con­tent, IMO). 😎