The Keyboards

“Wait, this is Swype?”

I read about Swype in Brian’s Droid X review, but Motorola shipped the keyboard disabled by default so I figured it’d be one of those things with a steep enough learning curve to dissuade the impatient. When I first started using the keyboard on the Epic 4G I fell in love. It was by far my favorite Android keyboard. It wasn’t until I finished typing a word and noticed a little info button blinking in the lower left corner of the keyboard that I realized I was using Swype.

Samsung ships the Epic 4G with Swype installed and enabled by default, and I totally get why. The keyboard layout is simply perfect for Android. You get a very simple keyboard with a layout that makes sense, I have absolutely no complaints about it. The keys are both big and well spaced enough on the 4” touchscreen to make typing quickly a non-issue. There’s no And if you want an alternate input form that requires fewer taps, there’s always Swype input.

The virtual keyboard rocks but what Swype lets you do is input characters an alternative way: by tracing a line over the letters of the word you’re trying to type. For example, if I wanted to Swype out the world “them” I’d place my finger over the letter ‘t’ on the keyboard, then draw a line down to h, diagonally up to e, and back down and to the right over to m. When I lift my finger there’d be a slight pause, and Swype would insert the word “them”. There are tricks to do more complicated things: make a little circle around a letter you need to enter twice, or extend a line up above the keyboard to create a capital letter. If Swype is unsure of what you’re typing it’ll give you a list of options to choose from, and manually typing in words adds them to the dictionary.


Swyping "hello"

I personally prefer the traditional typing method of text input but I can see how, with practice, you could be just as fast with Swype.

While Swyping you have to pay more attention to spelling. The iOS style of text input is pretty much tap and forget, if you misspell or mistype something the OS autocorrects. But with Swype, you actually need to know how to spell the words you’re trying to type and know where all of the keys are on the keyboard. I didn’t feel my mental CPU utilization hit 100% as Brian described in his first encounter, but I felt like I was in a constant spelling/key location bee. It just takes some getting used to but I actually liked Swyping when I didn’t feel like typing with two hands.

The downside to using Swype as a normal virtual keyboard is the optional autocorrection (you have to enable it under Swype settings). Instead of getting suggestions inline, you get a distracting popup. Thankfully you can easily switch back to the default Android keyboard just by holding down on any text input box and changing the input method.

The physical keyboard is a nice addition, I definitely appreciate it being there although most of the time I used the virtual keyboard. I’d probably prefer the other Galaxy S variants that lack the physical keyboard, but if you need tactile feedback the Epic 4G’s hybrid model works.

The Smoothest Android UI To Date The Fastest GPU in a Smartphone
POST A COMMENT

93 Comments

View All Comments

  • Ethaniel - Monday, September 06, 2010 - link

    I have also noticed that all Android phones out there do some kind of "breakdancing". You think it has something to do with Android, but I think it has something to do with Java. Now, Java devs will probably want to eat my brain after this... but Java sucks. Big time. Making Android's UI based on Java was a bad, bad, really bad move. About four three time slower than C++, it demands more memory... completely inadequate for a mobile environment. Reply
  • meatless - Monday, September 06, 2010 - link

    It's sad, the prevalence of Java FUD to this day. It's also bad to blame Java (the syntax), as you are unnecessarily conflating the Dalvik VM with desktop VMs such as Sun's.

    C++ is fast, sure, but there is a lot more to designing a platform than speed, and the Dalvik VM is more than fast enough. iOS's Obj-C implementation is also not C++ fast, but who complains?
    Reply
  • taltamir - Tuesday, September 07, 2010 - link

    1. both Javas are shit
    2. There is more to a platform then speed... but when you are designing a platform starved for processing power and that needs to sip electricity then it makes a huge difference.
    Reply
  • Penti - Tuesday, September 07, 2010 - link

    Most of the platform are actually C/C++ libraries and programs, where you glue your app in isn't that relevant. You need a framework for any mobile phone platform, but the resources that framework glues into thats where a lot of performance comes from and it's in C/C++. It's better to have an accelerated framework running on a virtual machine then an unaccelerated C++ one. Rendering of menus and such would be slower on the last one. Besides on Symbian it's QT-framework that rules now, not some ultra customized embedded framework. Memory requirements have gone up there too, but capacity have grown even more. Besides nobody wanted to write mobile apps to some badly designed and awkward C++ framework and API. Java syntax was a good choice therefor. Reply
  • taltamir - Monday, September 13, 2010 - link

    the fact that there are more considerations than just programming language when it comes to power and speed are obvious, as is that you could make a java app thats faster than a C++ app.
    Neither make java a good choice.

    BTW, I didn't personally comment about the issue of jerkiness, I was going on a tangent as a reply to what meatless said (specifically the socalled "java FUD")
    Reply
  • zizagoo - Monday, September 06, 2010 - link

    It's an Android problem. The cause of the "jerkiness" is that unlike iOS/WebOS/WP7, Android doesn't have a gpu accelerated ui. They supposedly did this because the G1 wouldn't support it at the time.

    http://code.google.com/p/android/issues/detail?id=...

    Gingerbread, which is supposedly showcased next month, should fix this.
    Reply
  • deputc26 - Monday, September 06, 2010 - link

    Thankyou! this is exactly it, give the man a medal. I don't know why Anandtech never mentions this. It should be ubiquitous knowledge in the android community. Reply
  • meatless - Monday, September 06, 2010 - link

    Also, the 3-4X speed difference on non-mobile platforms is greatly exaggerated. I always find http://shootout.alioth.debian.org/ a fun and FUD-free site. Reply
  • Iksy - Tuesday, September 07, 2010 - link

    Greatly exagerated? That site shows a 2.3x speed difference and it's comparring against Sun's fastest most optimizing version against g++. The unoptimized version is over 20x slower, you'll find it near the bottom of the list for compares. I do find it interesting that while they're satisfied with using an open source C (gnu) compiler, they do not include the open source java interpreter. They also do not include the Intel C compiler, even though they easily could and include the Intel Fortran compiler.

    In other words, is still in the ball park so say Java is 3-4x slower than the equivalent c++ code.
    Reply
  • dvinnen - Tuesday, September 07, 2010 - link

    Wait, so the Java syntax is what is slowing down Android? Because it doesn't run Java, it runs Dalvik.

    I would also like to see evidence that C++ is 4 times faster. Not saying Java is faster but it is fast enough. I say that as a Java developer who doesn't like the language and would rather use slower languages like Python
    Reply

Log in

Don't have an account? Sign up now