Looking at the spec sheet, a 1500 mAh battery and the talk time is 6.5 hours...battery life on that phone is bad...The Droid X with a 1540 mAh battery the talk time is 8-9 hours..
Spec sheet says its using the older Snapdragon, where the newer one should help with battery life...
This is the problem I have with MS and some of the WP7 phones having the older Snapdragon in em and the phone being marketed as high end. That Snapdragon is on its way out as being current, so why use em?
The reason why WP7 is stuck with the older Snapdragon is the reason why the UI appears so fluid and smooth.
The graphics libraries are hard coded against the GPU, so optimized in fact, it may not be easily scalable. Every time is so synchronized to a certain speed that going faster or slower screws up everything. Do you understand why game consoles cannot go faster or slower? Because games are so written to set processing and GPU speed, they're not very scalable.
This is the reason why WP7 is not using the newer Snapdragons with the Adreno 205, why they're not using Samsung's Hummingbird, why they're not using Texas Instrument OMAP6.
Because WP7 supports only a Qualcomm, expect Samsung (despite the alleged BS that claims Samsung will put out more WP7 sets than others) to deemphasize WP7 in favor of Android and Bada, since Android and Bada are capable of supporting Samsung made chipsets not just Hummingbird, but the recently announced Orion. Samsung has been positioning itself increasingly as Qualcomm's competitor.
Watched how nVidia changed its tunes, its CEO once praised MSFT for the Zune HD supporting the Tegra. Now they are all praise to Google and Andy Rubin since obviously WP7 has left the Tegra 2 out, leaving Tegra 2 to bet its chances with Android. This does not escape both LG and Motorola, who are planning Android devices with Tegra 2.
Its one reason why Motorola, in bed with using TI OMAP, is reluctant in using WP7. Know who also uses the OMAP chips? Nokia.
Its also the same reason why WP7 isn't on ARM11 chipsets, leaving the growing low and middle end market.
If you have an OS that has to support different chipsets, you have two ways to pursue it.
1.) Go open source and "fragment" the kernel. That means each separate vendor and chipset maker can take the OS code and make their own version of the OS suited to their chipset,
without adding code support for another chipset.
This is what is happening to Android.
2.) Stay closed and create a monolithic kernel to support all chipsets in one giant OS. This is the Windows model. The end result of this is that you end up with an OS running on a given piece of hardware, loaded with stuff intended to run on all sorts of different hardware that is never used. The end result of this model is a maintenance mess and the more hardware has to be supported, the greater the mess becomes. It will reach to a point that the OS will suffer serious performance issues, and the only way to fix that is clean out the extraneous code out of the OS by greatly subtracting hardware support to only a few strategic platforms. Preferably one.
This happened to Windows Mobile. It happened to Windows Vista. The clean up model is Windows 7 and Windows Phone 7. But the cycle can begin again and still create a mess down the road.
Once your hardware support list gets longer, so is your testing and development cycles. Again, you see this with Windows, which has long development and testing cycles.
Microsoft is trying to make a game console environment out of mobile. As you know, game consoles have static specs that have a very long life. Xbox 360 has the same spec up to know since its introduction back when?
Games are the most unscalable of all software and if the platform maker (Apple, Microsoft, Sony, whoever) decides to emphasize games in their platform, they're trapping themselves in a corner in the future because its difficult to improve your hardware without breaking some game eggs. Your platform becomes defensive as it gets old, because you're trying to support legacy baggage. Every time you write code,whether its GUI or games, that's coded highly optimized against GPU hardware, you risk the code not being scalable and portable to different platforms.
