Final Words

With each new iteration of Android smartphone we get closer to the perfect device. Samsung took some pretty big steps toward that ideal ‘droid but regressed in others.

The move to Super AMOLED is key. With Super AMOLED the Epic 4G improves outdoor usability significantly. It’s a large enough jump to make the Nexus One’s display feel old. While Apple can tout the benefits of higher resolution, contrast is very important on these devices - especially for content consumption. I would have liked to have a brighter display on the Epic 4G, but the contrast ratio is great.

Samsung got the performance of the Epic 4G right. The OS feels snappy and relatively smooth. There are still some hiccups but its 1GHz Hummingbird SoC does a better job than anything else I’ve seen running Android. I suspect that after we get Gingerbread and dual-core Cortex A9 SoCs that these little performance quibbles will be a thing of the past. Unfortunately that doesn’t help those trying to make a decision today.

Build quality could use some work but that’s probably more of a function of the sliding mechanism on the phone than anything else. The physical keyboard is nice for those who want it, but that’s really a personal preference. I applaud Samsung for shipping Swype enabled by default on the Epic 4G. Not only does Swype offer a unique take on text input, but its virtual keyboard is the best I’ve used on Android to date.

On the software side, Samsung’s TouchWiz is one of the most polished custom Android UIs I’ve seen. Everything from the app launcher down to the dialer is well done. Samsung does take the simplicity a little too far in some areas (e.g. not showing battery percentage, only the visualization), but overall it’s nice. You don’t get as much of the PC-feel as you do on other Android phones, which again boils down to personal preference.

I love how Samsung integrated turning off Bluetooth/WiFi/4G/GPS into the notifications pulldown menu, and some of Samsung’s widgets are nice (e.g. task manager). However, the seven home screens are overwhelming and counterproductive in my opinion.

For all the praise I shower on the Epic 4G, it has two real problems: battery life and GPS reception. They are both pretty simple to explain: the Epic 4G won’t last longer than 4 hours of use, and it has a hard time pinpointing your location via GPS. There’s nothing more to it.

What does four hours of use translate to? I’d say less than a day’s worth of use taking into account idle time. If you pick your phone up at 8AM and use it periodically throughout the day, I’d expect it to be dead by 5PM. Quite possibly sooner.

The GPS issue makes the Epic 4G a pain to use as a navigational device. If you use Google Maps a lot for calculating directions, prepare for a frustrating experience with the Epic.

We’re closer and Samsung did very well, but we’re not quite perfect.

GPS Issues
Comments Locked

93 Comments

View All Comments

  • Ethaniel - Monday, September 6, 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.
  • meatless - Monday, September 6, 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?
  • taltamir - Tuesday, September 7, 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.
  • Penti - Tuesday, September 7, 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.
  • 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")
  • zizagoo - Monday, September 6, 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.
  • deputc26 - Monday, September 6, 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.
  • meatless - Monday, September 6, 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.
  • Iksy - Tuesday, September 7, 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.
  • dvinnen - Tuesday, September 7, 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

Log in

Don't have an account? Sign up now