Easily Influenced

As the manufacturer for both the NAND that goes into Apple devices and the SoC that Apple uses in the iPhone/iPad, Samsung works closer with Apple than most other smartphone vendors. I was once given a characterization of Samsung that I will never forget: this is a company that’s trying to learn as much as it can from Apple for use in its own smartphone endeavors.

There’s no better example than the Galaxy S. Unlike other vendors who have been Cupertino inspired, Samsung’s learnings are put to use almost exclusively in software. Physically, the Galaxy S is quite dissimilar from the industrial design used in Apple’s iOS products.

Samsung sent me the Epic 4G, a variant of the Galaxy S for use on Sprint’s network (with WiMAX support as implied by the 4G moniker). The Epic 4G has an amazingly contrasty 4” 800 x 480 Super AMOLED display. The capacitive touchscreen is backed up by a physical keyboard that slides out in landscape mode.

I’d say that Samsung did everything to be the most unlike Apple in the design of the Epic 4G. Along the top you have a microUSB port, but Samsung included a sliding cover to keep the pocket lint out. This adds complexity to the look of the device, but is nicely protective if you’re a bit OCD about getting lint in the crevices of your phone. The sheer location of the microUSB port is unusual as well. Most Android phones we’ve looked at have their power/sync connector at the bottom of the phone, not the top.

The power/lock button also shifts positions compared to what we’re used to. It’s on the right side, near the top on the Epic 4G.

On the lower part of the right side of the phone there’s a shutter release button for the camera. There’s a volume rocker on the left side of the phone. All of the buttons on the Epic 4G have a rubbery texture to them with the exception of the shutter release button which has a metal insert surrounded by rubber.

The screen slides up to reveal a landscape keyboard on the Epic 4G. The sliding mechanism is easy enough to operate with one hand and reasonably smooth. It’s not the most confidence inspiring but not terrible either.

The physical keyboard itself is a nice addition for those who must absolutely have it. Samsung even duplicates the four Android keys on the keyboard itself (home, back, menu, and search) so you can exclusively use the physical keyboard for navigating the OS if you’d like. There is no scroll ball or equivalent on the Epic 4G, but the physical keyboard does have four arrow keys you can use in its stead.

The keys on the physical keyboard are fairly wide and reasonably spaced (it is a landscape keyboard after all). The keys are missing some curved definition that would make it easier to touch type on them but overall it’s not a bad keyboard. Again, not the best I’ve encountered but not terrible at all.

Since this is a slider phone, build quality isn’t the easiest to guarantee. The two halves of the phone independently feel well made, but the joining of the two isn’t super secure. The “oreo effect” as Brian likes to call it is very present on the Epic 4G. You can twist the top and bottom halves of the phone and get them to separate by a couple of degrees. It’s not terrible but if having a loose feeling phone bothers you then you may want to look elsewhere.

The four standard Android keys are also present in capacitive touch form along the bottom edge of the Epic 4G. Unlike most other Android phones, the capacitive buttons aren’t visibly outlined on the phone. You can only see them if they’re backlit, which has a timer associated with it that’s by default separate from the screen timer. What this means is that the row of Android buttons will actually disappear before the screen goes blank if you don’t touch the phone. Thankfully Samsung provides a setting to sync these two so both the screen and buttons go blank at the same time, but it’s just not enabled by default.

The Epic 4G is a good fit in my hand, but with a physical keyboard it is a thicker phone than most I’m used to. If you’re coming from a standard cellphone or feature phone, the Epic 4G is going to feel huge - if you’re coming from another Android/iOS device, it won’t be too bad.

From left to right: Google Nexus One, Samsung Epic 4G, iPhone 4

The phone is a mixture of materials, with the front being glossy plastic, then a chrome strip around the middle and a matte black back cover.

The back cover snaps off with relative ease revealing the 1500mAh battery, a microSD card slot and what looks like four external antenna connectors. I’m not really sure what the exposed connectors are for, perhaps to help during hardware testing/debug. Not having to take the battery out to get to the microSD card is a nice addition as well. The phone comes with a 16GB card as well as a microSD to SD card adapter for use in standard card readers.

Finally on the back we have a lens for the 5MP camera sensor and a single LED flash.

Physical Comparison
  Apple iPhone 4 Apple iPhone 3GS Samsung Epic 4G HTC EVO 4G Motorola Droid X
Height 115.2 mm (4.5") 115 mm (4.5") 124 mm (4.9") 121.9 mm (4.8") 127.5 mm (5.02")
Width 58.6 mm (2.31") 62.1 mm (2.44") 63.5 mm (2.5") 66.0 mm (2.6") 66.5 mm (2.62")
Depth 9.3 mm ( 0.37") 12.3 mm (0.48") 15.2 mm (0.6") 12.7 mm (0.5") 9.9 mm (0.39")
Weight 137 g (4.8 oz) 133 g (4.7 oz) (5.47 oz) 170 g (6.0 oz) 155 g (5.47 oz)
CPU Apple A4 @ ~800MHz Apple/Samsung A3 @ 600MHz Samsung Hummingbird @ 1GHz Qualcomm Scorpion @ 1GHz TI OMAP 3630 @ 1GHz
GPU PowerVR SGX 535 PowerVR SGX 535 PowerVR SGX 540 Adreno 200 PowerVR SGX 530
NAND 16GB or 32GB integrated 16 or 32GB integrated 1 GB integrated, 16 GB microSD preinstalled 1 GB integrated, 8 GB microSD preinstalled 8 GB integrated, preinstalled 16 GB microSD
Camera 5MP with LED Flash + Front Facing Camera 3MP with autofocus 5 MP with LED Flash and autofocus 8MP with dual LED Flash + Front Facing Camera 8MP with dual LED Flash
Screen 3.5" 640 x 960 LED backlit LCD 3.5" 320 x 480 4.0" 480 x 800 4.3" 480 x 800 4.3" 480 x 854
Battery Integrated 5.254Whr Integrated 4.51Whr Removable 5.55Whr Removable 5.5Whr Removable 5.698 Whr
Vectors of Innovation The Smoothest Android UI To Date
Comments Locked


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.


    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