Samsung Corby Folder gets official
LG GW620 launched in Italy as LG LinkMe
Google Nexus one coming to Verizon in March, Vodafone in April
Motorola Cliq OTA Update Causing Problems
Urbanspoon for iPhone, iPod touch, and iPad Now Available
Mobile Phone is not a 'Closed Container'
Nokia E73 upcoming nokia phone details
this phone runs with Symbian OS and it has an Accelerometer sensor for rotate UI. the internal memory of this phone is 190MB and it supports up to 16GB memory cards. Nokia E73 has both bluetooth and wi-fi features. it supports 3.6MBP/s HSDPA connectivity.
the main camera of this phone is 5MP and it comes with a LED flash. also Nokia E73 has a GPS receiver. it has the latest version of Nokia maps.
AT&T to Launch LG Arena, Mobile TV Phone for $200
NBC Gives Mobile Access to the Olympics
YouMail App for BlackBerry, Android, and iPhone
Nokia X6 16GB hits Nokia Flagship Stores in the U.S.
Motorola Quench Ready for March Launch Via TIM Brazil
Nokia N97 mini Gold Edition Officially Announced, Priced at $850
Recognizr: Face-Recognition Software for Android [Video]
How many Kindles have really been sold? (And other interesting tidbits about ebooks)
So I was very happy Wednesday when the Book Industry Study Group (a publishing industry trade group) gave details from its recent survey of ebook adoption in the US. The survey was first revealed in January, but the press release was very sketchy and sometimes confusing. In its presentation at the Tools of Change conference, the BISG gave much more details on the results. My highlights from the presentation:
Ebook usage is growing fast, but it's still small. Roughly 2% of American book buyers over age 13 are active ebook users, meaning they obtained an ebook or a reader device in the last year. About half of those were first-time ebook buyers, so the usage of ebooks has probably roughly doubled in the last year. BISG is doing multiple waves in the survey, and says it found a 25% increase in ebook usage just over the holiday season, so it was a pretty good Christmas (and Hanukah) for ebooks.
The most-used device for reading an ebook is a personal computer (47%). Amazon Kindle is number two (32%), followed by Apple's iPhone and iPod Touch (21%).
Either there's something wrong with the numbers, or Amazon hasn't sold quite as many Kindles as some people think. More on that below.
What does it mean?
PC leadership is no surprise. There are so many PCs in the US that even a small percentage of PC users reading ebooks will swamp everything else. BISG said that the PC share of ebook reading is declining as other devices grow, also what I would have expected. I bet that in a year (or two at the most), a majority of ebook readers will be on non-PCs.
Apple is closer to Kindle than you might expect, but... A tidbit that jumped out at me was Apple's share of ebook usage. Kindle has gotten all the attention, but Apple has about 2/3 the share of Amazon in ebook usage without even trying. However, before we set off another round of "Apple uber alles" on the web, there are several big caveats:
--BISG didn't report on the number of books bought per platform. Based on my experience at Palm (which had an active e-reading community), I suspect that a lot of those iPhone book readers are pretty casual, buying a few books or publications to kill time when they are bored. I believe Kindle users are probably much more active readers.
(For comparison, about 4% of the Palm OS users in the US were reading ebooks at least occasionally in 2002. That total rose to about 8-10% if you included the Bible -- it was by far the most popular ebook. That amounts to about 1.5-2 million ebook users on Palm OS alone.)
--Apple and Kindle are also different demographically. After the presentation today, BISG told me that Kindle readers are older and more likely to be female compared to Apple readers. What we may be seeing is that if someone already carries an iPhone or iPod Touch, they're less likely to invest in yet another device just to read on it. Or maybe younger people just find it easier to read on a tiny screen. Either way, I think it's pleasant that Apple and Kindle are reaching somewhat different audiences rather than just stepping on each other.
--And of course the iPhone/iPod Touch installed base is a lot bigger than Kindle's. So as is the case with PCs, even relatively low ebook usage on the iPhone will add up to a lot of users.
How many Kindles are really in use? As far as I can tell, Amazon hasn't released any Kindle device sales figures, other than a quote referring to "millions" of users. Several analysts have jumped on the use of the plural as evidence that at least two million Kindles have been sold. But I think the BISG survey doesn't support that. Here's my math:
--About 2% of book buyers have ebooks and/or ebook devices.
--About a third of them have Kindles (that's 0.67% of active book buyers).
--If 0.67% of book buyers in the US is two million people, then there are 300 million active book buyers in the US. That is the entire US population, including infants and people who don't like books. I don't know what the base of active book buyers is in the US, but my guess is it's not over 200 million, meaning the installed base of Kindles would be about 1.3 million.
It's tricky to play with survey results when the percentages are this small -- the margins of error become very significant. But for now I think the BISG survey raises some questions, and I'm not willing to accept the two million figure for the Kindle installed base without some more rigorous evidence to support it.
Other tidbits
BISG is not going to release all of the information from the survey (that goes only to the companies that paid for it). So I took as many notes as I could during the presentation. Here's what I captured:
Ebooks are somewhat cheaper than hardcovers
On average, an ebook costs $6.25 less than a hardcover book. This is a huge issue to the book publishing industry, which worries that ebook sales will cannibalize hardcover book sales. My comment: Of course they do, get over it. The thing publishers should be looking at is the much higher margins they make per ebook sold. I don't know of many industries that resist moving to a higher-margin product, but publishing appears to be the grand exception. Of course, the thing worrying publishers is the decline of independent bookstores, and they're afraid ebooks will accelerate that. But the decline of the bookstore has almost nothing to do with ebooks -- it's being driven by online sales of paper books and predation by retail chains.
Demographics
-Ebook buyers are 51% men (compared to 58% women for paper books).
-Ebook buyers are higher income than paper book buyers. Not a lot, but significantly higher income. No surprise there -- most poor people can't afford several hundred dollars for an ebook reader. Betcha they don't buy a lot of hardcover books either.
Cannibalization
Among ebook buyers, 11% no longer buy any paper books. 8% buy mostly ebooks, and about 30% prefer to buy ebooks. So about half of ebook users prefer ebooks to paper books. That's actually a lower percentage than I expected for something that is supposed to take over the world. But remember, half of ebook users are reading on PCs. What I really want to know is the percentage of Kindle users who prefer ebooks; that'll tell us how satisfied Kindle users are.
Preferred device used to read ebooks
-PC: 47%
-Kindle: 32% (and rising in later waves of the survey)
-iPhone: 11%
-iPod Touch: 10% Hmmmm! iPod Touch really is a PDA.
-Other smartphones (including Blackberry) 9%
-Netbooks 9%
-Sony Reader 8%
-Barnes & Noble Nook 8% (the BISG folks noted that Nook was just starting to sell at this point; they believe some users confused Barnes & Noble ebooks with the Nook device)
Genres of ebooks
-General fiction, 31%
-Mystery 28%
-How To 25% (but #1 over Christmas)
-Science Fiction
-Biography
-Business
I don't know where religion and travel went. I need to learn more about how this question was asked.
Meebo iPhone App to Chat With Friends on AIM, Gtalk, Yahoo, MSN
Google Earth has landed for Android 2.1
T-Mobile Pulse Mini does cheap, tiny, prepaid Android for Europe
HTC Desire leaked and rom ported to Nexus One
Dell Mini 3 Android Smartphone Showcased at MWC 2010
Humanitarian Aid or Pay As You Throw?
Review: Griffin Clarifi in White Finish
I managed to get a review unit of the recently released Clarifi w/ White Finish for my wife's white iPhone 3G so it will no longer feel like it is going through identity crisis. Since the function of this case did not change, feel free to refer back to my original review to see why I love the macro-lens so much. In my previous review, I often refer to the original case's glossy black finish as Darth Vader-like; in this new finish, the glossy white reminds me of the Storm Troopers, how funny. The new finish compliments white iPhone 3G or 3GS perfectly. As a reminder, I really prefer having portions of the backside composed of a rubberized material which prevents the phone from sliding out of your pocket easily.
Overall, this Clarifi case update is every bit as good as the original black ones, the only major difference is that I noticed screen protectors are no longer part of the package; if you have been holding off buying the original Clarifi case due to its color, I'm pleased to tell you that this white Clarifi case is here to please. [MSRP: $35 , available directly from Griffin]
Trapster knows where the Speed Traps are
Until this visionary device comes along, I have found an interesting little app called Trapster which looks to be available across just about every mobile OS (iPhone, Android, BlackBerry, WinMo, WebOS, Symbian, etc...) that is dubbed as the "Speed Trap Sharing System". The app is a marriage of your standard social-based application that encourages people in the network to share the latest spotting of traffic police spots, speed cams and various other roadway information. Based on the various settings and filters available, users can customize alerts and sounds to notify you as you reached certain types of speed trapes. This alert can even be delievered via iPhone's push notification feature which doesn't even require you to run the app.
Apparently, this app has gotten strong buzz and some sheriff's office are even working with Trapster in an attempt to slow motorist down. While we don't condone speeding and reckless driving from this blog, the concept of this application is really interesting; it is one of those apps that will work really well if it can create a massive user community to help maintain it; or it would not work at all.
Google Shopper App
The mere fact that Google engineers know how to produce a high quality application isn't so shocking. The underlying significance here is that Google has been leveraging its Android OS Marketplace to attract mobile app ideas (developers flocked to Android because they resent Apple's way of running their app store); but as Google sits back and identifies an area for growth, it will enter the game and become a player with an unfair advantage against those app developers who came up with the idea in the first place. Given the way they've entered the hardware handset game (NEXUS One), the pattern is now clear.
HTC Desire new Android HTC phone
it has a 3.7 inch AMOLED capacitive touchscreen and it has 480 x 800 pixels resolution. also HTC Desire has a track ball. it supports multi-touch and has an Accelerometer sensor as well. this mobile phone has very good sound quality and it supports Dolby Mobile sound enhancement. like Google Nexus one, HTC Desire has a 1GHz processor and 512MB RAM. the internal memory of this phone is 576MB and it supports up to 32GB memory cards.
in connectivity side, HTC Desire has 7.2MBPS HSDPA speed and 2MBPS HSUPA speed. it also has bluetooth and wi-fi features. the main camera of this phone is 5MP and it supports HD D1 720x480 pixels resolution 30fps high quality video recording. HTC Desire has a good GPS receiver and a digital compass as well.
Samsung I8520 Beam projector phone | mobile phone with a Projector
Samsung I8520 Beam has a 3.7 inch AMOLED touchscreen which supports 480 x 800 pixels resolution. it supports multi-touch and has a new interface called "Projector UI". the phone has DNSe technology which gives very quality sound output. it also has a 3.5mm audio jack.
As i mentioned earlier, I8520 Beam runs with Android OS, v2.1 Eclair version. it has a 800MHz processor and 384MB RAM. the internal memory of this phone is 512MB and supports up to 32GB memory cards.
Samsung I8520 Beam has a 8MP main camera which supports high end features like Geo-tagging, face, smile and blink detection. it it allows HD video recording; 720p and 30fps format. the projector type is WVGA and you can directly project the phone screen to a wall. also Samsung I8520 Beam comes with a good media player, image editor and a GPS receiver.
Yelp iPhone App Rocks!
Yelp Mobile coupled with a GPS-enabled phone is a match made in heaven; I rely on it so much as the voice to help me pick a restaurant nearby. While there are so many other categories to choose from, just picking from the highest rated food categories is enough to keep this mobile head happy. I often contribute to Yelp via Mobile taking a photo of the establishment if I like the restaurant.
Yelp Mobile Applications, don't leave home without it!
Windows Phone 7 Series
Apparently, the folks at Engadget are praising this release. It appears that the consensus is that MSFT had only one move to make and they are definitely making the right move.
Samsung S8500 Wave new samsung cell phone with bada OS
Samsung S8500 Wave has 8GB internal memory and supports up to 32GB memory cards. it runs with 1GHz ARM processor and has a 256MB RAM. this phone comes with Digital Natural Sound Engine technology which gives very quality sound.
in connectivity side Samsung S8500 Wave supports 7.2HSDPA and has bluetooth and wi-fi features. it has a 5MP main camera with a LED flash. it's a auto-focus camera which has Geo-tagging, face, smile and blink detection features. also it has a GPS receiver with A-GPS support and comes with many google applications.
HTC Legend new HTC touch phone
HTC Legend runs with Android OS. it has a Qualcomm MSM 7227 600 MHz processor and a 256MB RAM. the internal memory of this phone is 270MB and it supports up to 16GB memory cards. also HTC Legend supports 7.2MBP/s HSDPA connectivity and has both bluetooth and wi-fi features.
the main camera of this phone is a 5MP and it has a LED flash. HTC Legend has a GPS receiver and a FM radio with RDS.
Certified/Validated Mobile Phone Tools
Service API changes starting with Android 2.0
Service API changes starting with Android 2.0
Watching developers use the Android platform the last year has shown a number of trouble areas in the Service API as well as growing issues in the ways services operate. As a result, Android 2.0 introduced a number of changes and improvements in this area for both developers and users.
The three main changes to be aware of are:
- Service.setForeground() is now deprecated and in 2.0 does nothing.
- There were many edge cases in the service lifecycle that made it very easy to accidentally leave a service running; new APIs in 2.0 make this much easier to deal with.
- Android 2.0 also introduces a new UI for end users to monitor and manage the running services on their device.
Background on services
Before going into the details of 2.0, it may be useful to go over a quick summary of services. The Service API in Android is one of the key mechanisms for applications to do work in the background. Due to the way Android is designed, once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.
This is a very powerful facility but along with that power comes some responsibility: an actively running service is taking resources away from other things that can run (including inactive processes in the background that don't need to be initialized the next time the user visits them). It is thus important that developers take care when designing their services that they only run when truly needed and avoid any bugs where they may accidentally leave the service running for long durations.
Redesigning Service.setForeground()
During the final stabilization period of Android 1.6 we started to see more issues due to an increasing number of applications using the Service.setForeground() API when they shouldn't be. This is an API that we haven't advertised much because it should not be used by most applications and can be very hard on the system: it asks that the service's process be treated as in the foreground, essentially making it unkillable and thus more difficult for the system to recover from low memory situations.
At that point in 1.6 it was too late to make any significant changes to the behavior here, but in 2.0 we have done so: Service.setForeground() now does nothing. The API was always intended to be something a service would do in conjunction with putting up an ongoing notification for the user; by saying you are in the foreground, the user should be "aware" that the service is running in some way and know how to stop it. Thus in place of the old API Andriod 2.0 introduces two new APIs that require a notification go along with being in the foreground:
public final void startForeground(int id, Notification notification);
public final void stopForeground(boolean removeNotification);
This also not coincidentally makes it much easier to manage the notification state along with the service, since the system can now guarantee that there is always a notification while the service is in the foreground, and that the notification goes away whenever the service does.
Many developers will want to write a service that works on older platforms as well as 2.0 and later; this can be accomplished by using something like the following code to selectively call the new APIs when they are available.
private static final Class[] mStartForegroundSignature = new Class[] {
int.class, Notification.class};
private static final Class[] mStopForegroundSignature = new Class[] {
boolean.class};
private NotificationManager mNM;
private Method mStartForeground;
private Method mStopForeground;
private Object[] mStartForegroundArgs = new Object[2];
private Object[] mStopForegroundArgs = new Object[1];
@Override
public void onCreate() {
mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
try {
mStartForeground = getClass().getMethod("startForeground",
mStartForegroundSignature);
mStopForeground = getClass().getMethod("stopForeground",
mStopForegroundSignature);
} catch (NoSuchMethodException e) {
// Running on an older platform.
mStartForeground = mStopForeground = null;
}
}
/**
* This is a wrapper around the new startForeground method, using the older
* APIs if it is not available.
*/
void startForegroundCompat(int id, Notification notification) {
// If we have the new startForeground API, then use it.
if (mStartForeground != null) {
mStartForegroundArgs[0] = Integer.valueOf(id);
mStartForegroundArgs[1] = notification;
try {
mStartForeground.invoke(this, mStartForegroundArgs);
} catch (InvocationTargetException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke startForeground", e);
} catch (IllegalAccessException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke startForeground", e);
}
return;
}
// Fall back on the old API.
setForeground(true);
mNM.notify(id, notification);
}
/**
* This is a wrapper around the new stopForeground method, using the older
* APIs if it is not available.
*/
void stopForegroundCompat(int id) {
// If we have the new stopForeground API, then use it.
if (mStopForeground != null) {
mStopForegroundArgs[0] = Boolean.TRUE;
try {
mStopForeground.invoke(this, mStopForegroundArgs);
} catch (InvocationTargetException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke stopForeground", e);
} catch (IllegalAccessException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke stopForeground", e);
}
return;
}
// Fall back on the old API. Note to cancel BEFORE changing the
// foreground state, since we could be killed at that point.
mNM.cancel(id);
setForeground(false);
}
Service lifecycle changes
Another situation we were increasingly seeing in 1.6 was that, even ignoring the services that inappropriately make themselves foreground, we had a growing number of devices with a large number of services running in the background all fighting each other over the available memory.
Part of this problem is services that are running more than they should or there simply being too much stuff trying to be done on the device. However, we also found many issues in the interaction between services and the platform that made it easy for an application to leave a service running even when it is trying to do the right thing. Consider this typical scenario:
- An application calls startService().
- That service gets onCreate(), onStart(), and then spawns a background thread to do some work.
- The system is tight on memory, so has to kill the currently running service.
- Later when memory is free, the service is restarted, and gets onCreate() called but not onStart() because there has not been another call to startService() with a new Intent command to send it.
Now the service will sit there created, not realizing it used to be doing some work, and so not knowing it should stop itself at some point.
To address this, in Android 2.0 Service.onStart() as been deprecated (though still exists and operates as it used to in previous versions of the platform). It is replaced with a new Service.onStartCommand() callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:
- START_STICKY is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.
- START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.
- START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.
For compatibility with existing applications, the default return code for applications that are targeting an earlier version of the platform is a special START_STICKY_COMPATIBILITY code that provides the old behavior of not calling onStart() with a null intent. Once you start targeting API version 5 or later, the default mode is START_STICKY and you must be prepared to deal with onStart() or onStartCommand() being called with a null Intent.
You can also easily write a Service that uses both the old and new APIs, depending on the platform. All you need to do is compile against the 2.0 SDK with this code:
// This is the old onStart method that will be called on the pre-2.0
// platform. On 2.0 or later we override onStartCommand() so this
// method will not be called.
@Override
public void onStart(Intent intent, int startId) {
handleStart(intent, startId);
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
handleStart(intent, startId);
return START_NOT_STICKY;
}
void handleStart(Intent intent, int startId) {
// do work
}
New "running services" user interface
Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.
To help address this, Android 2.0 introduces a new "Running Services" activity available from the Application system settings. When brought up, it looks something like this:
The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:
- GTalkService is part of the standard Google application suit; it is running in Google's "gapps" process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.
- ActivityService is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.
- SoftKeyboard is a third party input method. It has been running since I switched to it, about 4 minutes ago.
The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it:
Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system's input settings).
Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:
- Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
- Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)
For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing "task killer" applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.
For developers, this is an important tool to ensure your services are well behaved. As you develop your app, be sure to keep an eye on Running Services to ensure that you are not accidentally leaving your services running when they shouldn't be. You should also now keep in mind that users may freely stop any of your services as they wish, without your control, and account for that.
Android's Services are a very powerful tool, but one of the main and subtle ways that application developers can harm the overall experience a user has with their phone.
LG GS500 Cookie Plus newest touchscreen phone
the internal memory of this phone is 128MB and it supports up to 16GB memory cards. also LG GS500 Cookie Plus supports 7.2MBP/s HSDPA connectivity. it has a 3.15MP camera and supports video recording.
MyTouch3G is now available with 3.5mm Non-Clapton Edition
Fender edition is temp out of stock? Crazy.
HTC Trophy new phone unofficial review and pictures
HTC Trophy powered by a 600MHz processor and it runs with Microsoft Windows Mobile 6.5 Professional OS. the internal memory of this phone is 256MB and it supports up to 16GB memory cards. in connectivity side HTC Trophy supports 3.6MBP/s HSDPA connectivity. also it has both wi-fi and bluetooth features.
HTC Trophy has a 5MP main camera which supports 30fps video recording as well. it has a GPS receiver with A-GPS supports and has lot more useful applications.
Sony Ericsson Robyn Android phone unofficial details
the internal memory of this phone is 128MB and it supports up to 16GB memory cards. also Sony Ericsson Robyn has a 5MP camera which supports Geo-tagging, face and smile detection features. in connectivity side, it has both bluetooth and wi-fi features.
Sony Ericsson Robyn has a GPS receiver with A-GPS support. it comes with lots of pre-installed applications like Google Search, Maps, Gmail,YouTube, Calendar and Google Talk.
Live wallpapers
With the introduction of live wallpapers in Android 2.1, users can now enjoy richer, animated, interactive backgrounds on their home screen. A live wallpaper is very similar to a normal Android application and has access to all the facilities of the platform: SGL (2D drawing), OpenGL (3D drawing), GPS, accelerometers, network access, etc. The live wallpapers included on Nexus One demonstrate the use of some of these APIs to create fun and interesting user experiences. For instance, the Grass wallpaper uses the phone's location to compute sunrise and sunset times in order to display the appropriate sky.
Creating your own live wallpaper is easy, especially if you have had previous experience with SurfaceView
or Canvas
. To learn how to create a live wallpaper, you should check out the CubeLiveWallpaper
sample provided with the Android 2.1 SDK; you will find it in the directory platforms/android-2.1/samples/CubeLiveWallpaper
.
A live wallpaper is very similar to a regular Android service. The only difference is the addition of a new method, onCreateEngine() whose goal is to create a WallpaperService.Engine. The engine is responsible for handling the lifecycle and the drawing of a wallpaper. The system provides you with a surface on which you can draw, just like you would with a SurfaceView
. Drawing a wallpaper can be very expensive so you should optimize your code as much as possible to avoid using too much CPU, not only for battery life but also to avoid slowing down the rest of the system. That is also why the most important part of the lifecycle of a wallpaper is when it becomes invisible. When invisible, for instance because the user launched an application that covers the home screen, a wallpaper must stop all activity.
The engine can also implement several methods to interact with the user or the home application. For instance, if you want your wallpaper to scroll along when the user swipes from one home screen to another, you can use onOffsetsChanged(). To react to touch events, simply implement onTouchEvent(MotionEvent). Finally, applications can send arbitrary commands to the live wallpaper. Currently, only the standard home application sends commands to the onCommand() method of the live wallpaper:
android.wallpaper.tap
: When the user taps an empty space on the workspace. This command is interpreted by the Nexus and Water live wallpapers to make the wallpaper react to user interaction. For instance, if you tap an empty space on the Water live wallpaper, new ripples appear under your finger.android.home.drop
: When the user drops an icon or a widget on the workspace. This command is also interpreted by the Nexus and Water live wallpapers.
Please note that live wallpaper is an Android 2.1 feature. To ensure that only users with devices that support this feature can download your live wallpaper, remember to add the following to your manifest before releasing to Android Market:
<uses-sdk android:minSdkVersion="7" />
, which lets Android Market and the platform know that your application is using the Android 2.1 version.<uses-feature android:name="android.software.live_wallpaper" />
, which lets the Android Market and the platform know that your application is a live wallpaper.
Many great live wallpapers are already available on Android Market and we can't wait to see more!
Finger powers mobile phone battery
2 Million iPhone Handsets Sold Says O2 UK
Sony Ericsson XPERIA X10 on Vodafone UK in April
Free Ovi Maps by Nokia Gets 1 Million Downloads in First Week
Symbian OS goes open source four months early
Nokia 6303i classic unveiled
Sony Ericsson announced a new eco friendly phone Aspen
Sony Ericsson Aspen is a 3G phone which supports 3.6MBP/s HSDPA connectivity. it has a 2.4 inch touchscreen and a QWERTY keypad as well. another special thing is this phone runs with Windows Mobile 6.5.3 Professional OS. the internal memory of this phone is 100MB and it supports up to 16GB memory cards. it has an Accelerometer sensor and new XPERIA Panels interface.
Sony Ericsson Aspen has 3.15MP camera. the GPS receiver supports A-GPS and it has pre installed Google maps.
Augmented Reality: Pretty Cool Stuff
MNO & VMNO SIM Cards
I'm speaking about ebooks in New York this month
My talk is about the many ways the ebook industry has failed in the past, but my real focus is on how to avoid those problems in the future. As you know if you've read this blog for a while, you know I am pretty passionate on this subject (link). With all the recent goings-on between Apple, Amazon, Macmillan, etc, we have a lot to discuss.
Here's a synopsis of my talk. If you have any other ebook questions you'd like to see me cover in it, post a comment here.
Check Out My Scars: Seven Lessons from the Failure of Ebooks in 2000, and What They Mean to the Future of Electronic Publishing
1:40pm Tuesday, 02/23/2010
O'Reilly Tools of Change for Publishing (link)
The tech industry has a long history of celebrating its successes and forgetting its failures. We honor the IBM PC but forget the DEC Rainbow and Kaypro II. We put the iPhone and BlackBerry on a pedestal but sweep the Qualcomm PDQ and Ericsson R380 under the rug.
That selective memory is often helpful in the development of a new technology, as it prevents companies from being held back by other companies’ failures. But it also makes tech companies prone to repeating the same mistakes over and over again. So it’s useful to look back at previous efforts to make ebooks successful, both as standalone reader products and as software for other mobile devices.
When you do that, there are seven lessons that emerge for today’s e-publishers:
1. Beware the chicken and the egg. Purchasing a dedicated e-book reader is a major decision for most users. Even though reader devices aren’t all that expensive, they cost a lot more than a couple of books, and so the user needs to have a fairly high motivation before they’ll buy. But the most enthusiastic readers – the people most likely to pay for an ebook reader – are also the people who care the about having a wide selection of ebooks available before they buy the device.
Meanwhile, publishers look at the uncertainties and expenses of preparing an ebook edition, and are reluctant to convert their entire catalogs unless they’re convinced that a huge installed base of reader devices will be available.
This creates a classic chicken-and-egg situation in which the publishers won’t jump on board until there are a lot of reader devices, and users won’t buy the devices until there are a lot of books available. This was the root cause of the failure of ebook devices in 2000.
Amazon and Sony, to their credit, have been trying to power through the chicken and egg situation through very aggressive marketing and price subsidies. They have made progress, but the reader market is not yet self-supporting, in part because of issue #2:
2. Ebook customers are cheap. It would be much easier for book publishers to embrace the ebook market if they could charge more for an electronic edition than they get for a hardcover book. That way they wouldn’t worry about cannibalizing their traditional channels. The reality is just the opposite—consumers generally view an electronic edition as less valuable than a hardcover. Even though an ebook is easier to carry, it’s viewed as evanescent, without the seriousness and tactile quality of a hardcover. As a result, many people are reluctant to pay more than paperback prices for ebooks.
But the book enthusiasts who are likely to be interested in ebook devices are the sort of people who want to read the latest releases, rather than waiting for a paperback edition. They want hardcover content at paperback prices. So Amazon and Sony have been forced to subsidize the sales of ebooks, paying hardcover prices to publishers but collecting lower revenue from their customers.
This doesn’t bode well for the economics of the reader device market. Instead, a lot of people are hoping that other reader devices will emerge, like smartphones. That brings us to the third lesson…
3. Mobile usage patterns are hostile to most publishing. Most print publishing is built around the idea of an extended reading session – the customer settles down with a book or a newspaper and reads through it cover to cover. Mobile devices have a completely different usage pattern. People use them on the go – they pull out the device when they have a minute free, use it briefly, and then put it away.
The usage pattern is more like eating bon-bons than sitting down to a meal.
That means there are strong, natural limits on the amount of text content that many people will consume on a smartphone or other small mobile device. If you’re publishing a joke book, a mobile device may be the perfect distribution medium for you. But unless you are publishing in a country where most people commute by mass transit for long distances (Japan, Korea), extended reading on mobiles is likely to remain a niche for a long time.
4. Periodicals are promising. Combine points 2 and 3 and they indicate an interesting possibility for e-publishing: Magazines. Other than National Geographic, most magazines are viewed as disposable after they’re read. And many of them are read in short sessions rather than all at once. So there is not as much customer resistance to paying the full list price for an e-magazine, and the format is more compatible with a mobile device. Plus, an e-magazine can be delivered faster than a print version, giving the e-edition an advantage.
The challenge for magazines is that the ad-heavy format of a traditional print magazine does not translate well to an electronic device. On an electronic device, people expect to jump straight to content rather than thumbing past ads they way they do in a print magazine. That’s why software products that replicate a print magazine on screen haven’t taken off. The usage pattern is just different.
So the challenge for magazine publishers is to remake their business models, balancing much lower printing and distribution costs against reduced (or different) ad revenue. No one has perfected that balance yet.
5. How do you get a better experience than paper? Here are the first two sentences of Sony’s online pitch for its Pocket Reader: “Carry hundreds of books in your pocket. The Reader Pocket Edition lets you access up to 350 of your favorite books from anywhere.” The problem with this reasoning is that almost no one wants or needs to carry 350 books at once; you can only read one at a time. So Sony’s touting an advantage that’s not actually advantageous.
If they want to win over users, ebook companies need to offer a product that’s actually superior to paper. Amazon’s instant download of books is a good start, but another promising opportunity is the backlist. Even popular authors routinely go out of print on their less well-known titles, and once an author dies their work can virtually vanish from the marketplace.
For example, in science fiction the late Robert Heinlein is considered a giant in the field, but about half of his titles listed on Amazon.com are out of print.
The enthusiastic readers who make up the core market for ebook devices would respond very well to a device that made large numbers of out of print books available, but the process of getting them available has been very slow. This is another area where Amazon is making some progress through the application of money.
6. Beware the tipping point. For book publishers, there is an economic cliff lurking somewhere on the horizon. Once ebook reader devices do take off, there is a point where it will make economic success for a successful author to completely bypass print publishing and self-publish electronically.
The economics work like this: An author typically gets about 15% of revenue as royalties. But a self-published e-author could retain a much larger cut—up to 70% if e-book stores come to resemble the iPhone app store. At that royalty rate, an author would make more money as soon as about 20% of the book-buying public has e-readers.
The actual location of the tipping point will vary for different types of books, and the situation is quite different for new authors who can’t generate demand for themselves. But in general, e-publishing changes the economic balance between authors and publishers, and it would be healthy for publishers to get ahead of that transition rather than waiting for it the way the music business has done.
(In the session I’ll flesh out this analysis more, with pointers to help publishers identify where the tipping point is and what it’ll mean.)
7. Be careful what you wish for. Beyond the financial tipping point, there’s another trend that will likely affect publishing: the rise of free. In both music and consumer software, prices have been inexorably trending toward zero. On the Apple App Store, for example, ASPs are steadily declining. Authors and publishers both should be thinking now about how they’ll maintain the perceived value of written content, and what other models they might use to monetize it.
(In the session we’ll discuss what some of those models might be, based on what’s happening in other types of content.)
================
A couple of unrelated links:
--We've posted the Rubicon "Competitive Idea Book," a collection of famous competitive strategies designed to help companies think about their businesses creatively (link).
--Thanks to WAP Review for including my post about the iPad in the latest Carnival of the Mobilists.
Nokia's Super touch Phone Nokia X6 with 16GB memory
Nokia X6 has a 3.2 inch capacitive touchscreen. it has a scratch resistant glass surface like apple iphone. also Nokia X6 has an Accelerometer sensor and a Proximity sensor. it has 16GB internal memory and supports up to 32GB memory cards. in connectivity side Nokia X6 has both bluetooth and wifi. it also has 3.6MBP/s HSDPA speed.
the main camera of this phone is 5MP and it has Dual LED light. also Nokia X6 supports 30fps video recording. this phone runs with Symbian OS v9.4 which is the latest touch version of this version.
it has a GPS receiver and Ovi Maps 3.0. also Nokia X6 has many new features like voice commands and a TV out.
Popular Posts
- 199 iphone wall paper
- Scanbuy Announces Addition to Its Board of Directors
- Millions of Names Available for .Co Open Registration
- YouTube Mobile 3G Enhancements & Java Beta Launchd.
- What a wonderful Second Life!
- Google Wave: First impressions
- Nokia N8 + Bluetooth Keyboard + Mouse
- Developers unhappy over Oracle Android suit
- Caribou Coffee to Use Cellfire for Mobile Coupon Offer
- Catching up: 8 random things about me