On Android Compatibility

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]

At Google I/O 2010, we announced that there are over 60 Android models now, selling 100,000 units a day. When I wear my open-source hat, this is exciting: every day the equivalent of the entire population of my old home city starts using open-source software, possibly for the first time. When I put on my hat for Android Compatibility, this is humbling: that’s a whole lotta phones that can all share the same apps.

Another thing we launched at Google I/O was an upgraded and expanded source.android.com. The new version has refreshed info on the Android Open-Source Project, and some new tips and tools for device manufacturers — useful if you’re an OEM. However, it also has details on the Android compatibility program, now. This is also aimed mostly at OEMs, but Tim Bray suggested that developers might be interested in a peek at how we keep those 100,000 devices marching to the same beat, every day. So here I am, back on the blog.

The F-word, or, Remember remember the fifth of November

I remember sitting with my colleagues in a conference room in Building 44 on November 5, 2007, listening to Andy Rubin and Eric Schmidt announce Android to the world. I remember a lot of the press stories, too. For instance, Android was “just words on paper” which was especially entertaining since I knew we were getting ready to launch the first early-look SDK a mere week later.

Another meme I remember is... yes, “fragmentation”. Literally before the close of business on the same day we announced Android (4:46pm to be precise), I saw the first article about Android “fragmentation.” The first day wasn’t even over yet, and the press had already decided that Android would have a “fragmentation” problem.

The thing is, nobody ever defined “fragmentation” — or rather, everybody has a different definition. Some people use it to mean too many mobile operating systems; others to refer to optional APIs causing inconsistent platform implementations; still others use it to refer to “locked down” devices, or even to the existence of multiple versions of the software at the same time. I’ve even seen it used to refer to the existence of different UI skins. Most of these definitions don’t even have any impact on whether apps can run!

Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.

Compatibility

Now, that’s not to say that there aren’t real challenges in making sure that Android devices are compatible with each other, or that there aren’t very real concerns that keep app developers awake at night. There definitely are, and I spend a great deal of time indeed thinking about them and addressing them. The trick is to define them clearly.

We define “Android compatibility” to be the ability of a device to properly run apps written with the Android SDK. This is a deceptively simple way to frame it, because there are a number of things that can go wrong. Here are a few:

• Bugs - devices might simply have bugs, such as a buggy Bluetooth driver or an incorrectly implemented GPS API.

• Missing components - devices might omit hardware (such as a camera) that apps expect, and attempt to “fake” or stub out the corresponding API.

• Added or altered APIs - devices might add or alter APIs that aren’t part of standard Android. Done correctly this is innovation; done poorly and it’s “embrace and extend”.

Each of these is an example of something that can make an app not run properly on a device. They might run, but they won’t run properly. These are the things that I spend my time preventing.

How It Works

As stewards of the platform we realize that it’s vital to allow only compatible devices to participate in the Android ecosystem. So, we make compatibility a strict prerequisite for access to Android Market and the right to use the Android name. This means that developers can rely on the fact that Android Market — the keystone of the Android ecosystem — will only allow their apps to run on compatible devices. It’s pretty self-evident that a single app ecosystem is better than many small ones, so OEMs are generally pretty motivated to ship compatible devices.

But motivation alone doesn’t get us very far without tools to actually ensure compatibility, which is where the Android compatibility program comes in. This program is like a stool with three legs: the Android source code, the Compatibility Definition Document, and the Compatibility Test Suite.

It all starts with the Android source code. Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device. For the most part, Android devices are running the same code. The fact that all Android devices run the same core Android code goes a long way toward making sure those devices all work the same way.

However, this doesn’t solve the problems of missing components or altered APIs, because the source code can always be tweaked. This is where the Compatibility Definition Document (or CDD) comes in. The CDD defines in gory detail exactly what is expected of Android devices. It clearly states, for example, that devices may not omit most components, and that the official Android APIs may not be altered. In a nutshell, the CDD exists to remove ambiguities around what’s required of an Android device.

Of course, none of that overcomes the simple reality of human error — bugs. This is where the Compatibility Test Suite comes in. The CTS is a collection of more than 20,000 test cases that check Android device implementations for known issues. Device makers run the CTS on their devices throughout the development process, and use it to identify and fix bugs early. This helps ensure that the builds they finally ship are as bug-free as possible.

Keeping Up with the Times

We’ve been operating this compatibility process with our OEM partners for over a year now, and it’s largely responsible for those 60+ device models being interoperable. However no process is ever perfect and no test suite is ever 100% comprehensive, and sometimes bugs get through. What happens then?

Well, we have great relationships with our OEMs, and like I said, they’re motivated to be compatible. Whenever we hear about a serious bug affecting apps, we report it to our partners, and they typically prepare a bugfix release and get it out to end users. We will also typically add a test case to the CTS to catch that problem for future devices. It’s an ongoing process, but generally our partners are as interested as we are in the user experience of the devices they sell.

The mobile industry today is “very exciting”, which is code for “changes painfully fast”. We believe that the only way Android will be a success is to keep up with that change, and ultimately drive that change. This means that over time, the CDD will also change. We’ll add new text to handle problem cases we encounter, and the actual requirements will change to accommodate the innovations happening in the field. For example, in the 2.1/Eclair CDD, we tweaked the CDD slightly to make telephony optional, which allows Android to ship compatibly on non-phone handheld devices. Whenever we do this, of course, we’ll make corresponding changes to the Android APIs and Android Market to make sure that your apps are protected from ill effects.

On a somewhat related note, a lot of ink has been spilled on the fact that there are multiple versions of Android out there in users’ hands at the same time. While it’s true that devices without the latest software can’t run some of the latest apps, Android is 100% forward compatible — apps written properly for older versions also run on the newest versions. The choice is in app developers’ hands as to whether they want to live on the bleeding edge for the flashiest features, or stay on older versions for the largest possible audience. And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded.

What It Means for You

All that is great — but what does it mean for developers? Well, we put together a page in the SDK Documentation to explain this, so you should take a look there. But really it boils down to this:

1. As a developer, you simply decide what features your app requires, and list them in your app’s AndroidManifest.xml.

2. The Android compatibility program ensures that only compatible devices have access to Android Market.

3. Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don’t have the features you listed.

That’s all!

There almost certainly will be devices that have access to Android Market that probably weren’t quite what you had in mind when you wrote your app. But this is a very good thing — it increases the size of the potential audience for your app. As long as you accurately list your app’s requirements, we’ll do the rest and make sure that your app won’t be accessible to a device where it won’t run properly. After all, we’re app developers ourselves, and we know how painful it is to deal with users upset about an app not working on a device it wasn’t designed for.

Now, that’s not to say that we think our current solution is perfect — no solution is. But we’re continuously working on improvements to the SDK tools and Android Market to make your life as an Android developer even easier. Keep an eye on this blog and on the Android Market itself for the latest info.

Thanks for reading, and happy coding!

HTC Droid Eris , the latest Android phone

There are many HTC Android phones like Google Nexus one. but HTC Droid is the first phone which has their Sense UI that integrated with Android OS. HTC Droid Eris is a very powerful phone which runs with a 1GHz processor and a 512Mb RAM. it has a 3.5 inch AMOLED capacitive touchscreen.
HTC Droid Eris comes with latest features like accelerometer, proximity sensor and a 3.5mm audio jack. the internal memory of this phone is 8GB and it supports up to 32GB memory cards.
the main camera of this phone is 8Mp, which is fairly enough to get high quality pictures. the camera supports auto focus, face detection and geo-tagging features. HTC Droid Eris has very good media features integrated with Android. it has a great media player and sound quality.
this phone has GPS receiver and navigator and it also supports A-GPS. in connectivity side, HTC Droid Eris has 7.2 MBP/s HSDPA modem and has both bluetooth and wi-fi. this phone comes with a Verizon contract.

Android Cloud To Device Messaging

[This post is by Wei Huang, who helped implement this feature. — Tim Bray]

In the just-launched Android 2.2, we’ve added a new service to help developers send data from servers to their applications on Android phones. Android Cloud to Device Messaging (C2DM) makes it easier for mobile applications to sync data with servers.

Most of the useful applications on your mobile phone use the Internet to keep users connected. Traditionally, many apps use polling to fetch data periodically. POP mail clients, for example, connect to the server every 15 minutes or so. Polling is fairly easy to implement, and works well in many situations. It’s tricky, though, to select the frequency: Poll too often, you may not see any new data, and create unnecessary stress on the server and network. Poll too rarely and the data on the device may become stale. Polling is especially problematic on mobile devices, because it consumes precious network bandwidth and battery life.

Having the server push messages to the client asynchronously may be a superior choice for getting the latest data to your applications, resulting in fresher data and more efficient use of the network and your battery. However, it’s also tricky to implement a good push solution, and it isn’t free as there is some overhead in maintaining the required connection. On a mobile device like an Android phone, implementing applications to receive these messages is tricky; you have to worry about patchy network coverage and zombie connections created when the wireless carrier’s routers time out connections that are idle for too long.

Many of the Google applications on Android already use push to keep their data fresh, for example Gmail, Contacts, and Calendar. Starting with Android 2.2, C2DM allows third-party developers to use the same service the Google apps do.

Here are a few basic things to know about C2DM:

• It requires Android 2.2; C2DM uses Google services which are present on any device running the Android Market.

• It uses existing connections for Google services. This requires the users to sign into their Google account on Android.

• It allows 3rd party servers to send lightweight data messages to their apps. The C2DM service is not designed for pushing a lot of user content; rather it should be used like a “tickle”, to tell the app that there is new data on the server, so the app can fetch it.

• An application doesn’t need to be running to receive data messages. The system will wake up the app via an Intent broadcast when the the data message arrives, so long as the app is set up with the proper Intent Receiver and permissions.

• No user interface is required for receiving the data messages. The app can post a notification (or display other UI) if it desires.

It’s easy to use the C2DM API. Here is how it works:

• To enable C2DM, an application on the device registers with Google and get a registration ID, and sends the ID to its server.

• When the server needs to push a message to the app on the device, it posts the message via HTTP to Google’s C2DM servers.

• The C2DM servers route the message to the device, and an Intent broadcast is sent to the app.

• The app is woken up to process the message in its Intent Receiver.

• The app can unregister with C2DM when the user no longer wants messages to be pushed to it.

That’s about it! All you need is a server that knows to talk HTTP, and an Android app that knows how to use the Intent APIs. Below are some code samples:

// Use the Intent API to get a registration ID
// Registration ID is compartmentalized per app/device
Intent regIntent = new Intent(
        "com.google.android.c2dm.intent.REGISTER");
// Identify your app
regIntent.putExtra("app",
        PendingIntent.getBroadcast(this /* your activity */, 
            0, new Intent(), 0);
// Identify role account server will use to send
regIntent.putExtra("sender", emailOfSender);
// Start the registration process
startService(regIntent);

The registration ID will be delivered back to your app via an intent broadcast with the Intent Action com.google.android.c2dm.intent.REGISTRATION. Here is a code sample to receive the registration ID.

// Registration ID received via an Intent
public void onReceive(Context context, Intent intent) {
  String action = intent.getAction();
  if (“com.google.android.c2dm.intent.REGISTRATION”.equals(action)) {
    handleRegistration(context, intent);
  }
}

public void handleRegistration(Context context, Intent intent) {
  String id = intent.getExtra(“registration_id”);
  if ((intent.getExtra(“error”) != null) {
    // Registration failed.  Try again later, with backoff.
  } else if (id != null) {
    // Send the registration ID to the app’s server.
    // Be sure to do this in a separate thread.
  }
}

On the server side, your server needs to get a ClientLogin Auth token in order to talk to the C2DM servers. When it wants to push a message to the device, it can send an authenticated http POST with:

• Authorization: GoogleLogin auth=<auth token>

• URL encoded parameters including the registration id, the data key/value pairs, a “collapse key” used for overriding old messages with the same key on the Google C2DM servers, and a few other optional params.

When you use the C2DM service, you no longer need to worry about dealing with flaky mobile data connections, or when the user isn’t connected to the internet (i.e. Airplane mode). C2DM keeps the messages in the server store, and delivers them when the device comes back online. Basically, you can leave all the hard work of designing a robust push service to Google. Your application can take advantage of push infrastructure we’ve already built and tested, and stay more connected to the internet. Best of all, you won’t ruin the users’ battery life.

Information about how to build C2DM enabled applications on Android is online at the code lab, and more will be coming as we approach general release.

Review: Griffin Elan Passport Case for iPad

UPDATE (5/28/10): Griffin has reached out and clarified that they've improved the Griffin Elan Passport case design so the loops blocking either the lock/landscape/portrait or speaker ports are no longer blocking.  I've included an updated picture at the bottom.

If you are looking for a professional iPad case that is easy to use without having to pull the iPad in or out of a sleeve, Griffin's Elan Passport may be a case worth consideration at $49 MSRP. With a folio-styled design, this attractive case is made of a synthetic material that looks like leather especially with its sporty white stitching along the border.  The inside of the Elan Passport is made of a grey micro suede material to gently caress your iPad; when in use, it reminds me one of those fancy legal pad folios often seen in a board room.  It also comes with 4 card holder to increase its usability.  The iPad installs easily and stays in snuggly and it definitely provides ample protection.

There are some areas for improvement from the Griffin Elan Passport case, for instance, two of the four loops that holds the iPad in actually interferes with the iPad's hardware design.  One of the loop blocks portion of the speaker/mic port and the other blocks the power button and the portrait/landscape lock.  All together, the case doesn't get in the way of using your iPad but its still a design flaw never-the-less.  I would have also liked to have seen this case to fold into a desktop prop like the Apple iPad case.

If you are a young professional and do not like the idea of constantly taking your iPad in and out of a sleeve based case, the Griffin Elan Passport is definitely a good choice for a work setting to impress your co-workers or clients.

Improved Loop design shown below (updated 5/28/2010):

Dalvik JIT

[This post is by Dan Bornstein, virtual-machine wrangler. — Tim Bray]

As the tech lead for the Dalvik team within the Android project, I spend my time working on the virtual machine (VM) and core class libraries that sit beneath the Android application framework. This layer is mostly invisible to end users, but done right, it helps make Android devices run smoothly and improves developer productivity.

The 2.2 release is particularly pleasing to me, as it is the first release since before 1.0 in which we have been able to deliver significantly new VM technology. And unlike much of what my team and I do, it is something that can be experienced directly by end users.

“Dalvik” isn’t exactly a household word (at least in my country), and most people wouldn’t know a virtual machine if it hit them in the face, but when you tell them you were able to make their existing device work better — run faster, use less battery — they will actually take notice!

What Makes This Possible?

We added a Just In Time (JIT) compiler to the Dalvik VM. The JIT is a software component which takes application code, analyzes it, and actively translates it into a form that runs faster, doing so while the application continues to run. If you want to learn more about the design of the Dalvik JIT, please watch the excellent talk from Google I/O 2010 given by my colleagues Bill Buzbee and Ben Cheng, which should be posted to YouTube very soon.

To be clear, the differences aren’t always dramatic, nor do they apply uniformly to all applications. Code that is written to run the CPU all-out can now do more in the same amount of time (running faster), and code that is written to be rate-limited can get its work done using less time and less of the CPU (using less battery). On the performance front in particular, we have seen realistic improvements of 2x to 5x for CPU-bound code, compared to the previous version of the Dalvik VM. This is equivalent to about 4x to 10x faster than a more traditional interpreter implementation.

The team is proud of our new JIT in general, but we are especially proud of two aspects of it:

Many previous JIT implementations react slowly, delivering performance improvements only after a long warm up period. In the extreme, it can be minutes or even hours before the code is fully up to speed. On the other hand, the Dalvik JIT reacts quickly, so that mere moments after you hit the “Start” button on your favorite game, you are already benefiting from the work of the JIT.

We are also very pleased with how little memory the JIT uses. The code for the JIT itself is well under 100k, and each process that the JIT runs in will typically only use another 100k or so of RAM. On the current generation of Android phones, device users won’t even notice this additional memory usage; on my own phone, I can still have literally dozens of applications warmed up in memory and ready to go.

The Dalvik team isn’t resting on its laurels, either. We are hoping to see the Dalvik JIT deployed on many devices in the coming months. Looking forward, the team has an endless list of ideas for making the VM and library code better, which we are diligently working on.

Diplomas: MTEdipl Syllabus and Student Handbook

Diplomas: MTEdipl Syllabus and Student HandbookThe distance learning and self-study Diplomas: Mobile Telephone Evidence (MTEdipl) Syllabus and Student Handbook is now available for download:http://www.4shared.com/document/7XHHJ1Ru/MTEdipl_Cata20.html

Nothing much new

As you guys can probably tell, I've been mostly busy with other real life stuff and I haven't been working on Android much. That will be changing pretty soon however.

I was able to have a lot of fun doing an interview on This Week in Android. Hopefully I wasn't too geeky for them!

There's nothing else new, I think. I'll try to integrate in the backlight stuff first and some of the cleanup that Bluerise did on the layout for the Android tree. That will be very important moving forward.

After that, there's a possibility that before moving onto the power management (which might be a fairly lengthy battle), I can whip up an installer and updater for current and future revisions that works through Cydia. Do you guys think I should work on that first or dive straight into the power management stuff?

Imagining a mobile Moodle

For this year's 4th International Slovenian MoodleMoot I decided to explore the efforts being made to bring Moodle to mobile devices. I found several interesting projects in this field, although I think we're just starting to explore all possibilities, and that more interesting developments will follow in the next few years, especially when teachers start experimenting with things like geolocation, augmented reality and resources that can interact with sensors on mobile devices.

The main goal of my paper and presentation was to invite teachers to think about possibilities that mobile devices can offer for education and the ways we could embed mobile learning in Moodle, a well established Learning Management System.

Here's the abstract from my paper Taking Moodle Out of the Classroom: Making Learning Mobile, Context-Aware and Fun:

"Mobile devices are becoming increasingly more powerful, better connected and are able to provide better user experience and new services based around location and context of users, which opens new possibilities for learning. The paper presents an overview of mobile learning and the efforts being made to provide better support for mobile devices and learning activities/resources in Moodle. In conclusion we also present some future trends in mobile computing that could also provide new ways of learning on the go."

You can see a video of my presentation at the conference on YouTube (total length 15 min):



And if you'd like to learn more about the topic, you can read my full paper on Scribd:

iPhone 3G binaries!

I wrote up a how-to for PC World on how to put Android on the iPhone 3G and the iPhone 2G and it went up today. I wanted to be there to tweet about it when it went up, but I've been keeping really strange hours lately and I wasn't awake for it when it went up.

But here are the binaries (for iPhone 3G, and for iPhone 2G), graciously hosted by PC World!

Please read the how-to that I wrote for PC World to on installing it. The steps are basically the same as before, except you can put the firmware in a directory on the iPhone OS data partition. This means that you don't have to modify the ext2 partition as before.

One thing I didn't mention is that you could perform the installation on OS X without a Linux VM if you recompile loadibec and oibc. Otherwise, the directions are the same.

Android 2.2 and developers goodies.

Today at Google I/O we announced that Android 2.2 is right around the corner. This is our seventh platform release since we launched Android 1.0 in September 2008. We wanted to highlight five areas in particular:

Performance & speed: The new Dalvik JIT compiler in Android 2.2 delivers between a 2-5X performance improvement in CPU-bound code vs. Android 2.1 according to various benchmarks.

New enterprise capabilities: We’ve added Exchange capabilities such as account auto-discovery and calendar sync. Device policy management APIs allow developers to write applications that can control security features of the device such as the remote wipe, minimum password, lockscreen timeout etc.

Faster, more powerful browser: We have brought the V8 JavaScript engine to the Android browser as part of 2.2. This has resulted in a 2-3X improvement in JavaScript performance vs. 2.1.

Rich set of new APIs and services: New data backup APIs enable apps to participate in data backup and restore, allowing an application's last data to be restored when installed on a new or a reset device. Apps can utilize Android Cloud to Device Messaging to enable mobile alert, send to phone, and two-way push sync functionality. Developers can now declare whether their app should be installed on internal memory or an SD card. They can also let the system automatically determine the install location. On the native side, a new API now gives access to Skia bitmaps.

Additions to Android Market: Android Market provides Android Application Error Reports, a new bug reporting feature, giving developers access to crash and freeze reports from users. Developers will be able to access these reports via their account on the Android Market publisher website.

For a complete list of everything we’ve included in Android 2.2, please see the platform highlights.

Developers can now download the Android 2.2 SDK and Android NDK, Revision 4 from the Android developer site.

Tools update

We are releasing new version of the Android SDK Tools, Revision 6, Eclipse plug-in ADT 0.9.7 and Android NDK, Revision 4.

Android SDK Tools, Revision 6, Eclipse plug-in 0.9.7

These new versions include support for library projects that will help you share code and resources across several Android projects.

Android NDK, Revision 4

Workflow improvements
The new NDK brings a host of workflow improvement, from compilation, to debugging. Starting with 2.2, the NDK enables debugging native code on production devices.

ARMv7 instruction set support
This release enables the generation of machine code for the ARMv7-A instruction set. Benefits include higher performance, as well as full use of the hardware FPU for devices that support it.

ARM Advanced SIMD (a.k.a. NEON) instruction support
The NEON instruction set extension can be used to perform scalar computations on integers and floating points. However, it is an optional CPU feature and will not be supported by all Android ARMv7-A based devices. The NDK includes a tiny library named "cpufeatures" that can be used by native code to test at runtime the features supported by the device's target CPU.

For more information, please see the releases notes for the SDK Tools, ADT, and NDK.

As I said at the beginning, Android 2.2 will be here soon, and some devices will get the update in the coming weeks. I invite application developers to download the new SDK and tools and test your applications today.

Check out the video below to learn more about Android 2.2.

The Google TV Story

Vincent Dureau, who’s in charge of Google TV, is a lean, bony-faced man with a strong French accent; not too far off my own age, I’d say. With the announcement imminent, he’s been too busy to write; I'm reporting on my talk with him to give a feel for the thinking behind the project. You’ll notice an absence of quotation marks; Vincent’s half of the conversation is reconstructed from the combination of my memory and notes. I think it’s accurate in essence, but certainly not in detail; among other things I can’t write with a French accent.

On why Google TV is needed:

Even two years ago you would have said that telephones are mostly for making calls, maybe for email and texting. Today, we know that phones can actually do a whole lot more. In the same way, people say that TV is just for watching TV. But, like the phone can be used for more than making calls, we believe that TV can be used for more than just video. Also, there’s not enough shelf space for the stuff on TV; not even with online channel guides and your PVR access and your racks full of disks. The shelf space should be as big as the web.

On why developers should care:

They’ve always had access to the desktop. With mobile devices, they managed to get into your pocket. Google TV brings them into the living room, which is where people live.

On what’s going to be in the SDK:

First, we have to make sure that most mobile apps work on your TV, too. Second, we should offer TV-specific features, like being smart about screen sizes, changing channels, embedding video streams, mashing up live TV and what’s on the PVR and what’s on the Web.

On the Google TV project:

The project started 2½ years ago, with a vision of a walled garden of TV-optimized web services. But the landscape keeps shifting, particularly in the capabilities of mobile devices. The only solution big enough for the problem is to bring the whole web to your TV.

On which apps will come with the initial release of Google TV:

First of all, we run Chrome so we can ship both Android and web apps. Some will be pre-loaded; this is a moving target but we expect that Listen, Netflix, and Amazon Video On Demand will be on board.

On what truly great Google-TV apps he imagines:

That’s irrelevant; the reason we’re building the SDK is to enable all those smart people out there that don’t work for Google to do cool stuff with TV.

On how it works if there isn’t a partnership between Google TV and your TV provider:

It should be pretty good; the device comes with an IR blaster and knows the IR interfaces for the popular satellite and cable boxes. You really should be able to get an integrated experience.

On himself:

He’s the guy who pitched the project to Google’s executive team. He has been at Google for four years, and was hired to work on TV, originally ads. Working on TV is pretty much the only thing he’s ever done. Prior to Google, he worked on compression and DIRECTV.

On which TV he watches:

He doesn’t watch TV, he tests it. His popular test materials are Battlestar Galactica, Life on Discovery, Democracynow.org, Al-Jazeera’s newscasts (they have reporters more places than any other network); and, these days, the NBA playoffs. He does a lot more on his TV than watch TV; he uses it to run Pandora and Last.fm to hear the music through the nice speakers. Whenever he hears a tune he likes, he buys it right there & then from Amazon, which can get a little expensive.

On how to get involved:

You can begin building optimized web apps today. If you’re interested in building Android apps, visit our Google TV homepage to sign up for updates on when the SDK add-on will be available. And if you’re interested in helping out in a broader scope, check out our Google jobs site and apply for an engineering position.

Latitude API Launch

Over at the Google Code Blog, there's a pretty significant announcement, about the release of APIs for Latitude. the idea, as you might expect, is that the best way to get good location-based applications is to put the tools for building them into everyone's hands.

A glance at the online documentation reveals an essentially-RESTFul API with JSON payloads, which should be easy to use from an Android app. It seems likely that a device which knows its location is a really good platform for building location-sensitive apps.

Apple, Adobe, and Openness: Let's Get Real

There's a huge debate online about who's "right" between Apple and Adobe in the dispute over allowing Flash on the iPhone. Both companies portray their actions as protection of users and developers, but in reality what they're both protecting is their profits. There's nothing wrong with doing that -- it's what companies are supposed to do. But the only truly innocent victims in this dispute are the people trapped between Adobe and Apple.


Why Apple really doesn't want Flash on iPhone

Steve Jobs outlined his case against Flash in a recent open letter. His arguments boiled down to this:

Flash is proprietary.
H.264 video is better than Flash video.
There are lots of games on iPhone, so you won't miss the Flash ones.
Flash is insecure.
Flash makes Macs crash.
Flash is slow and reduces battery life.
Flash doesn't work well with touchscreen technology.
As an independent development layer, Flash reduces Apple's ability to innovate.

I'm not going to evaluate each of those claims; others have done a good job of that already. But none of Jobs' points except the last one explains all of Apple's actions. Apple has consistently banned not just Flash but almost all independent platforms, including Java, QT, and Palm OS emulators. One of the most poignant examples I've run across recently is Runtime Revolution, which is basically Hypercard brought into the modern era. It's a nifty tool for making prototypes and interactive media products, and its creator had been heavily committed to iPhone as a development target, encouraged by Steve Jobs' public statement that a third party developer could create a Hypercard-like product for iPhone. But Runtime Revolution's CEO killed the iPhone project last week because Apple won't allow the product to run; his story is posted here (link).

The bottom line: Apple just doesn't like other platforms.

I think Apple is sincere when it says it views these platforms as a potential barrier to innovation. But I don't think that's the whole story. Independent platforms also make it easy for a successful developer to port its software to other platforms, like Android or Symbian. This cross-platform porting is something that Apple fears because it's what allowed Windows to catch up with Macintosh.

Here's a list of some major PC software products. Do you know what they all have in common?

Photoshop
Word
Myst
Excel
FileMaker
PostScript
PowerPoint
Illustrator

The answer: They were first successful on Apple systems, and only later took off in the PC world.

I was working at Apple when this process happened, and I can tell you that it was searing. Apple had invested countless hours and dollars marketing those products as prominent reasons to buy Macs, and then we saw that investment turned against us when the apps were made available on Windows.

Do you think Steve Jobs has forgotten that experience? Look how he started the open letter on Flash:

"Apple has a long relationship with Adobe. In fact, we met Adobe's founders when they were in their proverbial garage. Apple was their first big customer, adopting their Postscript language for our new Laserwriter printer. Apple invested in Adobe and owned around 20% of the company for many years. The two companies worked closely together to pioneer desktop publishing and there were many good times. Since that golden era, the companies have grown apart."

Can you hear the resentment? It reminds me of Bill Cosby quoting his dad: "I brought you into this world, and I can take you out." I think some of the key folks at Apple remember being "betrayed" by "their" developers, and they are determined never to leave themselves vulnerable to that again. I believe it's Apple's policy to keep iPhone and iPad developers as closely tied to the platform as possible, and to make it as hard as possible for them to move their products elsewhere. I think that's the core reason why Apple won't permit Flash, or any other third party platform, to run on iPhone.

If I were still working at Apple, I would probably do the same thing. That's not to say I like the policy, because it restricts customer choice and developer flexibility. But I understand the business logic behind it, and the depth of feeling Apple folks have on this issue. To Apple this isn't just about innovation, it's about business survival.

I just wish Apple had been more specific about what was allowed and not allowed on its platform. At times the rules seem very arbitrary. For example, Runtime Revolution is banned from iPhone, but a game creation environment called Game Salad says it is allowed (link). The company claims Apple privately promised that it could continue to run, but won't say what it did to get Apple's permission. Runtime Revolution thought it was following the rules too. A platform vendor is responsible for articulating exactly what developers will and will not be permitted to do, before they invest time and money. Apple was at best sloppy about delivering that information, and at worst it changed the rules in the middle of the game.


Adobe's Flash agenda

So we have Apple trying to keep developers on the farm, barefoot and pregnant. Does that make Adobe the liberator, throwing open the gates and setting developers free? Maybe, but only to the extent that it serves Adobe's own interests.

If you want to understand Adobe's agenda for Flash, you have to look back to 2006, when Adobe bought Macromedia. Just after the acquisition, Adobe CEO Bruce Chizen gave a very interesting interview in which he discussed Adobe's plans for Flash and related technologies (link):

Buying Flash "enables us to create an 'engagement platform.' Think of it as a layer or a vehicle in which anybody can present information that could be engaged with in an interactive, compelling, reliable, relatively secure way -- across all kinds of devices, all kinds of operating systems....If we execute appropriately we will be the engagement platform, or the layer, on top of anything that has an LCD display, any computing device -- everything from a refrigerator to an automobile to a video game to a computer to a mobile phone."

In other words, Flash becomes the developer platform, and the underlying OS is transformed into commodity plumbing. Adobe's focus at the time was on competing with Microsoft (the article mentions Apple only in passing and Google not at all), but when you declare war on one OS, you declare war on them all.

I don't think you can blame Apple for feeling threatened by this. (Or Google, for that matter, which has been running its own behind the scenes war against Flash by promoting HTML 5.)

I thought it was a brilliant strategy when Adobe announced it. Unfortunately, Adobe's execution hasn't matched its rhetoric. Four years ago, Chizen said Adobe would quickly merge Flash and Acrobat into a runtime environment that would own the next generation of applications. If Adobe had moved quickly, it might have made its platform into a contender, and the software market might look a lot different today. But the new platform, called Adobe Air, was very slow to come to market, and was focused on PCs rather than mobile devices. Today it has very little developer momentum.

Adobe spun its wheels in the mobile market in particular. It insisted on charging for the mobile Flash runtime for a long time, even though it knew that free runtimes are the key to adoption. And then much of the Adobe mobile team was fired in a series of layoffs starting at the end of 2008. Adobe had hired a lot of mobile industry veterans, and by firing them Adobe created the impression in the mobile industry that it was not serious about mobile. There's a very good discussion of some of Adobe's other mobile challenges here.

Fast forward a year and a half from those firings, and Apple has completely seized the initiative with mobile developers. Now Adobe is fighting a defensive battle just to keep Flash relevant.

There's an old quote attributed to Napoleon, "If you start to take Vienna, take Vienna." Adobe failed to take Vienna. Note to other tech companies: Don't declare your intention to take over the world; do it first and explain later. (By the way, this explains both Apple's strategy and Chinese foreign policy, but I digress.)

Because of this history, I find it hard to feel a lot of sympathy for the troubles that Flash is having. I also find it a bit disingenuous when Adobe says that it's fighting for a "multiplatform" world (link), when the company has said previously that it really wants a single platform, led by Adobe, that runs on top of multiple operating systems.

I'm also amused by Adobe's statements that it has always been a proponent of open standards. Adobe cofounders John Warnock and Chuck Geschke wrote:

"That, certainly, was what we learned as we launched PostScript® and PDF, two early and powerful software solutions that work across platforms. We openly published the specifications for both, thus inviting both use and competition. In the early days, PostScript attracted 72 clone makers, but we held onto our market leadership by out-innovating the pack."

Actually, Adobe held onto its leadership in part by building secret, proprietary extensions to PostScript and tying its paid products to them. In an example I saw personally, Adobe's secret APIs in PostScript enabled it to create higher-quality fonts that looked better and ran more efficiently than competitors. As a PostScript developer you were welcome to work with Adobe's low-quality font technology, but Adobe refused to allow any developer to access its proprietary high-quality APIs.

Sounds like something Apple would do, doesn't it?


The real battle

So the real situation around Flash is that Apple won't permit most other platforms on iPhone (no matter how innocuous they are) because it thinks they threaten its survival, while Adobe wants its platform on iPhone so it can set a de facto standard and make money from it. Neither company is really focused on protecting developers or users as its main goal; they are fighting over who gets to use developers to make money.

Unfortunately for developers, this situation makes it more and more likely that the mobile world will continue to be split into incompatible platforms, forcing them to rewrite their programs multiple times in order to reach the broadest group of customers. Theoretically, the mobile browser could become the grand unifier of mobile development, and as I have said before I wish it would (venture capitalist Eric Ver Ploeg makes the case for it here). Unfortunately, the development of those standards has been incredibly slow and political, and after watching that process for years, it's becoming harder and harder to convince myself that it'll ever speed up. I hope it does, but I suspect that one reason Apple's willing to support web standards is because it believes it can dramatically out-innovate them.

In the meantime, Apple and Adobe will continue to duke it out. If Adobe could get customers and developers to boycott Apple products, I guess Apple might be forced to back down. Or Adobe might convince the government to charge Apple with noncompetitive behavior. But I think neither of those is likely to happen. The most likely outcome is that Apple will hold the line against Flash, Adobe will try to run Flash on every other mobile platform, we'll get a lot more posturing from both companies -- and a lot of websites will get rich running Adobe's anti-Apple ads.

Stand By...

I'm posting this from Moscone West, the site of Google I/O 2010. Some things that it may be useful to know:

• The official hash tag is #io2010

• The keynotes will be live-blogged all over the place (thus, not here) and also live-streamed on YouTube.

• If you're mad because you couldn't get a ticket, we're sorry, but you're not alone. We have filled Moscone West to the very absolute splitting-at-the-seams max. There are a ton of Googlers who couldn't get in.

Things have already started; above is our own Roman Nurik giving the first Android session at the pre-IO Bootcamp.

Above are the signs over the Android part of the main gathering area. There are many tantalizing display cases and tabletops; gleaming and empty now, but not for long.

Meta-Blogging

Thursday is the big Android day at Google I/O. There will be announcements. We're going to try to use this blog to deliver more depth and perspective than you can expect from an executive on a stage in a keynote. So we've lined up a whole lot of blog posts; more than any human could be expected to read in a day.

The plan is to have a couple of posts on Thursday summarizing and highlighting what we think are probably the big-news stories. Then we'll have more detailed technical pieces every other day or so for the next couple of weeks, filling in the details behind the announcements. It's heart-warming how eager the engineers are to tell the world about what they've been building, and it makes me happy to facilitate the process.

There are other Google blogs that are going to be working hard too, telling the other stories coming out of this gathering. We'll post some links to things that seem particularly newsworthy, either to the world in general or to the Android comunity in particular.

Stay tuned!

Revew: Griffin FlexGrip for iPad

Upon first glance, I thought to myself, will a skin-like case for the iPad work as good as the ones we've been using on iPhones?  Well, the answer is "Yes".  If you've handled an iPad before, you'll notice the device can be a little slippery given the slick aluminum casing on the back, most people would try to avoid the inevitable and minimize their finger contact on the screen thus increase the risk of dropping their beloved iPad.  Thats why it all makes sense after I installed Griffin's FlexGrip (MSRP $34.99), a silicon skin for the iPad.  The case is easily installed and instantly provides protection, padding and extra grip. There are all the appropriate cutouts for various ports and control precisely carved out for ease of control. Overall, I was pleasantly pleased with using this skin. In fact, after a days use, I am convinced that this is probably the case for me since it offers the most versatility.  With this case on, I can easily toss the iPad into my messenger bag not having to deal with another case.  For the most part, I'm not concerned about the screen being scratched but if you have other hard objects in your bookbag, you might want to use a sleeve or portfolio style case just to provide proper protection.

Status update

I know the binaries for the iPhone 3G are taking a while. Everything is basically done and all the code I have is in the source repositories so people are free to build it for themselves. However, I wanted to improve the packaging slightly to ease installation (no longer requiring people to modify ext2 partitions). The release of the binaries (and a how-to) will be sometime within the next week.

The binaries will have more features than the iPhone 3G demo showed: It will have full calling and sound support. The code for that (and everything else) is already finished and is in my github if you would like to check it out.

Meanwhile, I am working on some stuff that is slightly more fun. Last night, I brought openiboot for the first-generation iPod touch up to scratch so that it supports all the features the other ports of openiboot support: sound, multitouch and SDIO (for WLAN) are the notable things I had to fix. Earlier today, I figured out how to drive the piezoelectric tweeter on the iPod touch.

Hopefully, we'll be able to roll out the iPod touch binaries with the 3G binaries and get on with the real work: power management and the little details that will make Android a truly viable alternative on our three early ports.

In the meantime, I hope to find some time to play with the piezoelectric buzzer on the iPod. Two neat projects I think I or some other enterprising person should do with it:

The first one is implementing an interface for it that is compatible with QBASIC's PLAY statement. QBASIC was my first experience with computer programming. In fact, I learned the language exactly concurrently with English.

The second is taking the considerable body of knowledge people have about programming PC Speakers and getting them to output PCM sounds from them and adapting them to the iPhone. It would be an awesome hack to get the iPod touch speaker playing some real music! I am reading this page for some hints, but I would love suggestions or help from people who may have had more experience.

One of the things I have always really wanted to do is to create a demoscene-style demo on the iPhone. I've always admired the demoscene and I want to be cool like them but I don't have the right skillset to do the "graphix" and music. It would be cool if we can get a group together (if any of my readers are demosceners!) and create the first iPhone demo to run on bare metal.

P.S. I switched over to IntenseDebate for the comments. One of the reasons is that blogger lets a lot of spam comments through, forcing me to do moderation on older posts (I only filter comments that are clearly spam: I let anything else through, including flames, trolling, etc.). I would rather not have to perform moderation so I'm hoping IntenseDebate will do a better job. Also, some of these posts get a huge volume of comments and I think IntenseDebate would do a better job organizing the comments.

Diplomas: Mobile Telephone Evidence (MTEdipl)

Diplomas: Mobile Telephone Evidence (MTEdipl).The Diplomas provide individuals with a path to recognition for demonstrating development of students knowledge, skill and experience for those involved in mobile telephone examination and evidence or for anyone interested in this field of distinction..Empowering students to have confidence in themselves, their knowledge and skills, is one feature in

Twitter for Android: A closer look at Android’s evolving UI patterns

[This post is by Chris Nesladek, Interaction Designer, Richard Fulcher, Interaction Designer, and Virgil Dobjanschi, Software Engineer — Tim Bray]

Along with our regular updates of the Android platform, we like to build example applications that showcase best practices for UI features and behavior patterns, to help our 3rd party developers create even richer applications.

For example, the Twitter for Android application that we worked with Twitter to design gives you, the 3rd party developer, a working example of how you can customize and build an application that’s both fun and highly functional. This blog post is meant to showcase these patterns along with some recommended implementations as you start to develop your applications around them.

Let’s get started and explore these patterns in more detail now.

Pattern 1: Contacts Sync with Address book at Sign in

One of the most important intents we added to Twitter for Android was the ability to sync your Twitter contacts into the phone. This integration also allowed us to give Twitter users with an Android phone the use of the QuickContact widget, which gives users a choice of ways to contact their followers.

We recommend:

• Using this activity upon first signing into an application.

• If your app has no sign-in, showing this screen at first launch to improve discoverability of contact sync.

Pattern 2: Twitter account integration with QuickContact for Android

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app. QuickContact for Android provides instant access to a contact's information and communication modes. For example, a user can tap a contact photo and with one more tap launch a call, SMS, or email to that person. Other applications such as Email, Messaging, and Calendar can also reveal the QuickContact widget when you touch a contact photo or status icon.

Pattern 3: Dashboard

The dashboard pattern serves as a home orientation activity for your users. It is meant to include the categories or features of your application. We recommend including an Action bar on this screen as well.

The dashboard can be static or dynamic. For example, in the case of our dashboard for Twitter, we used the goodness of Live Wallpapers introduced in 2.1 to create an animated dashboard complete with real-time trend bubbles and the Twitter bird silhouette.

We recommend:

• Using this pattern to showcase the most prominent features of your app.

• Adding some unexpected delight to this screen, making it engaging without overwhelming the user.

• Exercising caution - for some apps, the user will want to jump directly into the meat of the application. For others, this sort of welcoming dashboard will be the right starting place.

Pattern 4: Action Bar

The Action bar gives your users onscreen access to the most frequently used actions in your application. We recommend you use this pattern if you want to dedicate screen real estate for common actions. Using this pattern replaces the title bar. It works with the Dashboard, as the upper left portion of the Action bar is where we recommend you place a quick link back to the dashboard or other app home screen.

We recommend:

• Placing an Action bar at the top of the screen to house the most common actions for your application that work across all activities.

• Using no more than 3 onscreen actions for the Action bar. Use the main menu as overflow for actions that are less important. The balance between Action bar and main menu will ensure the richness of interaction that is Android.

• Making the left-hand region actionable, offering one-touch return to your dashboard or other app home.

Pattern 5: Search Bar

The Search bar pattern gives you a fast way to switch between resources that are searchable by your application. For example, with Twitter for Android, we used the pattern to support searching within Tweets as well as People. When triggered, this pattern sits on top of the Action bar.

We recommend:

• You support suggestions.

• You keep a search history so users upon returning to the search activity can have quick one-button access to previous searches.

Additionally, you can feel free to use the Search bar selection mechanism as a replacement for tabs since it’s really just a fast pivot on a data set. If you have more than 3 data sets, tabs become problematic since no more than 3 can be onscreen at once. For example, look at how we implemented the Profile switching mechanism below:

Pattern 6: QuickActions

QuickActions is our newest UI pattern. Currently, it has been implemented as a fast, engaging, popup triggered by an onscreen UI element that identifies it in as minimally disruptive way as possible. We recommend you use this pattern for list views that are data intensive where items inside the list have contextual actions associated with them. QuickActions can be used as a replacement for our traditional dialog invoked by long press.

By choosing to use this pattern as part of a list, we made it easier for Twitter users to take action on the information in the list view by keeping the item and associated actions in context. We also took the extra step of making it easier to target links in list views by turning off the list view button element as a secondary component to making this pattern even more usable. This way users of Twitter for Android can view links with one tap and/or see the posted tweet on a map by tapping the tweet meta data directly.

We recommend:

• Creating a UI element that is minimal and recognizable as an action popup; either a frame around an image or an icon in a list item.

• Only using this pattern in applications where the data is intensive.

• Placing the action popup below or above the information you wish to allow users to take relevant contextual actions on. This will make it easier to associate the actions with the content in view.

• Turning off the entire list view button element so that regions can be easily targeted for the user.

Pattern 7: Companion Widget

The companion widget pattern is something we recommend all developers think about deeply. The widget you create should be more than a big button link into your app. Used correctly, it can provide a place on a home screen that personalizes, albeit in a small window, your application.

In the case of Twitter for Android, we designed and built small and large-sized widgets to support different types of functionality. Both widgets let a user view his/her tweetstream. However, the smaller widget hands off to the application to create a reply to a tweet from the stream, whereas the larger one gives direct access to the Tweet compose activity.

We recommend:

• Identify your application in the widget with a brand icon

• Make this more than a button into your app. Give your user an action or view into the app itself.

• Keep the activity stateful so that on exiting the application and re-entering a user is returned to the same context in the activity, minimizing the impact of using the dashboard if it is used.

Don’t think we quite got something right? As many of you know, we’ll soon be open sourcing this application code under the Android Open Source Project. We look forward to seeing what you can build starting from this code these UI patterns. In the meantime, Happy Tweeting!

Twitter for Android is available in Android Market for immediate download. It is compatible with Android 2.1/2.0 devices, with support coming soon for more.

Come check out the Android UI patterns session at Google I/O next week to learn more about how this applies across our framework and not just in the Twitter app.

Having Fun and Getting Fit: An Overview of Exergames

With the arrival of Eye Toy for Playstation 2, the widely popular Nintendo Wii, and the upcoming release of Project Natal for Xbox, the term exergaming - the use of video games as a form of exercise - has started gaining popularity. But how effective are these games? Can you really get fit by playing, let's say, Wii Sports?

It's been a while since I've embarked on a quest to find the best exergame aka geek friendly exercise, and throughout the course of my journey I've tried out many different games (mainly on Playstation 2 and Nintendo Wii), so I thought I'd do a little overview of what you can expect to gain from different types of exergames.

Casual Exergames: Lots of Fun with Friends

Examples: Wii Sports, Mario Cart Wii

Most Wii games fall into this category and I would also include games supposedly more focused on exercise, like Wii Sports. These games count on a limited amount of moves, and you don't even have to invest a lot of effort into the right moves to make it through the game. The focus is on fun rather than burning calories and these games usually won't hold your attention for long.

So, don't be fooled by the Sports in the title; these games won't really prepare you for any real sport, but the plus side is that they really are a lot of fun to play when you're having friends over!

Medium Intensity Exergames: Balancing Fun and Exercise

Examples: Dance Dance Revolution (DDR), Eye Toy Kinetic, We Cheer, Wii Fit

The games in this category can be quite demanding, especially if played on higher difficult levels, although they sometimes don't get your whole body moving (for instance, We Cheer is mostly a good exercise for your arms). But be prepared to spend a lot of time navigating menus, choosing exercises, songs and what not. Also, be prepared to invest some time in making sure your moves are detected properly, which can be quite frustrating and can spoil your immersion in the game. However, if everything works fine, these games provide a lot of fun and some exercise, but a lot of time is lost on pointless tasks (and if you're out of luck, a cumbersome navigation through menus).

The bottom line is: if you invest enough energy in these games, they can make you sweat, but you have to play these games a whole lot (read: at least an hour per session) before getting any real results.

High Intensity Exergames: Emphasizing Exercise

Examples: My Fitness Coach (Wii)

Interestingly enough, the highest intensity exergame I found for the Wii doesn't even use the motion sensing abilities of the Wiimote or the Wii Balance Board. It's just a continuos exercise routine that really gets you moving around. It's up to you to make sure you're doing the right thing, but if you're interested in getting fit, you should have the motivation for that anyway. What I like about My Fitness Coach is that you only have to choose the duration and daily focus of your workout, and everything else is done for you. No wasting time on menus, you're just asked to assess the difficulty of the workout after completing major sections, so that the next workouts can be adjusted accordingly. A great feature is also that you are asked to do a Physical Challenge every 10 workouts, so you can really track how your workout affects different parts of your body.

All in all, My Fitness Coach is a real exercise that will can have real effects on your fitness level if you decide to stick with it. And it's a nice way to get prepared for more difficult forms of exercise if you're starting from scratch.

Leaving the Game Consoles: Nothing Beats the Real Deal

Examples: Nike+

Not surprisingly, at the end of my exergame journey I came to the conclusion that nothing beats the real deal: going out and running. But as a true geek I wasn't prepared to settle for a workout without gadgets, so I decided to give Nike+ iPod Sports Kit a try. While it's not a true exergame, it's a great gadget that can keep you motivated and provides real-time feedback during your runs. After every run, I love to see how the latest run compares to previous ones, compete in different online challenges with or against other runners and set personal goals to beat.

As you can see from my profile, I haven't been using Nike+ for long, but I find it very easy to decide to go for a run after seeing how close I am to a goal or how other runners are beating my distance. Nike+ brings elements of games to real exercise and that I think is the winning combination.

Exergames: Easy Start and a Filler Activity

So, what exactly is the role of exergames then? Are they worth it?

If you're looking for something that will help you to get up from the couch, I'd suggest starting with some of the Medium Intensity Exergames I listed and then progress to Higher Intensity or outdoor activities. Having fun can really make you appreciate exercise and I found less intensive games like Wii Fit to be a great way to get used to regular workouts, but you'll probably soon feel the desire to progress to something more demanding (especially if you want visible results).

Apart from providing an easy start, exergames can also provide you with an exercise option on days when you feel like taking a little break, but still want to workout. For example, my current workout routine includes Nike+ running around 3 times a week and My Fitness Coach in between to strengthen specific body muscles. And when I just feel like having fun, a dose of We Cheer can also provide some light exercise.

To sum it up: exergames do have some positive effects, but don't rely on exergames alone to get fit. I can certainly recommend using them as a fun way to encourage and maintain regular exercise - but don't forget that there are also gadgets like Nike+ that can make serious outdoor activity more enjoyable.

Samsung W960 world's first 3D phone with AMOLED display

Mobile phone technology changing every day. first it came just as a calling device but now it has become a pocket computer. i think you know about 3D movies. now samsung has recently announced their newest mobile phone which has a 3D AMOLED display. and Samsung W960 is the world first mobile phone which has this kind of capability.
also to watch a 3D movie, we need to wear a special 3D glass at the cinema hall. but the special thing of this mobile phone is, you don't need any glasses to wear. there is a dedicated 3D shortcut key on the phone and when you activate it, it just shows the 3D images.
Samsung announced about Samsung W960 in this April and it will be available at the end of the year. also they going to manufacture it for the korean market only.
other than the 3D display, this phone has couple of special features. Samsung W960 is a full touchscreen phone which has a 3.2 inch capacitive touchscreen. it also has an Accelerometer sensor and Gesture control as well. according to the media sources, Samsung W960 comes with samsung's Bada OS.
the main camera of this phone is 3.2 MP and it supports video recording. also has Samsung W960 DMB TV feature. in connectivity side Samsung W960 supports 7.2 mbps HSDPA speed. it has bluetooth but wi-fi is not available.

Review: Griffin Elan Sleeve for iPad

Griffin, as you would have expected, has introduced a series of iPad accessories to help you protect your new gadget.  Tonight, I'm reviewing a sleeve called Griffin Elan Sleeve for iPad (MSRP $49) as part of my iPad case review series. At first glance, the sleeve looks and feels like its composed of a leather exterior but it is actually made of a synthetic material held together with white stitching giving a sporty look. First impression with the Elan Sleeve is that it is thin; even with the iPad inside, the case doesn't add too much thickness to the iPad while offering ample protection.  The Elan case has a cool little trick to its design; by pulling on the folding clasp, the iPad will be released from the case with minimal effort.

Overall, the Elan Sleeve is a very solid case with a very professional styling.  Like my previous review, my only feedback is the sleeve design would require you to tend to both your iPad and the sleeve while on the go.  The case is for iPad only so be sure to pack your charger and cable separately.

Tory Burch Launches Mobile Web with Free Shipping

Tory Burch, the popular women's shoe/fashion designer has just launched a beautiful mobile website fully capable of commerce at m.toryburch.com.  The site is powered by Digby and I was quite pleased with the design, functionality of the site as well as the quality behind the site. 

What I found interesting is the fact that Tory Burch is offering free standard shipping on all mobile web purchase, pretty start strategy to entice customers shopping on the go.

Review: ColcaSac case for iPad

The folks at ColcaSac was kind enough to send me a review sample of their latest iPad case and I was eager to test it out on my iPad.  This sleeve case is composed of a durable linen/canvas like outer material while the lining inside is made with a plush sherpa fleece which caresses the iPad.  The case fits like a glove and provides ample protection.  ColcaSac iPad (MSRP $35) case has an external pocket which is the only iPad case I've seen thus far that offers for storage of the charger; definitely a convenient feature.  The thickness, however, is noticeable since it is filled with the said sherpa fleece lining when compared to other iPad cases.

Since this case is a sleeve design, make sure that is what you are looking for as it would require you to take your iPad in and out of the case each time you need access.  I think its more suitable for people that are more stationary so removing and storing of case when in use is more appropriate.  For business travelers, I would probably recommend a portfolio-styled case. ColcaSac has been making the same cases for Macbook and Macbook Pro for quite some time so you can be sure this is made of the same high quality by a very solid company; not to mention they are proudly made in the U.S.A (Salt Lake City, Utah to be more specific).