Code This

std::cout <<me.ramble() <<std::endl;

MIUI Inspired GO Launcher EX Theme Published

leave a comment »

Not too long ago I ran across the MIUI ROM for Android. I rather like the clean and modern style of the ROM. The problem is, it’s not available for many devices, my HTC Thunderbolt included. So I set out to find a theme based on MIUI that I could run instead. The problem was, I couldn’t find a good one. Fortunately, my favorite launcher (GO Launcher EX) has a theme factory available for making custom themes. This allowed me to dig into the MIUI ROM and piece together a GO Launcher EX theme. That theme is now available on the Android market, for less then the price of a decent cup of coffee:

My MIUI theme for GO Launcher EX

There are plenty of screenshots available on the market page, but here is a comparison of MIUI and my theme:

MIUI

My theme

Written by Kris Wong

January 14, 2012 at 6:29 pm

Status Update: EAS Support in K-9 Mail

with 23 comments

After a more in-depth look at ActiveSync support in K-9, I found there to be more issues than I had first thought. This post serves to point out the most major of the issues that I have to tackle before this will be ready to be released into the wild.

1. K-9 does not remember sync state after being restarted. The sync keys used by the Exchange server to know which folders and emails have been synced by the phone are not persisted. This may not be immediately obvious, but it causes K-9 to do a bunch of work it doesn’t need to, which will do a real number on your battery (as well as network usage). This problem has been solved.

2. K-9 does not use the Exchange server to send email. K-9 uses its own “special” outbox for sending email, and it does the sending. K-9 should be moving composed emails into the outbox on the Exchange server, to be sent by the server. UPDATE: My original thoughts here were incorrect. Sending is working correctly.

3. K-9 does not download headers first and then mail contents. It downloads everything in one go. This causes a major delay before mails begin to appear in your message list. I am not sure the ActiveSync protocol is designed for this type of usage. This issue will require further investigation and thought.

4. ActiveSync is designed to filter the number of emails fetched by date, according to pre-defined filters (such as “one month”). K-9 is currently designed to fetch mail differently. The user interface for ActiveSync accounts will need to be modified to match the design used by Exchange.

5. There are discrepancies in the truncation size options for emails between K-9 and Exchange. I am also not certain if it is possible to know if an email is not fully downloaded. This will require further investigation.

I will be tackling these issues 1 by 1 as time allows. At this point, I don’t really have any idea how long it will take me to complete them all.

UPDATES: I have found and addressed a number of additional areas where the design of ActiveSync does not really mesh well with the design of K-9. I won’t go into all the technical details. Syncing of email is now working pretty well. I am now able to use K-9 as my daily email application on my phone.

Written by Kris Wong

December 20, 2011 at 7:33 pm

Building K-9 Mail With Exchange ActiveSync Support

with 34 comments

I have blogged in the past about the less than fortunate state of Exchange support in K-9. This is due to the fact that K-9 communicates with Exchange through and outdated and problematic protocol: WebDAV. WebDAV support is turned off by default in Exchange 2007, and completely removed in Exchange 2010. This of course implies that K-9 does not support Exchange 2010. Since I started working on K-9, I have had the desire to replace the use of WebDAV with the Exchange ActiveSync protocol, which is designed specifically for mobile devices. Unfortunately, this task was much too large for me to take on in my (non-existent) free time. Lucky for us Google sponsors the annual Summer of Code.

This year K-9 was granted 4 Summer of Code projects, including EAS support. The project was successful, and at this point we have “mostly working” EAS support in a branch of the K-9 repository on github. There are still a few small issues to work out, and a few small features to complete, but I currently use K-9 with EAS support for email on my phone. If you would like to build K-9 with EAS support for your own personal use, I am including step-by-step instructions for doing so (though as usual, I do assume some basic knowledge of source control and building java applications).

In order get the K-9 sources and complete a build, you will need a git client, a JDK, ant (you can also use eclipse, but I don’t include instructions for that), and the Android SDK (make sure it’s up to date). The first step is fetching the source:

git clone git@github.com:k9mail/k-9.git k9mail

This will clone the repository at git@github.com:k9mail/k-9.git into the directory k9mail. This fetches all branches in the K-9 repo, including the ms-eas branch where EAS support lives. The next step is to “checkout” the ms-eas branch:

git checkout -b ms-eas origin/ms-eas

This tells git to create a local branch named “ms-eas” that tracks the remote branch at origin/ms-eas, and switch to this new branch. Now you must build the K-9 source. First, create a file called ‘local.properties’ at the root of the source tree with the following entry:

sdk.dir=/path/to/android-sdk

Obviously, replace “/path/to/android-sdk” with the path to the Android SDK on your machine. The command to build is:

ant debug

This will build a signed and zipaligned installer ready for installation on your device. Finally, plug your phone into your PC via USB and ensure it is recognized by adb. To install the freshly built K-9:

adb install -r bin/K9-debug.apk

If you have K-9 installed from the market, you must uninstall it first. Your new K-9 will be signed with a different key than the market version and Android will not let you install this new version if the keys don’t match. Alternatively, you can give the app a new name in AndroidManifest.xml, but that’s outside the scope of this blog post.

If you want to report issues, feel free to mail k-9-dev [at] googlegroups.com.

Written by Kris Wong

September 29, 2011 at 3:29 pm

Using QThread Without Subclassing

with 28 comments

The source code for this blog post can be found here. You do not need a Pro account to download the file, click No if you are prompted to upgrade.

Having been developing with C++ and Qt for around 6 years, and being a regular on #qt on freenode, a thought occurred to me. Hey, why not use that experience for a blog post? So, I thought I would start with one of the least understood classes in the Qt API, and that is QThread. This class is inherently difficult to use, because threading is difficult. Threading can turn a perfectly deterministic system into something non-deterministic. A threading issue is typically going to be much more difficult to diagnose and correct than other issues. Don’t get me wrong, threading is very useful, and serves a very important purpose (imagine using a web browser that didn’t use threads to fetch and render the content). But you should be familiar with both the positives and the negatives of the tools you are using to develop applications.

The first thing you need to know about using QThread is, a QThread object is not a thread. QThread is a class used for managing a thread; it is not itself a thread. The only method on QThread that runs on a separate thread is “run”. The second thing you need to know about using QThread is, as with all QObject subclasses, a QThread object has affinity to the thread in which it is instantiated. If you subclass QThread and add your own slots, you may be surprised to learn that these slots will actually run on the main thread. This also means you cannot use the QThread object as the parent of a QObject instance that has affinity to the thread (i.e., one created within “run”). And lastly, you need to know that only the main (GUI) thread can access GUI elements (QWidgets). The method of communicating between the thread and the GUI is signals and slots. If you don’t know, by default an object’s slots are run on the thread to which the object has affinity. This is done using the event loop.

Unfortunately, until Qt 4.4, QThread was an abstract class. The “run” method was pure virtual. And, even though this is no longer the case, the documentation still shows an example of using QThread by subclassing. While this is not wrong, or bad, it is not necessary. It also lends itself to using the class in ways it was not designed to be used. QThread is now able to be used without being subclassed. Attached is a small example application that creates a QTreeWidget and a button. Clicking the button will lead to the tree widget being populated with the contents of the user’s home direcrtory. Reading the contents of the file system is done on a separate thread. For this reason, you will see that you can still interact with the GUI while this is being done. There is a “sleep” call added, and tree widget items are expanded and collapsed while this is happening, so you are able see what is happening while the application runs.

So let’s jump into some code. This is the declaration of the FSReader class, the class that reads from the file system:

#ifndef FSREADER_H
#define FSREADER_H

#include <QObject>

class FSReader : public QObject
{
   Q_OBJECT

public:
   FSReader(QObject* parent = 0);
   ~FSReader();

public Q_SLOTS:
   void start();

Q_SIGNALS:
   void pathFound(const QString& path);
   void finished();
};

#endif // FSREADER_H

A pretty typical QObject subclass. As we will see later, the start slot will be executed when the thread begins to run, and the finished signal is emit’d when the object has completed its task. The pathFound signal is used to communicate with the GUI. The following is the implementation of the class:

#include "FSReader.h"
#include <QDirIterator>
#include <QDesktopServices>

#if defined(Q_OS_WIN32)
#include <windows.h>
#define SLEEP(msecs) Sleep(msecs)
#else
#define SLEEP(msecs) usleep(msecs * 1000)
#endif

FSReader::FSReader(QObject* parent)
   : QObject(parent)
{
}

FSReader::~FSReader()
{
}

void FSReader::start()
{
   QDirIterator it(QDesktopServices::storageLocation(QDesktopServices::HomeLocation), 
      QDirIterator::Subdirectories);
   while (it.hasNext()) {
      emit pathFound(it.next());
      SLEEP(1);
   }
   emit finished();
}

As you can see, the implementation of this class is quite simple. It only uses QDirIterator to iterate the files and directories in the user’s home directory, and emits a signal for each one found. As mentioned previously, the SLEEP call is simply to slow the program down a bit so you can see what is happening while it runs. It should not be used in a “real” application.

The last code snippet is also the most relevant, as it includes the use of QThread:

void Widget::onBtnClicked()
{
   QThread* thread = new QThread;
   FSReader* reader = new FSReader;

   reader->moveToThread(thread);

   connect(thread, SIGNAL(started()), reader, SLOT(start()));
   connect(reader, SIGNAL(pathFound(QString)), this, SLOT(onPathFound(QString)));
   connect(reader, SIGNAL(finished()), thread, SLOT(quit()));
   connect(reader, SIGNAL(finished()), reader, SLOT(deleteLater()));
   connect(reader, SIGNAL(finished()), thread, SLOT(deleteLater()));

   thread->start();
}

This is the button click handler of the Widget class. You can see here we instantiate both a QThread and FSReader instance, each without a parent. We then change the affinity of the “reader” to this new thread using the method “moveToThread”. This method can be used to change the thread affinity of any QObject.

Lets look at each connection that follows. The first is what starts the reader object after the thread has started. This method is run on the thread. The second connect links the reader object to the GUI. The “onPathFound” slot is run on the main thread. The next connect causes the thread’s event loop to exit once the reader has finished. The default implementation of QThread::run simply starts the thread’s event loop. The last 2 connects handle cleanup, since our objects were created without parents. The “deleteLater” method causes the objects to be deleted once there are no more pending events in the event loop. The reader is deleted on the thread, and the thread itself is actually deleted on the main thread. This “deleteLater” call works for the reader, even though the thread’s event loop would have already exited, because QThread does one final loop to handle all deferred deletetion events once its event loop has exited. QApplication does the same.

The rest of the Widget class, and the main, is included in the linked source, and is not particularly relevant to this post. That’s all you have to do to use QThread without subclassing it. Happy threading!

Written by Kris Wong

April 4, 2011 at 12:22 pm

An Inside Look At Exchange Support In K-9 Mail

with 25 comments

When I first bought my Droid Eris, around a year ago, it came loaded with HTC replacements for most of the stock Google apps, including the mail app, the dialer, mms, etc… The HTC mail app just worked – it supported Exchange, handled multiple in-boxes, and the notifications worked like a charm. Sadly, when I switched to a Froyo ROM, the HTC applications where no longer available and I was stuck with the stock Google apps. Well, as far as the mail application was concerned, this was a very bad thing. The Google mail app came with some significant bugs, and a notification system that was pretty much useless. So I set out to find an acceptable replacement for the HTC app.

This is when I found K-9. It was reviewed well, and boasted Exchange support, which is apparently hard to find on Android. I was saddened when I discovered the state of the Exchange support, which wasn’t great. Firstly, there was a bug in it that prevented it from working with the domain\username format. But alas, the project was open source and, being a developer, this was good news. So I took it upon myself to dive in and fix whatever bug(s) was preventing it from working correctly. I had no idea what I was in for at that point.

What was going to hopefully be a few line patch turned into 2,000 lines or so – and I was only half done at that point. By now I have completely rewritten the process of making the initial connection to Exchange and authenticating. After my initial patch was (reluctantly) reviewed and merged, the project head offered me the position of taking over as maintainer for Exchange support. I accepted, but warned him that I don’t have much free time these days. Either way, I have gained a lot of knowledge about how Exchange with OWA and WebDAV work, and am able to share that knowledge with you.

First, let me describe a little bit about how WebDAV access works. Each user has a mailbox, which by default can be accessed by a URL in the form: https://mail.company.com/Exchange/username. Tack ‘/Inbox’ on to that path, and you have the user’s inbox. You can type that into your browser and you will be kindly redirected to an OWA login page. If you were to send an HTTP GET request to that URL, you would find that the Exchange server responds with a 302 status code, which is a redirect. This is exactly what K-9 does when making its initial connection to your exchange server.

Assuming this request is “successful” (I won’t go into what qualifies as success), K-9 then attempts to authenticate you. Based on the initial response, this will either be through basic authentication or form-based authentication. The greater majority of Exchange servers are setup for form-based authentication, and this is the only configuration I have actually tested. Unless the user has overridden the default authentication path in their configuration (which is completely unnecessary), the path used is: https://mail.company.com/exchweb/bin/auth/owaauth.dll. If Exchange gives K-9 back authentication cookies on the response, the user is authenticated and K-9 retrieves the user’s list of folders. Otherwise, it tries a more brute-force approach. It will check the response for an HTML form target. If it does not find one, it will send a request to the redirect URL from our initial connection and check this response for an HTML form target. Assuming one of these searches yields a valid form target, it will then try to authenticate again using a URL constructed with this form target. For this reason, the user can enter complete junk into the ‘Authentication path’ field, and K-9 will still be able to authenticate the user (albeit less efficiently). I could have removed this field entirely, but chose not to just in case a user has a completely custom/bizarre Exchange configuration.

The only reason I have encountered for why a user would need to enter a value for one of the “advanced” configuration options is if their mailbox alias does not match their user name. Unfortunately, this was not the case for versions of K-9 prior to 3.400. For this reason, upgrading K-9 to the most recent version will break Exchange support for some users until their configuration is corrected. I didn’t really want to do this, but it was a necessary improvement so that these advanced options have a specific and deterministic affect on how K-9 connects to your Exchange server. I don’t want users spending hours “tinkering” with their options trying to get K-9 to work anymore.

To cap off this blog post, I’d like to show some screen shots of the updated screen for configuring an Exchange account. As of the writing of this post, these changes have not even been merged into trunk yet.

Let me know what you think.

Written by Kris Wong

January 7, 2011 at 7:06 pm

Posted in Android, Exchange, HTC, K-9 Mail, OWA

Ohio HB 55/HB 79 – Stop BSL in your Community!

leave a comment »

It’s not typically my nature to post politically motivated content on my blog, but I want this post to serve as a call to action for those who read it. Ohio is currently the only state that has statewide legislation against an entire breed of dog, specifically – pit bulls. In the state of Ohio, all pit bulls (American Pit Bull Terrier) and related breeds (American Staffordshire Terrier, Staffordshire Bull terrier) are labeled as “vicious”, and are subject to all restrictions placed on dogs determined to be “vicious”. A dog of any breed can be labeled as vicious, but pit bulls are the only breed that are automatically labeled as vicious, regardless of a given dog’s actual temperament.

I could likely write a few pages on what BSL is, why it is not effective at increasing public safety, and why it in fact does more harm than good, but there are already a number of resources that feature this discussion. I recommend stopbsl.com, and this sub-page specifically for HB 55/79 related information. I would like to point out the most ironic aspect of BSL against pit bulls, however. That is, a higher percentage of pit bulls pass temperament related tests than many breeds considered to be safe, loving, and otherwise generally awesome family pets. The American Temperament Test Society conducts regular tests on many different breeds to determine the breeds’ level of aggression toward humans. In these tests, the American Pit Bull Terrier scored 86.0%. That is higher than the Beagle, the Collie, the Toy Poodle, and even the Golden Retriever, among many others! Find more information here.

So what is HB 55? It is a bill that is currently stuck in the Ohio Senate that, among other things, removes the automatic categorization of pit bulls as vicious. This bill passed the Ohio House in March by a vote of 93 to 3. But, if the bill does not pass in the Senate by the end of the legislative session this December, it will die. I need you to push your senator, as well as the Criminal Justice Committee, to hear this bill and vote to pass it. It only takes a simple email! This is an email I recently sent to the 9th district senator and the members of the Criminal Justice Committee:

Senator Kearny and the members of the Criminal Justice Committee,

My name is Kris Wong, and my wife and I are resident’s of Ohio’s 9th district. As you may know, HB 55 passed in the house earlier this year with a vote of 93 to 3. This bill must now pass in the senate by the time the legislative session ends in December. This bill removes the automatic classification of the pit bull terrier breed of dog as “vicious”. As pit bull owners, we strongly urge you to hear this bill, and do what is in your power to see that this bill passes. I am sure that you can appreciate the fact that labeling an entire breed of dog as vicious is a misjudgment at the very least. Legislation that mandates this classification makes it easier for insurance companies to deny our household liability insurance, and only furthers negative attitudes towards pit bulls. Our dog is a very sweet and loyal animal, and has never shown aggression towards any person she has met. Thank you for your consideration of this matter.

Kris Wong

For your convenience, the following is a string of email addresses you can paste directly into your email client’s “To” field: ‘SD18@senate.state.oh.us’; ‘SD16@senate.state.oh.us’; ‘SD25@maild.sen.state.oh.us’; ‘SD12@senate.state.oh.us’; ‘SD03@senate.state.oh.us’; ‘SD33@maild.sen.state.oh.us’; ‘SD21@maild.sen.state.oh.us’; ‘SD08@senate.state.oh.us’; ‘SD20@senate.state.oh.us’. These are the email addresses of Criminal Justice Committee. You can find your own Senator’s email address here: http://www.ohiosenate.gov. If Senator Kearny happens to be your senator, his email address is: ‘SD09@maild.sen.state.oh.us’. Please, take 5 minutes out of your day to send these individuals an email.

This post is dedicated to Oceana.

Written by Kris Wong

November 12, 2010 at 7:29 pm

The Swiss Army Knife Of Droid Eris Posts

leave a comment »

I have a few topics I’d like to cover in this post. First off…

SetCPU

I’ve recently been experimenting with my SetCPU settings, and I think I’ve found the optimal settings for my phone. My profiles are as follows:

  • Default – 787 max, 19 min
  • Screen Off – 480 max, 19 min, 90 priority
  • Temp > 40.4 C – 528 max, 19 min, 80 priority

And that’s it. I experimented with 806 max, but my phone was unstable (random crashes)  at this setting. It has been stable at 787 max. I can go 2 days w/o a charge with light usage, 1 day or so with moderate usage. The failsafe profile is important. I have triggered it a few times while using the phone for 5 – 10 minutes or more while it is charging.

I have heard of issues with setting a min of 19 while using Sense as your home/launcher. I personally have not tried this configuration, so I have not had any issues with it.

Titanium Backup

I discovered the hard way that you should not blindly back up/restore all user apps and system data. This wreaks havoc when switching between ROMs. I now backup my user apps only. Titanium Backup displays useful system data in green, which is safe to back and restore across ROMs, but I haven’t found a need to backup any of this information. This alleviates the need for apps2sd.

Froyo

I recently switched from xtrSENSE to KaosFroyo v. 32. I read that the first stable release of CyanogenMod 6 (the base for most Froyo ROMs) had been released into the wild, and I figured it might be stable enough for daily use at this point. Things have been going pretty smoothly so far. Most of the system apps (dialer, messaging, email, contacts, browser, etc…) have seen a significant interface overhaul – mostly for the better. The only issue I’ve had with these apps is the dialer. It no longer displays the call log immediately when opening, nor has the quick search for finding contacts, etc… There are instead 4 “tabs” available once the app is opened, and the first thing you see is simply a dial pad. The other tabs are Call Log, Contacts, and Favorites. It’s a little less convenient than it was previously, but workable once you get used to it. The favorites tab (populated automatically) is also nice.

The only other real issue I have seen is with the xScope browser. Typing into the address bar with the phone tilted horizontally causes the Froyo notification bar to display and then hide a few times for each key stroke, causing things to jump around on the screen wildly. Typing works fine if the phone is held vertically.

By now version 34 of this ROM is out. This developer appears to be incredibly active lately.

Update: I’ve discovered that the “interface overhaul” I discuss above is not due to my upgrade from 2.1 to 2.2; rather, it is a difference between the HTC applications included with xtrROM and the Google applications included with KaosFroyo. While the Google applications are generally nicer to look at, the HTC applications are generally much more usable (and function more sanely). This is most evident in the email application and the dialer. Since my upgrade to 2.2, I have been unable to find an email application that meets my needs. You would figure this is one of the most basic and prominent uses for a smart phone, but yet the only usable email application I have come across is from HTC. At present, I am trying to get exchange support in K9 Mail into some sort of usable shape, but as my free time and my experience with java are limited, this is coming along slowly.

Written by Kris Wong

September 17, 2010 at 3:49 pm