Samsung Tocco Lite edition
Samsung Tocco is a very famous mobile phone range of samsung. they launched number of phones in this range with a model number. but they has named this phone just as Samsung Tocco.
as it's name Tocco lite is going to be bit cheaper than others. it's a full face touchscreen phone which has 3 inch touchscreen. the touchscreen supports multi- touch input method. Tocco Lite is a 2G phone and it support three GSM bands. also it has an an accelerometer sensor.
they have named it's interface as TouchWiz UI because it supports many touch features. also Tocco Lite has new music technology named Samsung DNSe 2.0. the internal memory of this phone is 64Mb but it supports up to 8GB SD memory cards.
Samsung Tocco Lite comes with many social networking applications like facebook,myspace and youtube. it has 3.15Mp camera with a LED flash. the camera application has built in features like geo-tagging and face detecting.
Widget Design Guidelines
Since the beginning of the year, the Android UI team has been hard at work on the Android 1.5 release. Starting today with widgets, we would like to share some of our evolving Android design principles with you.
Widgets are a new feature that application developers can use to promote a small sample of the most relevant dynamic data from their applications on the Home screen. We've designed widgets to fit within our Home screen grid framework, which means you and your designer can create a widget within a 4x1, 3x3, or 2x2 grid cell, depending on the space you need for an at-a-glance summary of information from your application. To illustrate the preferred ways to design widgets for the home screen, we've assembled Widget Design Guidelines.
We're also providing the original artwork assets and source files that we used to create the widgets bundled with Android 1.5. If you want your widgets to match the platform in terms of appearance, use the templates that are available throughout the Widget Design Guidelines.
For more technical information around widgets, take a look at Jeff Sharkey's blog post as well as the AppWidgets documentation.
We've only just begun to scratch the surface of what's possible using widgets. We're looking forward to seeing how far you can extend our work!
One last thing: in the coming weeks, we'll be rolling out more articles and presentations that demonstrate design best practices for Android. For example, if you've ever wanted to learn how to create and be consistent with iconography on Android, stay tuned: we'll be posting sample guides and templates.
Learn about Android 1.5 and more at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and to field your toughest questions.
Free Symbian Subway Maps of NYC, London, Paris, Toyko and More...
The folks at PixelBeatPaper out of the UK is bringing major cities' subway maps to Symbian S60 5th edition handsets (i.e. Nokia 5800, Samsung Omnia HD and upcoming Nokia N97). These .Sis widgets are available for: NYC, Tokyo, London, Paris, Portugal, and Santiago. This is huge considering these are full functional interactive maps for free. Having these available independent of data is a major plus. This means you can take advantage your Symbian handset w/o accruing data charges. I only wish this is available for older Symbian S60 3rd edition handsets (ie. N95, N82, etc...)
[source: allaboutsymbian.com]
Motorola ZN300 cheap but attractive music phone
in 2009 March Motorola announced Motorola ZN300 phone which has very simple but useful features. therefor this phone may be cheap. it is a 2G phone which supports three GSM bands.
it has high quality sound output and 3.5mm audio jack. Motorola ZN300's media player supports many file formats even like MPEG4 and WMV. it has 8Mb internal memory but supports up to 32GB micro SD memory cards.
the main camera is 3.15Mp which can give well quality pictures and videos. the maximum picture resolution is 2048x1536 pixels and the camera comes with a Flash. it has built in video and picture editing applications. also the video editor has video mixture feature.
when considering other features, Motorola ZN300 has built in Opera Mini web browser. also it has number of pre-installed applications like Facebook, Myspace, YouTube and Photobucket.
My First Mobile Purchase over a Smartphone
Prior to this, I’ve always felt there was something missing with the mobile commerce. Either the speed is too slow or the interface is not big enough for me, a very research-oriented shopper, to do my homework before placing a purchase. Back then, my mobile experience was limited to basic utilities (checking news, weather, stocks, directions, maps, score, etc…). With my recent acquisition of a 3G iPhone and the progress made by the app community, things are starting to cook for the mobile commerce.
Here are the reasons why I finally made my purchase:
3G Internet – Wireless data plan is a must for mCommerce to take off. Having 3G network more readily available across the coverage map will convince more people to do more transaction over their mobile device. As for me, I recently upgraded to an iPhone 3G. The data speed is consistent enough for me to be more involved with the apps downloaded from the iPhone store. It has turned my commute into a more productive session, reading up on emails, news, and social media sites without having to wait until I get to the office. (If only it can make me a cup of coffee too!). All said, the 3G data empowers me to shift more of my tasks towards an otherwise in efficient use of time.
iPhone – the iPhone is just a marvelous device in doing the following task: receive information, extract the relevant parts and present it in a simple and powerful display. The concept is simple but no one (thus far) does it better than Apple. With the App store, Apple has given developers the power to expand on that concept and thus challenging the mobile community to take after that philosophy. The end result: consumers are the winners benefiting from some of the most powerful apps ever made, period!
Amazon App – The Amazon iPhone application is a perfect segue from the last paragraph. These guys get eCommerce and they also understand how to build a solid mobile application. Utilizing iPhone’s UI, Amazon dev team created, in my opinion, one of the best mobile application. All the things we love about Amazon is here: product reviews, images, pricing, add to cart, save for later, move to cart, one-click checkout. It is so intuitive that I don’t feel like I have to have a desktop to do anything. My purchase was not an easy one. From prior desktop sessions, I had already added the Henckels Knife Block to my “Save for Later” cart. Amazon’s iPhone app was able to let me see that list and move it into the cart easily (much like the edit function in mail). I was also able to switch the payment type in the one-click checkout setting as well as choose the right shipping address from my contact book. Finally, I was even able to add in an e-certificate code to my order before checking out. All of this is taking place while I am on my morning bus ride into NYC. If you look at the time sequence on my screen shots, within minutes, I was able to receive an email confirmation on the my iPhone for my purchase. The only question I have for Amazon is: Where is your app for the Android?
This is by far, the best mobile experience I have had. It was a flawless and smooth transaction and I can see myself shifting more transactions on my iPhone. Excellent job to Apple, Amazon and 3G mobile internet(AT&T).
Zillow iPhone App Available for Download
All joking aside, Zillow iPhone app is one of those mobile services that can really enhance a user's mobile experience. Anytime a mobile app can empower users and bring more value out of their data plan (whether it'd be a buyer or realtor), it brings great satisfaction to this blog. Kudos to Zillow for another great app addition to the iPhone store. To learn more info about Zillow for iPhone, visit here.
Motorola W7 Headed to China
HTC XV6175 for Verizon
Motorola Napoleon Gets the FCC Approval
Xperia X2 Mentioned By Skyhook
LG GT500 from Rogers
Google Base/Product Search Goes Mobile
Refurbished iPhone 3G, Is it worth it?
Should one take advantage of this deal?
I'll answering that by saying the price, unlike the1st gen. iPhone refurb deal last year, this time, the purchase will force you to open a 2-year contract. This means you'll have to live with this refurbished iPhone 3G hopefully trouble-free for the next two years. According to the fine print, all refurb iPhone 3Gs are warranted for 90 days or more. The "more" is based on the number of days left in since activation of the original one year warranty.
That said, I will go over couple of experience I've had with the 1st gen. refurbished iPhone deal I picked up last year. As mentioned above, the 1st gen. iPhone refurb can be had for $250 shipped. My refurbed 1st gen iPhone, however, had a failed touchscreen after 6 months of use. While AT&T originally promised a 1 year warranty as it was mentioned on the refurbished box label, APPLE store did want to honor it. They kept using the original registration info off of the previous owner as the time stamp for the one year warranty period. After much perusation, they finally agreed to exchange for another refurbished iPhone for an extended 90 days warranty. The replacement iPhone never worked properly with the presistant "iPhone won't ring in deep sleep" problem as I have documented. Long story short, I finally gave up on this route and extended my contract with AT&T for a new iPhone 3G.
So if you ask me, refurbished iPhone 3G is not worth the potential issues. As matter of fact, I've never bought into refurbished anything in the past. My only time of bending that rule backfired on me. So, no thanks, I'll pass.
Backward compatibility for Android applications
Android 1.5 introduced a number of new features that application developers can take advantage of, like virtual input devices and speech recognition. As a developer, you need to be aware of backward compatibility issues on older devices—do you want to allow your application to run on all devices, or just those running newer software? In some cases it will be useful to employ the newer APIs on devices that support them, while continuing to support older devices.
If the use of a new API is integral to the program—perhaps you need to record video—you should add a manifest entry to ensure your app won't be installed on older devices. For example, if you require APIs added in 1.5, you would specify 3 as the minimum SDK version:
<manifest>
...
<uses-sdk android:minSdkVersion="3" />
...
</manifest>
If you want to add a useful but non-essential feature, such as popping up an on-screen keyboard even when a hardware keyboard is available, you can write your program in a way that allows it to use the newer features without failing on older devices.
Using reflection
Suppose there's a simple new call you want to use, like android.os.Debug.dumpHprofData(String filename)
. The android.os.Debug
class has existed since the first SDK, but the method is new in 1.5. If you try to call it directly, your app will fail to run on older devices.
The simplest way to call the method is through reflection. This requires doing a one-time lookup and caching the result in a Method
object. Using the method is a matter of calling Method.invoke
and un-boxing the result. Consider the following:
public class Reflect {
private static Method mDebug_dumpHprofData;
static {
initCompatibility();
};
private static void initCompatibility() {
try {
mDebug_dumpHprofData = Debug.class.getMethod(
"dumpHprofData", new Class[] { String.class } );
/* success, this is a newer device */
} catch (NoSuchMethodException nsme) {
/* failure, must be older device */
}
}
private static void dumpHprofData(String fileName) throws IOException {
try {
mDebug_dumpHprofData.invoke(null, fileName);
} catch (InvocationTargetException ite) {
/* unpack original exception when possible */
Throwable cause = ite.getCause();
if (cause instanceof IOException) {
throw (IOException) cause;
} else if (cause instanceof RuntimeException) {
throw (RuntimeException) cause;
} else if (cause instanceof Error) {
throw (Error) cause;
} else {
/* unexpected checked exception; wrap and re-throw */
throw new RuntimeException(ite);
}
} catch (IllegalAccessException ie) {
System.err.println("unexpected " + ie);
}
}
public void fiddle() {
if (mDebug_dumpHprofData != null) {
/* feature is supported */
try {
dumpHprofData("/sdcard/dump.hprof");
} catch (IOException ie) {
System.err.println("dump failed!");
}
} else {
/* feature not supported, do something else */
System.out.println("dump not supported");
}
}
}
This uses a static initializer to call initCompatibility
, which does the method lookup. If that succeeds, it uses a private method with the same semantics as the original (arguments, return value, checked exceptions) to do the call. The return value (if it had one) and exception are unpacked and returned in a way that mimics the original. The fiddle
method demonstrates how the application logic would choose to call the new API or do something different based on the presence of the new method.
For each additional method you want to call, you would add an additional private Method
field, field initializer, and call wrapper to the class.
This approach becomes a bit more complex when the method is declared in a previously undefined class. It's also much slower to call Method.invoke()
than it is to call the method directly. These issues can be mitigated by using a wrapper class.
Using a wrapper class
The idea is to create a class that wraps all of the new APIs exposed by a new or existing class. Each method in the wrapper class just calls through to the corresponding real method and returns the same result.
If the target class and method exist, you get the same behavior you would get by calling the class directly, with a small amount of overhead from the additional method call. If the target class or method doesn't exist, the initialization of the wrapper class fails, and your application knows that it should avoid using the newer calls.
Suppose this new class were added:
public class NewClass {
private static int mDiv = 1;
private int mMult;
public static void setGlobalDiv(int div) {
mDiv = div;
}
public NewClass(int mult) {
mMult = mult;
}
public int doStuff(int val) {
return (val * mMult) / mDiv;
}
}
We would create a wrapper class for it:
class WrapNewClass {
private NewClass mInstance;
/* class initialization fails when this throws an exception */
static {
try {
Class.forName("NewClass");
} catch (Exception ex) {
throw new RuntimeException(ex);
}
}
/* calling here forces class initialization */
public static void checkAvailable() {}
public static void setGlobalDiv(int div) {
NewClass.setGlobalDiv(div);
}
public WrapNewClass(int mult) {
mInstance = new NewClass(mult);
}
public int doStuff(int val) {
return mInstance.doStuff(val);
}
}
This has one method for each constructor and method in the original, plus a static initializer that tests for the presence of the new class. If the new class isn't available, initialization of WrapNewClass
fails, ensuring that the wrapper class can't be used inadvertently. The checkAvailable
method is used as a simple way to force class initialization. We use it like this:
public class MyApp {
private static boolean mNewClassAvailable;
/* establish whether the "new" class is available to us */
static {
try {
WrapNewClass.checkAvailable();
mNewClassAvailable = true;
} catch (Throwable t) {
mNewClassAvailable = false;
}
}
public void diddle() {
if (mNewClassAvailable) {
WrapNewClass.setGlobalDiv(4);
WrapNewClass wnc = new WrapNewClass(40);
System.out.println("newer API is available - " + wnc.doStuff(10));
} else {
System.out.println("newer API not available");
}
}
}
If the call to checkAvailable
succeeds, we know the new class is part of the system. If it fails, we know the class isn't there, and adjust our expectations accordingly. It should be noted that the call to checkAvailable
will fail before it even starts if the bytecode verifier decides that it doesn't want to accept a class that has references to a nonexistent class. The way this code is structured, the end result is the same whether the exception comes from the verifier or from the call to Class.forName
.
When wrapping an existing class that now has new methods, you only need to put the new methods in the wrapper class. Invoke the old methods directly. The static initializer in WrapNewClass
would be augmented to do a one-time check with reflection.
Testing is key
You must test your application on every version of the Android framework that is expected to support it. By definition, the behavior of your application will be different on each. Remember the mantra: if you haven't tried it, it doesn't work.
You can test for backward compatibility by running your application in an emulator from an older SDK, but as of the 1.5 release there's a better way. The SDK allows you to specify "Android Virtual Devices" with different API levels. Once you create the AVDs, you can test your application with old and new versions of the system, perhaps running them side-by-side to see the differences. More information about emulator AVDs can be found in the SDK documentation and from emulator -help-virtual-device
.
Learn about Android 1.5 and more at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and to field your toughest questions.
Microsoft: What could have been
Aired May 1, 2009 - 9:00 p.m. EDT
THIS IS A RUSH TRANSCRIPT. THIS COPY MAY NOT BE IN ITS FINAL FORM AND MAY BE UPDATED.
KING: Tonight, people are calling it the most important business transformation in a generation. Bill Gates, the founder, chairman, and CEO of Microsoft joins us live. Bill, Microsoft just announced its quarterly earnings, and for the first time your revenue from personal computers actually dropped.
GATES: The economy is very tough, and that's affecting computer sales, just like everything else.
KING: But Microsoft's revenue and profits continued to increase, right? The stock market sure loved what you said last week.
GATES: I think our strategy's really starting to take hold. We don't manage Microsoft for quarterly earnings, but it's nice to see that investors are recognizing the progress we've made.
KING: You mentioned a new strategy. That started what, about eight years ago?
GATES: Roughly. We spent a lot of time looking at our business, asking where we were going, and we realized three important things.
KING: What were they? Lay them out for me.
GATES: Well, the first was that the biggest danger to Windows was Microsoft itself, and they way we were managing the product. Our philosophy for the last decade had been that whenever there was an innovation in personal computers, we copied it into Windows or into Microsoft Office. If there was an important new application, we built it into Office. If Apple or somebody came up with a new personal computer feature, we built that feature into Windows.
KING: You were trying to compete.
GATES: Yeah, but the effect was that Windows and Office were growing exponentially. If you extrapolated out the growth curve -- the number of lines of code and the number of features -- you could see that within about a decade we'd hit an asymptote...
KING: An assy-what?
GATES: A point of diminishing returns, where Windows would become so complex that we'd have to spend all our time just fixing bugs instead of improving the product. We were destroying our own ability to innovate.
KING: But that wasn't the biggest problem, was it? Your behavior also made Microsoft unpopular.
GATES: Not just unpopular, our aggressive business practices made people stop investing in writing new PC software. The entrepreneurs and the VCs were starting to say, "why should I bother writing a new Windows software program? Even if I'm successful, Microsoft will just take over my business."
KING: How's that a problem? It just means fewer competitors for you, right?
GATES: Not really, because people weren't going to stop writing new software overall. They just stopped writing it on Windows. By competing so hard with our own developers, we were forcing them to innovate on the Internet instead. So here we were, Windows was growing so big that we couldn't innovate, and at the same time we were driving all the other innovators to work on the Internet instead of building on our platform. We were in danger of strangling our own business.
KING: You said there were three things you realized. What was the third one?
GATES: That was probably the most painful one for us to face. We had to admit to ourselves that we just weren't very good at managing things outside the PC business.
KING: But today Microsoft is viewed as one of the best managed companies in the world.
GATES: Today, sure. But ten years ago, we were like the repair guy who has only a hammer. Everything looks like a nail. We thought we were a software company, but actually we were a PC company. To us, everything looked like a PC. We thought we could take what we already knew and apply it to any other technology business. Microsoft had this reputation that the third time's the charm...
KING: Your first two versions stink, but on the third try you'll get it right.
GATES: I wouldn't say stinks, but...you know, ten years ago I would have jumped all over a statement like that. But yeah, people said things like that, and I think at some level we started to believe it about ourselves. So we would enter these new businesses, and our first efforts would be a failure, and we'd tell ourselves that it was okay because of the learning curve. But that wasn't it; the reality was that we just weren't very good at those other businesses. You look at all the new things we were investing in...
KING: Let's make a list, there were video games, smartphones...
GATES: Lots more than that. Tablet computers. Music players. At one point we were even creating an operating system for watches, if you can believe that. And we were developing all of these things in-house, and most of them were very mediocre, very uninspiring.
KING: So let me get this straight, you had three problems at once...
GATES: Our products were getting so big that we couldn't innovate, we had driven away the other people who could innovate, and we weren't good at the new businesses we were getting ourselves into. Now, none of this was totally obvious in 2001. You could still rationalize at the start of the decade that all we needed to do was work a little harder. In fact, in a lot of ways it looked like we were stronger than ever. So the pressure to stay the course was pretty extreme.
KING: But that wasn't what you did.
GATES: No. It was the biggest decision of my career, but right when we were at the peak, we decided we had to remake the company. If we were going to diversify beyond the PC market, we needed to figure out how to manage very different businesses within Microsoft. We had to be more like GE, where they can run radically diverse businesses like jet engines and finance inside one corporate entity. And instead of growing everything ourselves, we'd need to acquire some companies with different DNA.
KING: But acquisitions were a problem for you.
GATES: Right. Because the government had decided we were a monopoly, we couldn't just go out and buy a bunch of companies. We would've drowned in lawsuits. So first we had to change the way we managed Windows. That's why we signed the consent decree with the government, agreeing to open up all the interfaces of Windows at no charge, and to stop copying the features of other software companies. That got the Department of Justice off our backs -- I mean, that made the regulatory authorities more comfortable with our strategy. You know, Larry, I still don't think we actually did anything wrong, but sometimes the perception is just as damaging as the act...
KING: Of course.
GATES: Then we made it clear to the VCs that instead of competing with the best Windows software companies, we were going to buy them. That turned around the whole investment dynamic -- instead of creating new software companies on the web, they started telling all the entrepreneurs to create Windows software, because they had an easy exit strategy. Plus we were able to make our Windows development more focused, because we weren't obligated to compete with everything all at once. It's like what Cisco did in networking. Get other people to do your R&D for you, and just buy the best ones. So that re-ignited innovation in Windows.
KING: It sounds so simple.
GATES: Actually, it is pretty simple, if you let the companies you acquire keep running themselves. We used to acquire a company and then "align" it with our strategy. In practice, that meant it disappeared like a tuna in a school of sharks. That was probably the hardest lesson we had to learn at Microsoft, that our way wasn't always the best way.
KING: Let's open it up to the phones. Peoria, Illinois, you're on with Bill Gates.
CALLER: Hello?
KING: Yes, you're on live with Bill Gates. What's your question?
CALLER: I wanted to ask about the acquisitions you've made in the last decade. Which one are you most proud of?
GATES: Oh, it's hard to choose just one. But the deal that set up Microsoft North is one of my favorites. People said we were crazy to buy those guys. We had to pay almost $3 billion for them in 2002. It was a huge risk at the time; Ballmer almost threw a chair at me when we discussed it. But today they're responsible for the whole Microsoft Blackberry product line.
KING: You mean that wasn't developed in-house?
GATES: People forget about that today, but yeah we bought this Canadian company that made Blackberry, and put them in charge of our mobile strategy. The analysts thought we were crazy -- they said we could just copy Blackberry and build it into our server and PDA products. But I thought about Microsoft Bob, and decided it was better to spend the money than risk missing the market. You know, that one $3 billion investment is probably worth at least $30 billion today.
Then there was the joint venture with Nintendo. God only knows how much money we would have lost if we'd tried to go into video games on our own.
KING: We're almost out of time. Nine years ago, on January 1, 2000, we had you on this program and you said that the biggest danger to Microsoft was that you would become complacent. How did you avoid that?
GATES: By assuming that we were complacent, and attacking it. Here's the rule: If you even suspect that you're at risk of becoming complacent, you probably already are. I mean, we could have just gone along with business as usual. That would have been the safe decision.
KING: If you had taken the safe approach, where do you think Microsoft would be today?
GATES: It's so hard to say. If we hadn't changed, we probably could have muddled through with high profits for about a decade before things would have started to come apart. I might have even gotten bored and retired, or given away all my stock to a foundation. But by the end of the decade, there we'd be, most of our business would still be centered on the PC, and when that market started to shrink, then we'd be in real trouble.
KING: Could you have fixed the company if you'd waited that long?
GATES: I don't really know. I want to say yes, because you know I'm kind of competitive. But when a company starts shrinking, there's huge pressure from the shareholders to cut costs. And logically, the first thing you cut is the speculative new products that might get you out of the mess. If I had given up my stock, I might not even have enough control over the company to step in and say, "ignore the investors for a couple of years while we fix everything." It was hard enough to do back in 2001.
Once you start to shrink, it's very difficult to turn things around.
KING: Instead, here you are. Sure enough the PC market is shrinking, but Microsoft's still growing...
GATES: Because we changed our strategy to use the talents of others, rather than feeding off them.
KING: Thanks, Bill.
GATES: You bet.
KING: Bill Gates, the founder, chairman and CEO of Microsoft.
Tomorrow night: Monica Lewinsky, where is she now?
Thanks for joining us. I'm Larry King. Good night.
The lesson from OQO
Baloney. OQO's time never arrived in the first place.
I'm always sad to see any startup run into trouble; especially a device company, because they're so rare. OQO did some beautiful things technologically. But in my opinion, they never had a chance as a business. There just wasn't a significant market for a shrunken, compromised PC at the same price as a full-size laptop. At first OQO was supposed to be a horizontal market device, and when that didn't take off the company went after business verticals (the place where struggling consumer technologies go to die). Sometimes that works, but usually it ends up being a gradual way to wind down the company.
But why, if OQO is failing, are netbooks taking off? Two words: They're cheap. It's one thing to ask someone to pay $900 for a less functional notebook. It's quite another to ask them to pay $300.
The lesson: Don't build something just because you can. Make sure there's a real market for your device before you create it. Geeky coolness will impress Wired reporters, but it won't get you a lot of sales from real people.
Review: Griffin WindowSeat iPhone, iPod Car Mount
The fit for my iPhone is very snug. The corners of the back plate is what holds your iPhone or iPod touch intact. To change out the adapters between iPhone and iPod Touch is easy but I find it a little cumbersome (since you can also unscrew the ball joint as it rotates lose in opposite direction). The enclosed 3.5mm audio cord makes it easy for you to rig your device to your car's aux in. There are plenty of clearances around my iPhone for access to power, audio and data ports, as well as the volume control. I personally prefer to use the enclosed suction cup plate so I can mount all my accessories to the dashboard than windshield. The suction cup is made of a rotational control which applies the pressure for a strong hold. For the money, Griffin's WindowSeat is a very good iPhone/iPod Touch automotive mount. Items like this, however, makes having a case on your device hard to use. I hope Griffin come up with a solution for folks preferring keeping their devices in protective hardcase.
Android 1.5 at Google I/O
I admit, I've been talking big about Google I/O in my last few posts. But I'm entirely serious: Google I/O is going to be the Android developer event of the year, no doubt about it. I want to take a few minutes to explain why.
The most exciting aspect, to my mind, is the technical content. We have 9 sessions listed now on the Google I/O sessions site, and we're working on still more. (And that's not even including the fireside chat with the Android Core Technical Team.) I recently sat down with some of the speakers to discuss their topics, and found that this is very solid material. Here are some of the sessions I'm excited about.
My background is strictly in engineering, and I never had the chance in college to take any design courses. So one session I'll definitely be at is Chris Nesladek's "Pixel Perfect Code". He's going to start with the basics, and give us an overview of the theory of UI design, and then explain the principles that we use when designing the core Android UI. If you like the UI updates that you've seen in the Android 1.5 "Cupcake" user interface, then be at this session.
My particular team works intensively with developers to help them build and launch applications. Justin Mattson is going to share some of the hard-earned debugging and performance techniques that we've picked up in our work with partners. He's going to walk you through some actual, real-world apps on the Android Market and show you how we squeezed the bugs out of them.
Now, they told me to focus on only one or two sessions in this post, but forget that. I can't resist! I have to tell you about a couple more, like David Sparks' session on the media framework. One of the most common questions we get asked goes something like "dude, what is up with all these codecs? AAC? MP3? OGG? MPEG? H264?" David's going to answer that question—among many others -- and explain how the media framework is designed and operates. Armed with this new understanding, you'll be able to make smarter choices as you design the media components of your own apps.
And last (for today), I want to mention Jeff Sharkey's "Coding for Life—Battery Life" session. A statement like "it's important to code efficiently on mobile devices" is deceptively simple. It turns out that what constitutes efficient code on, say, the desktop is sometimes woefully hard on battery life, on mobiles. What I've learned to tell developers is "everything you know is wrong." That's why I'm looking forward to Jeff's session. He's going to go through a whole basket of tips and tricks, backed up by some nice crunchy numbers.
And of course, these are just the technical sessions (and not even half of those.) We're also going to have quite a few folks representing some of our app developer and Open Handset Alliance partners at Google I/O, but I'll save those details for another post. I'm also looking forward to turning the tables, and giving some of you the floor. Besides the fireside chat where you can ask the Core Technical Team all the thorny technical questions you've been saving up, there's also a Lightning Talks session just for Android developers, and an Android Corner mixer area in the After-Hours Playground.
I'm also excited about a few surprises we've lined up... but I can't say anything about those, or they wouldn't be surprises, would they?
So, there you have it. Excitement! Drama! Surprises! It's like a movie trailer, but without the awesome voiceover. I hope it worked, and that you all are looking forward to Google I/O as much as I am. (By the way, I'm instructed to inform you that you can save a bit of coin by registering early. You might want to hurry though, since early registration ends May 1.)
Happy Coding!
Android 1.5 is here!
I've got some good news today: the Android 1.5 SDK, release 1 is ready! Grab it from the download page.
For an overview of the new Android 1.5 features, see the 1.5 release notes page in our developer site.
I am also happy to let you know that our partners at HTC have made available new system images to upgrade your Android Dev Phone 1 (ADP1) to Android 1.5. This new version (which is only available for the ADP1) is based on the Cupcake branch from the Android Open Source Project and corresponds to the system image of the Android 1.5 SDK, release 1. If you have questions about the process of updating your device, you can ask the mailing list that we've set up.
I'd also like to note that Android developer phones like the ADP1 are intended for application development, rather than daily use. Additionally, they are operator-neutral and country-neutral, so they may not include certain features found on end-user devices.
Samsung I7500 Smartphone, Android Done Right!
1. Physical Appearance: Much more refined looking and get rid of the annoying looking chin. This image rendering looks more professional duty by design and looks to have all the buttons much more accessible and laid out.
2. Feature rich + improvement: WOW! AMOLED display at 320x480. 5 Megapixel camera w/ LED flash. Tri band 3G (900/1700/1900) 1,500mAh battery (much needed improvement over G1's meager 1150mAh) and finally, in the words of Barney Stinson... "wait for it...wait..." 3.5mm audio jack!!!
This thing is pretty exciting. It just might convince me to make the switch again! Looks like Samsung is back and on top of the mobile biz.
Samsung Omnia Pro with QWERTY Keyboard?
HTC Magic in Italy from TIM
Verizon Hub Now for $149
BlackBerry Niagara is actually Tour?
T-Mobile Germany Android 1.5 Update to be available In May
New Live Pics of Palm Pre
Orange Vegas Cell Phone
Motorola V10 launched for Korea
Checking in on smartphone and Twitter usage
Smartphone adoption: RIM leads. In the US, about 10%-11% of the adult population uses smartphones. RIM has just under half of the installed base, followed by Apple at about a quarter.
The users of different types of smartphone have different feature priorities. iPhone users rate web browsing as their #1 feature, followed closely by e-mail. RIM users rank e-mail the most important feature, Palm users choose calendar, and Google phone users are partial to mapping. The profile for Windows Mobile users is similar to RIM's, but less enthusiastic about e-mail.
Mobile phone feature priorities of iPhone users compared to all mobile phone users. Percent of US users ranking a feature in their top four.
I think this is more evidence of something that I've been saying for a while -- most people buy phones more like they do appliances than like computers. They decide which functions are most important to them, and then pick the phone that does those things best, rather than looking for the best general-purpose device.
That's not to say that flexibility doesn't matter at all, but it's secondary. For example, adding third party apps is the #4 priority among iPhone users, and close to tied with several other features. It will be interesting to see how the priority evolves as Apple continues to advertise the daylights out of the app store.
For the full article, click here.
Twitter is a form of entertainment. Usage of Twitter is rising very rapidly -- as of April, it gets more daily visitors than cnn.com in the US, according to Alexa.com.
Our survey showed that the Twitter user base has more than doubled in the last six months. About 10% of US computer users have tried Twitter so far, and about a third of those people have stopped using it. You can decide for yourself if that's a big number or not, but a certain amount of churn is inevitable in any new web service.
Twitter awareness and usage among US PC users.
Most Twitter users say they are casual users of the service, and that it doesn't play an important part of their personal or business lives. The most active 10% of Twitter users say it does play an important role in their personal lives, but not in their business lives.
The overall pattern of usage indicates that for most people Twitter is currently a form of casual entertainment. There's nothing wrong with that, but the future of Twitter will depend on how that usage pattern evolves. Will Twitter become as important as e-mail, or will it be a fad like citizens' band radio (link)? It's too early to tell. But it's already clear that it's a separate medium with its own rules. Companies looking to use Twitter should make sure they understand how it's used; it's not the same as blogging.
For the full article, click here.
Macro Lens for Camera Phones (iPhone, HTC, G1)
Playstation 3 for $299 at Dell (PS3)
This is easily the best deal you can find on a PS3 w/o opening up a credit card or jumping through hoops. Dell.com is offering my favorite next generation console for a measely $300 shipped free. This is a cool $100 off from the regular price you'd find at Best Buy or GameStop. Buy this and be part of the help towards economic recovery!
MacBook Air Envelope Neoprene Envelope Sleeve
Super Mario Power Up Energy Drink
Brazilian Satellite Hack Crackdown
Introducing GLSurfaceView
GLSurfaceView is a new API class in Android 1.5. GLSurfaceView makes OpenGL ES applications easier to write by:
- Providing the glue code to connect OpenGL ES to the View system.
- Providing the glue code to make OpenGL ES work with the Activity life-cycle.
- Making it easy to choose an appropriate frame buffer pixel format.
- Creating and managing a separate rendering thread to enable smooth animation.
- Providing easy-to-use debugging tools for tracing OpenGL ES API calls and checking for errors.
GLSurfaceView is a good base for building an application that uses OpenGL ES for part or all of its rendering. A 2D or 3D action game would be a good candidate, as would a 2D or 3D data visualization application such as Google Maps StreetView.
The Simplest GLSurfaceView Application
Here's the source code to the simplest possible OpenGL ES application:
package com.example.android.apis.graphics;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
public class ClearActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(this);
mGLView.setRenderer(new ClearRenderer());
setContentView(mGLView);
}
@Override
protected void onPause() {
super.onPause();
mGLView.onPause();
}
@Override
protected void onResume() {
super.onResume();
mGLView.onResume();
}
private GLSurfaceView mGLView;
}
class ClearRenderer implements GLSurfaceView.Renderer {
public void onSurfaceCreated(GL10 gl, EGLConfig config) {
// Do nothing special.
}
public void onSurfaceChanged(GL10 gl, int w, int h) {
gl.glViewport(0, 0, w, h);
}
public void onDrawFrame(GL10 gl) {
gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);
}
}
This program doesn't do much: it clears the screen to black on every frame. But it is a complete OpenGL application, that correctly implements the Android activity life-cycle. It pauses rendering when the activity is paused, and resumes it when the activity is resumed. You could use this application as the basis for non-interactive demonstration programs. Just add more OpenGL calls to the ClearRenderer.onDrawFrame method. Notice that you don't even need to subclass the GLSurfaceView view.
Note that the GLSurfaceView.Renderer interface has three methods:
The onSurfaceCreated() method is called at the start of rendering, and whenever the OpenGL ES drawing context has to be recreated. (The drawing context is typically lost and recreated when the activity is paused and resumed.) OnSurfaceCreated() is a good place to create long-lived OpenGL resources like textures.
The onSurfaceChanged() method is called when the surface changes size. It's a good place to set your OpenGL viewport. You may also want to set your camera here, if it's a fixed camera that doesn't move around the scene.
The onDrawFrame() method is called every frame, and is responsible for drawing the scene. You would typically start by calling glClear to clear the framebuffer, followed by other OpenGL ES calls to draw the current scene.
How about User Input?
If you want an interactive application (like a game), you will typically subclass GLSurfaceView, because that's an easy way of obtaining input events. Here's a slightly longer example showing how to do that:
package com.google.android.ClearTest;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.view.MotionEvent;
public class ClearActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mGLView = new ClearGLSurfaceView(this);
setContentView(mGLView);
}
@Override
protected void onPause() {
super.onPause();
mGLView.onPause();
}
@Override
protected void onResume() {
super.onResume();
mGLView.onResume();
}
private GLSurfaceView mGLView;
}
class ClearGLSurfaceView extends GLSurfaceView {
public ClearGLSurfaceView(Context context) {
super(context);
mRenderer = new ClearRenderer();
setRenderer(mRenderer);
}
public boolean onTouchEvent(final MotionEvent event) {
queueEvent(new Runnable(){
public void run() {
mRenderer.setColor(event.getX() / getWidth(),
event.getY() / getHeight(), 1.0f);
}});
return true;
}
ClearRenderer mRenderer;
}
class ClearRenderer implements GLSurfaceView.Renderer {
public void onSurfaceCreated(GL10 gl, EGLConfig config) {
// Do nothing special.
}
public void onSurfaceChanged(GL10 gl, int w, int h) {
gl.glViewport(0, 0, w, h);
}
public void onDrawFrame(GL10 gl) {
gl.glClearColor(mRed, mGreen, mBlue, 1.0f);
gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);
}
public void setColor(float r, float g, float b) {
mRed = r;
mGreen = g;
mBlue = b;
}
private float mRed;
private float mGreen;
private float mBlue;
}
This application clears the screen every frame. When you tap on the screen, it sets the clear color based on the (x,y) coordinates of your touch event. Note the use of queueEvent()
in ClearGLSurfaceView.onTouchEvent()
. The queueEvent()
method is used to safely communicate between the UI thread and the rendering thread. If you prefer you can use some other Java cross-thread communication technique, such as synchronized methods on the Renderer class itself. But queueing events is often the simplest way of dealing with cross-thread communication.
Other GLSurfaceView Samples
Tired of just clearing the screen? You can find more interesting samples in the API Demos sample in the SDK. All the OpenGL ES samples have been converted to use the GLSurfaceView view:
- GLSurfaceView - a spinning triangle
- Kube - a cube puzzle demo
- Translucent GLSurfaceView - shows how to display 3D graphics on a translucent background
- Textured Triangle - shows how to draw a textured 3D triangle
- Sprite Text - shows how to draw text into a texture and then composite it into a 3D scene
- Touch Rotate - shows how to rotate a 3D object in response to user input.
Choosing a Surface
GLSurfaceView helps you choose the type of surface to render to. Different Android devices support different types of surfaces, with no common subset. This makes it tricky problem to choose the best available surface on each device. By default GLSurfaceView tries to find a surface that's as close as possible to a 16-bit RGB frame buffer with a 16-bit depth buffer. Depending upon your application's needs you may want to change this behavior. For example, the Translucent GLSurfaceView sample needs an Alpha channel in order to render translucent data. GLSurfaceView provides an overloaded setEGLSurfaceChooser()
method to give the developer control over which surface type is chosen:
setEGLConfigChooser(boolean needDepth)
- Choose a config that's closest to R5G6B5 with or without a 16-bit framebuffer
setEGLConfigChooser(int redSize, int greenSize,int blueSize, int alphaSize,int depthSize, int stencilSize)
- Choose the config with the fewest number of bits per pixel that has at least as many bits-per-channel as specified in the constructor.
setEGLConfigChooser(EGLConfigChooser configChooser)
- Allow total control over choosing a configuration. You pass in your own implementation of
EGLConfigChooser
, which gets to inspect the device's capabilities and choose a configuration.
Continuous Rendering vs. Render When Dirty
Most 3D applications, such as games or simulations, are continuously animated. But some 3D applications are more reactive: they wait passively until the user does something, and then react to it. For those types of applications, the default GLSurfaceView behavior of continuously redrawing the screen is a waste of time. If you are developing a reactive application, you can call GLSurfaceView.setRenderMode(RENDERMODE_WHEN_DIRTY)
, which turns off the continuous animation. Then you call GLSurfaceView.requestRender()
whenever you want to re-render.
Help With Debugging
GLSurfaceView has a handy built-in feature for debugging OpenGL ES applications: the GLSurfaceView.setDebugFlags()
method can be used to enable logging and/or error checking your OpenGL ES calls. Call this method in your GLSurfaceView's constructor, before calling setRenderer()
:
public ClearGLSurfaceView(Context context) {
super(context);
// Turn on error-checking and logging
setDebugFlags(DEBUG_CHECK_GL_ERROR | DEBUG_LOG_GL_CALLS);
mRenderer = new ClearRenderer();
setRenderer(mRenderer);
}
Learn about Android 1.5 and more at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and to field your toughest questions.
Sony Ericsson C901 5 megapixel camera phone
There is some special thing in Sony Ericsson C9xx series phones. that is all of them are high quality camera phones. the Sony Ericsson C905 was the world's first 8Mp camera phone and C902 is a 5Mp camera phone. The newest member of this family is Sony Ericsson C901 which has 5Mp camera. it will be launched on the middle of year 2009.
it's a 3G phone which supports 3.6Mbps HSDPA. the display is 2.2 inches and it supports 240 x 320 pixels resolution. C901 has a Accelerometer sensor to rotate the user interface when you turn the phone. it has 110Mb internal memory and supports up to 8GB micro SD memory cards.
C901 has Walkman quality media player with Track id music recognition feature. also it has a FM radio with RDS.
as i said earlier C901 has 5Mp camera. it supports 2592 x 1944 pixels maximum picture resolution and comes with Xenon flash. the camera application has Geo-tagging (cell-ID) and face and smile detection features.
Sony Ericsson C901 has number of built in applications. even the GPS is not available in this phone, it has Google maps application. also it has Picture editor,blogging software and a YouTube application.
Privacy Policy
Collection of Information -
We collect personally identifiable information, like email addresses, ONLY when voluntarily submitted by our visitors. This information is only used to fulfill your specific request (for example to add you to our mailing lists).
Cookie/Tracking Technology -
We use Google as third-party advertising vendor to serve ads when you visit our website. Please note that -
- Google, as a third party vendor, uses cookies to serve ads on our site.
- Google's use of the DART cookie enables it to serve ads to our users based on their visit to our site and other sites on the Internet.
- Users may opt out of the use of the DART cookie by visiting the Google ad and content network privacy policy.
Commitment to Data Security -
Your voluntarily submitted personally identifiable information is kept secure. Only authorized employees, and contractors like Google Feedburner, who have agreed to keep information secure and confidential, have access to this information. All emails and newsletters from this site allow you to opt out of further mailings
Make your own iPhone Gameboy Case
the mobile experience iPhone Knock Off Edition
ePhone M8 - $159
This particular model known as the ePhone features quad-band, dual SIM clone features bluetooth, handwriting recognition and an unknown UI. The website I found it doesn't have any shots of the OS or reference. It falls a little short in the camera (1.3MP), LCD display (240x320px) as well as the internal storage at 1GB. But, hey, if this thing looks anything like the pictures, you could have everyone fooled with the screen off and laying it on a coffee table.
SciPhone i68 - $104
Again with dual SIM card feature, I was told this iClone is one of the most popular choice. Feature wise, its a quad-band international phone and like the ePhone M8, it boasts a 1.3MP camera and QVGA resolution. With an aluminum casing, this one looks to be a great first gen. knockoff. From the picture, it looks like the black strip on the back is towards the top of the phone. I guess it didn't completely rip Apple off.
Meizu M8 (Honorable Mention)
While the Meizu M8 MiniOne has always been regarded as a "legit" alternative to iPhone since it offers a step up in function (ie. 3MP camera, copy&paste, 480x720 resolution), I personally find it having too much hardware resemblance as the iPhone, so I am including the Meizu M8 as honorable mention. While this device runs on Windows Mobile and has been marketed openly at tradeshows and around blogsphere, I just find the hardware design too similar not to be labeled as an iClone knock off. Even Meizu's website design has strong resemblance of Apple.
Aside from Meizu, it appears most of the complete knockoff iClones are made by two brands: SciPhone or HiPhone. If you Google them up, you'll find a dozen or so models made by both. There is a market for everything!
Future-Proofing Your Apps
Hi, developers! I hope you've heard about the early-look version of the Android 1.5 SDK that we recently released. There are some great new features in there, but don't get too excited yet -- some of you will need to fix some problems in your apps before you can start taking advantage of Android 1.5.
We've done some fairly extensive testing of the popular apps on the Android Market, and it turns out that a few of those apps use some bad techniques that cause them to crash or behave strangely on Android 1.5. The list below is based on our observations of five ways that we've seen bad apps fail on 1.5. You can think of these as "anti-patterns" (that is, techniques to avoid) for Android development. If you've written an app with the Android 1.0 or 1.1 SDKs, you'll need to pay close attention.
Technique to Avoid, #1: Using Internal APIs
Even though we've always strongly advised against doing so, some developers have chosen to use unsupported or internal APIs. For instance, many developers are using the internal brightness control and bluetooth toggle APIs that were present in 1.0 and 1.1. A bug -- which is now fixed in Android 1.5 -- allowed apps to use those APIs without requesting permission. As a result, apps that use those APIs will break on 1.5. There are other changes to unsupported APIs in 1.5 besides these, so if you've used internal APIs in your apps, you need to update your apps to stop doing so. Even if they don't break on Android 1.5, there's a good chance they will on some later version. (There's some good news, though: because "flashlight" apps are so popular, we've added the "screenBrightness" field on the WindowManager.LayoutParams class just for that use case.)
Technique to Avoid, #2: Directly Manipulating Settings
Okay, strictly speaking this one isn't evil, since this is a change in behavior that we made to Android itself. But we made it because some developers were doing naughty things: a number of apps were changing system settings silently without even notifying the user. For instance, some apps turn on GPS without asking the user, and others might turn on data roaming.
As a result, applications can no longer directly manipulate the values of certain system Settings, even if they previously had permission to do so. For instance, apps can no longer directly turn on or off GPS. These apps won't crash, but the APIs in question now have no effect, and do nothing. Instead, apps will need to issue an Intent to launch the appropriate Settings configuration screen, so that the user can change these settings manually. For details, see the android.provider.Settings.Secure class, which you can find in the 1.5_pre SDK documentation (and later). Note that only Settings that were moved to the Settings.Secure class are affected. Other, less sensitive, settings will continue to have the same behavior as in Android 1.1.
Technique to Avoid, #3: Going Overboard with Layouts
Due to changes in the View rendering infrastructure, unreasonably deep (more than 10 or so) or broad (more than 30 total) View hierarchies in layouts are now likely to cause crashes. This was always a risk for excessively complex layouts, but you can think of Android 1.5 as being better than 1.1 at exposing this problem. Most developers won't need to worry about this, but if your app has very complicated layouts, you'll need to put it on a diet. You can simplify your layouts using the more advanced layout classes like FrameLayout and TableLayout.
Technique to Avoid, #4: Bad Hardware Assumptions
Android 1.5 includes support for soft keyboards, and there will soon be many devices that run Android but do not have physical keyboards. If your application assumes the presence of a physical keyboard (such as if you have created a custom View that sinks keypress events) you should make sure it degrades gracefully on devices that only have soft keyboards. For more information on this, keep on eye on this blog as we'll be posting more detailed information about handling the new soft keyboards.
Technique to Avoid, #5: Incautious Rotations
Devices running Android 1.5 and later can automatically rotate the screen, depending on how the user orients the device. Some 1.5 devices will do this by default, and on all others it can be turned on by the user. This can sometimes result in unpredictable behavior from applications that do their own reorientations (whether using the accelerometer, or something else.) This often happens when applications assume that the screen can only rotate if the physical keyboard is exposed; if the device lacks a physical keyboard, these apps do not expect to be reoriented, which is a coding error. Developers should be sure that their applications can gracefully handle being reoriented at any time.
Also, apps that use the accelerometer directly to reorient themselves sometimes compete with the system doing the same thing, with odd results. And finally, some apps that use the accelerometer to detect things like shaking motions and that don't lock their orientation to portrait or landscape, often end up flipping back and forth between orientations. This can be irritating to the user. (You can lock your app's orientation to portrait or landscape using the 'android:screenOrientation' attribute in your AndroidManifest.xml.)
Have any of your apps used one of these dubious techniques? If so, break out your IDE, duct tape, and spackle, and patch 'em up. I'm pretty excited by the new features in the Android 1.5 SDK, and I look forward to seeing your apps on my own 1.5-equipped phone -- but I can't, if they won't run! Fortunately, the fixes for these are pretty simple, and you can start fixing all of the above even with the 1.1_r1 SDK release.
By the way, if you'd like to fully immerse yourself in Android 1.5, join us at Google I/O! It's my pleasure to shamelessly plug an event that's shaping up to be the Android developer event of the year. We've added two more sessions—one on multimedia jujitsu, and a particularly interesting session on the Eyes-Free Android project—with even more yet to come. I thought Google I/O was a pretty killer event last year, and this year's looking even better, especially in terms of Android content.
I hope to meet many of you there, but either way, Happy Coding!
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