Invert Your Mind

One of the family Apple notebooks (a Macbook) was having some issues waking up from sleep periodically. It was also having issues when the lid was closed the fan would constantly spin as though the machine was overheating. I took the machine into the only Apple store I trust (the main tech there is pretty solid, although he still doesn’t use Terminal). The fix was pretty simple:

1. Open up Terminal (Google it if you’ve never done it)
2. Type in ‘cd /var/vm’
3. Type in ‘rm sleepimage’

It looks like this:

$ cd /var/vm
$ rm sleepimage

This should fix any issues with sleeping and waking up. The root cause is that if you move the machine to fast, have any static electricity and shock the machine, or otherwise jostle it too much when it is going into sleep mode (just after you close the lid), the sleep image will become corrupt and you’ll start having issues.

I just noticed that I’ve been using the Builder pattern with method chaining a lot. Looks like this:

FooBuilder builder = new FooBuilder();
Foo foo = builder.add(...).divide(...).multiple(...).builder();

The issue that arises is that I want to store a bunch of methods in a base class that various builders can use. In order to do this correctly, I have to really hack up my classes with some strange generics and unchecked casts like this:

public class BaseBuilder<T extends BaseBuilder> {
  public T add(...) {
    ...
    return (T) this;
  }
  public T divide(...) {
    ...
    return (T) this;
  }
  public T multiply(...) {
    ...
    return (T) this;
  }
}

public class FooBuilder extends BaseBuilder<FooBuilder> {
  public Foo build() {
    ...
  }
}

This is really annoying. I think every class should have a generic type variable that references the current type and let the compiler figure it out. Just name the variable ME or something. It would make the code look like this instead:

public class BaseBuilder{
  public ME add(...) {
    ...
    return this;
  }
  public ME divide(...) {
    ...
    return this;
  }
  public ME multiply(...) {
    ...
    return this;
  }
}

public class FooBuilder extends BaseBuilder{
  public Foo build() {
    ...
  }
}

Now that’s much nicer looking.

I know that .Net 4 is going to have some pretty cool features around dynamic typing and C++0x is also adding some auto typing features. I was thinking about all of this today and realized that what I really use most of the time is an inferred type. Essentially it would infer a new type based on the method’s contents.

Let’s say we have this:

public void callSomeMethod(Object obj) {
  obj.methodCall();
}

In static languages this fails because Object doesn’t contain the method methodCall. However, what if we told the compiler to create a new interface based on the content of the method? This code would then look like this:

public void callSomeMethod(autotype obj) {
  obj.methodCall();
}

The autotype keyword would cause the compiler to actually create this code:

public interface MethodCallInterface {
  void methodCall();
}

public void callSomeMethod(MethodCallInterface obj) {
  obj.methodCall();
}

This would now compile. Next, a caller to this method could pass in any object whose type the compiler could add this interface to. If you called it like this:

public class MyClass {
  public void methodCall() {
    System.out.println("Here I am");
  }
}

// Some other code somewhere
MyClass mc = new MyClass();
callSomeMethod(mc);

The compiler could take the interface it created for this method call and then see if the type passed in could implement that interface. If MyClass has already been compiled, it could do one of two things:

• If MyClass is accesible as part of the current compilation unit, it could update the compiled Class to implement the interface
• If it isn’t part of the current compilation unit and isn’t final, it could create a proxy for the call that implements the interface and delegates the call

Not sure yet how #2 really works or if it even makes sense to do it that way, but it seems to be the only way to make it work if the Class is in a JAR or DLL or something like that.

The only issue would be reflection. How could you reflection on the method and then pass an Object to it so that it would not completely blow chunks at runtime? Perhaps the reflective method invocation could determine if the object being passed could be proxied to the dynamic interface and then create a proxy on the fly.

Anyways, just pondering type systems in general today….

Since I’m doing a lot of C++ these days and working a lot with the STL, I want to jot down some things I’ve had to painfully recall about sorting:

1. The std::sort function really only works with vector
2. If you want to sort a set of pointers, you’ll need to create a comparator function or object and use it as a type parameter (uglier than hell)
3. If you want to sort a list, you MUST call the sort method on the list

#2 looks like this and really sucks to look at:

set<string*,StringPointerComparator> myset;

And if you want to pass that thing around, you have to either pass it like that (nasty) or typedef it. Since I hate all typedefs, macrodefs, etc, I generally pass that nasty full type around.

Here’s a quick run-down and comparison between the G1 vs. iPhone and Andriod vs. OS X mobile. This is based on side-by-side evaluation with both phones.

The phones

Keyboard

The winner: G1

The G1’s keyboard is awesome. I like it so much better than the iPhones mainly because I can see the whole screen while typing, but also because it has numbers and I don’t have to hit something to switch between numbers and letters. I’m a keyboard freak, so hands down the G1 wins.

Screen

The winner: iPhone

I think this is close to a tie, but the iPhone screen is bigger. The resolution is the same for both phones, which means that the G1 can display as much information as the iPhone, but it is smaller.

Battery

The winner: iPhone

The iPhone’s battery is 2-3 times better than the G1’s. I’ve heard word of T-Mobile shipping out batteries that add 30% more life, but even still, I play around with my G1 very little and it still needs to be charged daily. My iPhone needs charging every 2-3 days with the same use.

Form factor/Design

The winner: iPhone

This isn’t much of a battle. The iPhone is sleek, light and really nice to look at. The G1 is thicker, heavier and an eye-sore comparatively. However, I can understand the extra size given the full keyboard. One thing the G1 does nicely is it figured out the exact size required for anyone to hold it in one hand and use any feature of the phone. This is the only thing nice about the G1’s size and shape.

Buttons

The winner: G1

I like the buttons and track ball with the G1. The iPhone is sometimes a bit cumbersome to use given that everything is on the screen. Sometimes it is nice to just hit a button.

Accelerometer

The winner: iPhone

The iPhone has a really good accelerometer that seems to be level and responsive. The G1’s is a little rough around the edges and you can’t calibrate it or tweak it at all.

The operating systems and software

Structure

The winner: Android

Android has a lot of advanced features that are pretty nice overall. Each application has a menu, which is great for adding loads of functionality. There are keyboard shortcuts in applications which makes using features fast. Android has intents which are nice. It also allows applications to leverage other applications and common libraries. By far, Android wins when it comes to a modern platform.

At the same time though, Android has many bugs and issues that also make it difficult to actually use.

Homepage/Application Chooser

The winner: Tie

The iPhone home page doesn’t have the cool backgrounds or the lame analog clock or the drag and drop application display, but it is simple, orderable (you can move apps around), and looks really nice. Androids has a cool homepage that allows ordering and an alphabetized app chooser. So, they are different, but equally as usable and cool.

Androids icons definitely have that Linux look, which I grew tired of a decade ago while iPhone’s icons are sleek and nice and I haven’t gotten tired of yet (only 1 year as a Mac user). It seems like Apple is more in tune with style and each OS release keeps things fresh. We’ll see how 10.6 goes. Linux on the other hand just plain sucks the life out of you.

Voicemail

The winner: OS X

T-Mobile and Android’s voicemail integration is horrible. It is exactly the same as every other phone for T-Mobile because you have to dial into voicemail and manage it via T-Mobile’s phone system. There is an 3rd party application that adds visual voicemail to Android phones, but it is in beta and it is a hack that appears to actually dial up your voicemail and record the voicemails to an MP3. I’m not positive on that, but this is what it seems like. Regardless of how this application works, it is a 3rd party application and T-Mobile and Android should really be offering a tightly integrated feature of the phone.

The iPhone completely integrates with AT&T’s voicemail such that you can view all your voicemails on the phone, listen to them on the phone, and even setup and switch your voicemail greeting on the phone.

Calendar

The winner: Android

The Android Google calendar integration is great. However, it doesn’t support multiple calendars very well (you can only view calendars in the associated GMail account and not other GMail accounts or an Exchange calendar) and that’s a real pain point for most. Since I use a single calendar for everything, I don’t mind too much. On the other hand, if you have a Mac and only use Calendar.app, integration with the iPhone is great. This combined with Mobile Me would be ideal for real-time updates and syncing. For now though, Android wins in this department.

I’d imagine that Google will soon offer syncing with the iPhone as it does with the BlackBerry. If not, NuevaSync will work once it is finished and out of Beta.

Likewise, I would put money that Android will start supporting multiple calendars shortly.

Maps

The winner: OS X

Multi-touch, double-click and good integration/features wins this battle. Since you are already touching the screen to move around, multi-touch is nice. The G1’s map interface is nice and it does allow single handed use, but iPhone’s bigger screen and multi-touch prevail in this category.

Email

The winner: OS X

First, the GMail application really should be combined with the Email application. The fact that they are separate is really painful and annoying. Email should just be email like the iPhone does. Second, Android’s email application is one of the worst applications ever written. Here are a few of the pain points:

• Can’t view first few lines of emails in the inbox view
• The folder and email view are combined making for a very cluttered interface
• Email fails regularly even when connected to a WiFi
• Deleting emails does nothing for GMail accounts via IMAP.
• Can’t setup what happens on delete for IMAP accounts. For example, with GMail IMAP it should move the message to [Gmail]/Trash

The worst thing is probably that the Email application doesn’t instantly work with GMail IMAP accounts. This should just work considering that the entire platform and stock applications are written by Google. I mean come on guys, take a cue from Apple and just make stuff work, especially with your own systems. Plus, Email constantly crashes and has so many issues that it is rendered useless in most situations.

The iPhone email isn’t perfect, but it handles all of these things much better and also makes setting up GMail accounts a snap.

Document Viewer

The winner: OS X

The iPhone has a built in PDF viewer that works really well. It also displays Word documents and other formats decently well. In gets a little bit freaked out by complex Word documents in the new DOCX format, but otherwise it is great. It also allows you to zoom in and out using multi-touch and double-click.

The G1 looks like it uses Google Docs online viewer or some type of hacky internal viewer. Not really sure about which one, but it does a very poor job of displaying documents and files, including PDF (I mean really? PDF? It should perfectly display all PDFs). Images are also displayed poorly and some don’t render correctly, such as JPGs. Plus, no zoom (ouch!).

Apps

The winner: OS X

This is based purely on the most fundamental of all applications, solitaire. There are a number of choices on both phones, but overall the solitaire on the iPhone is much nicely in terms of design, features, etc.

App stores

The winner: OS X

Apple’s store has a much cleaner interface and includes pictures, better details, better commenting system and more interactivity. The Android market looks pretty shabby comparatively.

Accelerometer/Orientation

The winner: OS X

The iPhone uses the accelerometer all over the place and it does it really well. Orientation of the phone is really helpful in most applications as it makes the phone easy to use.

Android’s support for orientation and the G1’s accelerometer is just garbage. Even the browser requires 3-4 clicks before you can change the orientation without opening the keyboard. I mean come on guys, just use the tools you have and make people’s lives simple. Plus, HTC seems like they added a pretty low end accelerometer and it isn’t calibrated very well. Plus, you can’t really calibrate it.

Development

The winner: Android

I’ve talked at length about how I think Objective-C is really keeping Apple back, but here’s another way to look at it. If you take the years that technologies were introduced and line them up so that you have language, RAM, and CPU (based on speed), here are the results:

iPhone: 1986 1989 2000
G1: 1995 1996 2000

I definitely like the G1 and Android numbers much better.

The Final Score

If we add all these up, it looks like this:

G1/Android: 5

iPhone/OS X: 11

The final winner? iPhone/OS X