Push Email on the Windows Mobile Platform

A few months ago, I went ahead a bought an HTC Touch Smartphone. I initially wanted the Pocket PC platform, so that I could easily sync up with Outlook and have all of my contacts and appointments with me at all times. Synchronizing that information with a typical phone is very painful.


At first, I didn't really like the HTC Touch. It's slow (compared to a standard phone or an iPhone). The biggest issue was getting push email to work. The guy at the Sprint store claimed that you would just enter your email credentials, and push email would magically be enabled. I ensured him that it wasn't that simple, but he still insisted.

With pocket Outlook I was able to set up access to my GMail account using IMAP. The problem was that it was slow, and push email didn't really work at all. Research led me to the conclusion that Pocket Outlook really sucks at IMAP. I even tried another email client (Flexmail), but I still wasn't satisfied.

Then, I found out that you could use the "Live" application on the phone to get real-time email from Hotmail using the option on the device for receiving emails "as items arrive". I signed up for a Hotmail account, and set my GMail account to forward a copy of all messages. This option proved to be very flaky, but the email delay wasn't too bad. After doing some research, it seems as though this option pretends to be push email, but is in fact very frequent polling. I would occasionally lose my data connection, and the mail application would just give up.


Now on to the option that actually works, and the ONLY option that has worked consistently, reliably, and without much delay (5-15 seconds). Sign up for the "Live" option on Mail2web. This basically gives you your own free Microsoft Exchange account. Set up your email accounts for forward a copy of your messages to this account. Then use the credentials they supply to connect your device. On Windows Mobile 6, you can set it up in ActiveSync on your desktop, or through the device itself.

This option has worked flawlessly for me, even when I can barely get a signal. I get email no matter where I'm at, and I can save time because I don't need to compulsively check my computer for new mail. I'm guessing this is really the only well supported option for mail, because this is how business customers would set it up.

For extra credit, I copied the XP email notification sound off my system, amplified it (using Audacity), and then set that as my mail notification. I get the recognizable email sound, which is pretty confusing to those around me when there are no computers around.

Enjoy your real-time push email!

Like this post? Please share it!

See a mistake? Edit this post!

Don't play the "What If" game

One of the biggest traps I've seen developers fall into is what I like to call the "What If" game:

"Make your ID columns integers"

"But what if we want them to contain a letter eventually?

"Let's cook these 10 steaks"

"But what if 100 people show up?"

"Let's go to the park"

"What if we get sick?"

The "what if" game consists of over thinking your plan. Planning in general is obviously essential. However, I've seen an alarming rate of crippling fear. Fear to write any code because it will never possibly handle all possible scenarios. It ends up being a self fulfilling prophecy of failure.

Sometimes the side effect isn't just a fear to write code. It often leads to code that is generic beyond usefulness. For example, a database with all columns being VARCHAR(MAX).

Specialization is basically a spectrum. At one end, we have code that is so specialized that it is basically un-reusable. At the other end, the end I'm talking about, we have code that can be used everywhere, but doesn't really do anything.

Some of the hardest decisions we have to make as developers are related to whether we base our decisions on the present, or a potential future that has a variable amount of certainty.

I'm not saying that you should avoid planning, but your decisions need to be based on the real likelihood that changes will need to be made later. An ounce of prevention is worth a pound of cure, but 64 ounces of prevention is certainly not worth a pound of cure!

Like this post? Please share it!

See a mistake? Edit this post!

When should you use database constraints?

A discussion came up at work recently about the extent of constraint usage in your databases. There were basically 2 camps:

  1. Constrain everything humanly possible. If it's an integer that wouldn't normally be negative, add a ">= 0" constraint.
  2. Constrain primarily where it's necessary to maintain referential integrity.

Consider the following diagram. It's a map of the flow of data from your user, which eventually makes its way into the database.

Validation Layers

Since we're getting input from a user, and they're the one that can fix invalid data, we validate data at the top layer. There's usually no getting around this. In fact, for the best user experience on the web, you're going to perform some JavaScript validation. Then you'll probably validate it again on the server, in case they have JavaScript disabled.

At this point, unless there is a bug in your code, you're sure that the data is valid. You may not know if it's referentially valid. Validating the input a third time in the database is probably overkill. It's also a potential performance bottleneck.

Yes, there are many times when this doesn't apply. For example, when multiple systems are interacting with the same database, and one counts on the data in a certain format. The only way to guarantee you get data in a format you expect is to constrain it at the database level.

In general, I avoid strict constraints at the database level. The biggest reason is that it requires your to synchronize all of your validators. They all have to agree on the same set of restrictions, or the code will fail. That goes against the LEAN and Agile philosophies. When I want to allow negative numbers in my integer field, it's much easier to simply change it in my application. This is amplified if you have to talk to a DBA to make changes.

Another reason to avoid constraints is that they can't always understand the data like the application can. For example, should a constraint attempt to ensure that valid email addresses are entered? If you're storing a persons age, do you constrain it so that it can't go above 500? 200? 100?


Now let's assume that there is a bug in your application code, and you didn't have a trusty constraint to stop it. You now have invalid data in your database. The good news is that you now have the potential to clean it up, or adapt your code to deal with it. The bad news is that if that value is used in a calculation that could have bad side effects, you could have big problems.

As with anything, there is no hard and fast rule for every situation, but we can at least make some general guidelines.

Think LEAN. Anything that doesn't provide value to the customer is waste. Think Agile, requirements change, be adaptable.

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG