>140

EVO vs Droid Becomes Sprint vs Verizon (and Verizon Wins)

noreply@blogger.com (Borys Burnayev) — Fri, 02 Jul 2010 12:34:00 +0000

... And the day came when I found myself without any kind of mobile connectivity, unable to make a simple phone call. For those who wonder, it feels like being out without glasses. Or pants.

The long story short, by noon I was signing papers at a Verizon Wireless joint in a mall.

During the months that preceded such an unprecedented event I periodically harassed Verizon and Sprint representatives that can be found in quantities in my whereabouts. I would routinely shake one of my Google-dispensed phones before their faces and ask them for the best deal in town.

Surprisingly, it didn't play out with Sprint. Wherever I went I got the same lame answer - Google or Shmoogle, you need a 2-year contract with us.

It was hard for me to imagine myself having quite a few free and unlocked phones and being on a long term contract with a carrier at the same time.

Two weeks forward. I'm enjoying my good ol' Droid and writing this blog post. I'm on month-to-month contract with Verizon free to leave any time. My Picasa Web Albums are in the gallery again and I can reliably type complex passwords.

Is EVO better than Droid? In some respects. Is it worth the 2-year commitment to Sprint provided you have options? I don't think so.

EVO vs Droid

noreply@blogger.com (Borys Burnayev) — Thu, 03 Jun 2010 17:10:00 +0000

For the past few weeks I've been enjoying HTC EVO 4G that Google lightheartedly passed out to all 5000+ participants of Google I/O during the conference. I've been comparing it with Motorola Droid that Google carelessly passed out to all 5000+ participants of Google I/O before the conference.

For those who reads the news from the bottom, I'm strongly considering the switch to Sprint.

The nitty-gritty comparison details are below.

Call Quality
I use Google Voice and it works well on both phones.

Coverage
No substantial difference in the parts of Washington, DC area where I dwell.

4G
For many, me included, it's a marketing gimmick as 4G coverage is not widely available yet.

3G
Same speed on average.

Operating System and User Interface
Droid comes with a stock 2.1 Android while EVO rocks HTC Sense. I found Sense to be buggy(er) that the stock version. The most annoying thing is EVO routinely "forgets" it has an SD card, the only workaround being to reboot the phone.

The stock Android 2.1 Gallery application comes with Picasa integration baked in so that you can access your Picasa albums right from the Gallery. Sense's gallery replaces that with Flickr and kinda breaks the smooth Google experience.

The built-in Sense widgets look nice and work as expected most of the time. Some of them, such as Weather widget, lack functionality while others, like Calendar, don't behave as expected.

The integrated Clock application that includes the timer and the stopwatch among other things is definitely a plus.

7 home screens of Sense are something that I've yet to feel a need for but the home screen overview via pinch zoom-out is a nifty feature that I use a lot for no reason.

More often than not I wish I could replace Sense with the stock Android and remove much of the bloatware that comes pre-installed on the phone.

Hardware
Even through EVO boasts 1GHz processor (vs Droid's 600 MHz one) I don't see eye-popping difference in the performance of the two phones under my typical usage pattern.

8 megapixel camera with 720p recording works as advertised and is probably the best camera I've seen on a smartphone. Auto-focus is fast and in many cases focuses correctly in a wide range of distances. With my Droid I have to manually select macro mode for close-ups.

720p video looks good for a smartphone and can be viewed in HD on YouTube with a fair amount of pleasure. The 3gp format is problematic for non-linear editing but QuickTime Pro does the basic job of cutting and gluing.

Overall I find the camera to be one of the most compelling reasons for using EVO.

Screen
EVO's 4.3" screen is gorgeous. Large and clear. Easy to tap on correctly. You'll enjoy it.

Keyboard
We all know that EVO doesn't have a physical keyboard. It happened to be less of a problem than I originally thought though. One of the side advantages of a big screen is you can tap-type on it with fewer mistakes reasonably fast. The virtual keyboard that comes with Sense is tangibly better that the stock Android one. Auto-correction works well in many cases. You have to look at what you "typed" though - sometimes you are up to surprises.

The auto-correction somehow does not apply to search and some other input-heavy areas and there I found a lot of room for improvement of my thumb-typing skills.

The Looks
EVO is an eye-candy. Designed after iPhone, it's basically perfect.

Conclusion
I'm sitting on the fence and looking at EVO's territory. Two more weeks to go before the final decision is to be made.

Google I/O Aftermath

noreply@blogger.com (Borys Burnayev) — Mon, 24 May 2010 22:39:00 +0000

Last week I was fortunate to attend the Google I/O event in San Fransisco. Now when the emotions are settled down there's a chance to have a sober look at what happened and what effect it might have on us and the software industry.

The central place at the conference - its "booth" was located right in the middle of the second floor - took Android. Coincidentally the pivot of the second day keynote was also Android. At 100,000 new device activations a day the platform is no longer something to sneeze at. Android 2.2 Froyo was one of the few things that were announced and released during the event.

Another manifestation of the growing strength of Android is the fact that Google bets its new Google TV initiative on it. Yes, all those computers that we customarily call TVs are going to run the operating system with the green robot logo.

What was strangely missing from the keynotes was Chrome OS. My reading is either it's totally not ready for anything (though they did screw up the Google TV demo with a straight face no problem) or there's a change in the wind blowing high in the executive ranks. After Google Phone initiative was suddenly dropped I wouldn't be too surprised to see Chrome OS going out of business and Android taking its place.

Quirky and fragmented as it is, Android is making its way into our lives. If you are a developer you might want to jump on the bandwagon - there's still room and it's going to get big.

How to Upgrade Spring Security 2 to Spring Security 3

noreply@blogger.com (Borys Burnayev) — Fri, 09 Apr 2010 16:51:00 +0000

The short answer is you have to plunge into it head first.

The Problem
You have a working Spring Security 2.0.x setup and want to upgrade to the latest as of the time of this writing version 3.0.x. You did a (re)search on the Internet and found basically nothing. You are puzzled.

The Solution
You are not gonna like it but you have to get your hands dirty, figuratively speaking, and make it happen the hard way.

Remove the old libraries and drop in the new ones. You gotta get a lot of red in your IDE.
Make the red go away. The 3.x distro contains a file named class_mapping_from_2.0.x.txt. It can save you a search or two.
Update your Spring Security config files so that the schemaLocation ends with spring-security-3.0.xsd. If you have a validating XML editor you'll get a fair amount of red wavy lines right away.
Make the red go away. Refer to Security Namespace Configuration section of the manual.
If you happen to use an IDE that understands Java code in JSP pages, such as MyEclipse, hunt for the red there and exterminate it. Otherwise proceed to the next step.
Deploy your application. It'll blow up. That's OK. Have a look at the log. There was a lot of shuffling of the properties (defaultTargetUrl etc) among various classes between versions 2 and 3. Move the offending properties in your SS config file as needed.
Your application should now deploy fine. Run it and see if it bombs. It it is it may be because you didn't do a good job at step 5. Now you should have a good indication of where to look at. Have a look and resolve.
If you made it this far you are done. Congratulations!

The Rhetoric
Now when I'm done with the upgrade I keep asking myself the same question. How comes the supposedly best-of-breed enterprise-class software breaks backward compatibility in such an intricate, outrageous, in-your-face way?

Understandably Spring Security is the only game in town for the security-heavy shops on the EJB-less enterprise bandwagon. This is a classic vendor lock-in scenario in its uglier manifestation. A (re)design decision made by a few talanted developers is going to reverberate in the enterprise for years.

The enterprise is obsessed with compatibility and continuity. How can I recommend Spring Security to my next enterprise client with a straight face?

Don't Look a Gift Horse in the Mouth

noreply@blogger.com (Borys Burnayev) — Thu, 08 Apr 2010 23:43:00 +0000

In the rightful effort to disseminate the up-to-date Android technology Google has embarked on something officially called "device seeding program for top Android Market developers".

ActionComplete has been steadily approaching the 50000 downloads mark and has an average rating of 3.97 so here I am playing with a new toy.

Google couldn't go the straight way and decided to introduce an element of surprise by pseudo-randomly sending out Nexuses and Droids. It feels like developers in the US got Droids while other developers got Nexuses.

The Droid I got came with a complimentary one month of free Verizon service, both voice and data. A very smart move as that was the only way for them to make me try the Verizon network.

By now I've already used around 10 days of that free month and can report the initial findings.

The Phone
Fast. Functional. I always try to come up to a triad... This time it's going to be a dynamic duo.

I realized why it has that sunken chin. That's the only place where you can safely hold the phone in landscape without hitting the touch-sensitive buttons. Even with that in mind I still touch them a lot in very inappropriate moments. I'm yet to figure out why I keep sending empty emails now and then.

Oddly enough, the keyboard is less convenient than that on G1. The upper row is quite close to the slid-out top of the phone and you end up touching it a lot with your thumbs. The buttons are almost flat and the press response is minimal.

The good part is the phone is fast. And very functional. You can actually do what you are supposed to be able to and it usually works as advertised. You can get the directions to your lunch destination before you arrive there. You can view house prices in Zillow application for Android while driving at 40 mph. Believe it or not, but Droid in fact Does.

Which logically brings us to the the next review item - the network.

Verizon touts itself as the best network in the States (who doesn't?). Here in DC it might well be the case. The data network is always in 3G mode wherever I am. The connection is fast and reliable. The maps load promptly as you drive, voice-assisted navigation works well most of the time.

To keep its network fast Verizon puts some restrictions in place that are not typically found on other networks. You can't upload a video over 3G - it'll sit in the queue until you get a Wi-Fi connection.

The Conclusion
I found my attraction to the phone growing with every single day. Maybe it'll even become my primary phone after the free honeymoon is over. Who knows?

iPad First (and Last) Impression

noreply@blogger.com (Borys Burnayev) — Tue, 06 Apr 2010 12:50:00 +0000

In this post entitled starting with a lower case letter I'll talk about my first impression about the device that purportedly is the future of computing - iPad.

The best way to get a hands-on experience with the new Apple toy is to head to one of your local Best Buys as they tend to be less crowded than Apple Stores.

In my mind I was picturing an iPad as a laptop-screen-size device so it took me a while to find the demo stand featuring those puny things. The tablet is smaller that you might think it is.

But hey - it's not something to be upset about. It weighs way more than you expect! Take a 700-page book and you know what an iPad feels like in your hands.

The browser seems to be fairly limited even for what it officially supports, which does not include Flash.

The screen has a netbook-like resolution of 1024 x 768, which sits somewhere on the border between a smartphone and a computer, and does not always displays web applications correctly. Native applications have a clear edge over web applications on iPad - they generally look nicer and perform better.

I had high hopes that iPad would be a great device to run rich Internet applications... I have high hopes Chrome OS will give rise to great devices to run rich Internet applications.

Sexier than iPhone, Tougher than Droid

noreply@blogger.com (Borys Burnayev) — Thu, 25 Mar 2010 14:34:00 +0000

This year's CTIA Wireless trade show saw not one but two smartphones poised to eclipse the current market leader iPhone.

Both Samsung Galaxy S and HTC Evo 4G are beautifully designed devices harnessing the full power of Android 2.1 platform. The design of both phones is clearly inspired by the target rival, which is just fine.

Hardware of either device is top-notch and beats iPhone hands down. 720p HD recording, front-facing camera, 1GHz processor... You name it and it's likely there.

On the software front both Samsung and HTC decided to go with a custom user interface overlay on top of a stock Android. The customizations seem to be well thought out and add to the charm of the devices. The downside is most likely you'll have to forget about upgrading to the latest Android versions when they become available.

Integration with major social networks such as Facebook and Twitter is baked into either device.

Both phones seem to be "Google experience" devices meaning that all the good stuff from Google you come to expect from an Android phone such as Google Maps/Navigation, Gmail, Calendar, and the like is going to be at your fingertips.

Android Market is the source of more than 30,000 applications that can augment the out-of-the-box experience for either phone. A number of useful apps come preinstalled. Galaxy S features Swype - a soft keyboard input accelerator for smartphones.

The phones will be available later this year, presumably before the next-gen iPhone is announced, and the price is currently unknown. HTC Evo 4G is going to be offered by Sprint while Galaxy S is currently not tagged with a carrier. As it's a GSM phone it's reasonable to expect it to be available from either AT&T or T-Mobile in the US.

If you don't have a smartphone or your iPhone contract is about to expire you might want to have a long and close look at these devices. This is the first time I recommend an Android phone over an iPhone to a friend.

The Second Life of my G1

noreply@blogger.com (Borys Burnayev) — Wed, 24 Feb 2010 18:26:00 +0000

Over the past month I've been enjoying the Indian summer of my Android phone. Long story short - it got a new battery. Not just a new battery - a 2200 mAh one. That's about twice the capacity of a stock G1 unit (1150 mAh).

The catch? The phone got fatter by a quarter of an inch or so. Now I can feel and appreciate the thing.

Most importantly though I can use it. Fishin' 2 Go, Google Navigation, the whole nine yards. A day or two without a recharge. That's a terrific improvement over 4 something hours the old faithful could squeeze out of itself before.

If you happen to have the first Android phone and are contemplating a replacement device that is about to be released "soon", 20 bucks can be the bridge financing you are looking for.

GAE Developer Tip: Updating Database Schema

noreply@blogger.com (Borys Burnayev) — Sat, 20 Feb 2010 16:09:00 +0000

The backend of Google App Engine is not relational. One of the implications is different records in the same table can have different number of columns. Sometimes it's just fine, other times you want it the conventional way - all rows having the same columns.

The practical consequence of such a design is that a field added to a domain object will only appear in objects of this type created after the structure of the object was modified. All the objects created before the change will happily live with the old structure.

Before you know it you'll want to filter or sort on the newly added attributes. What happens next is you realize your queries totally ignore your good ol' buddies without the new attributes. Which makes you wanting desperately to bring your schema to order and add the missing columns to all the records of your table so to speak.

Here comes a surprise. You can't really do that easily. What you need to do is to fetch ALL the objects and re-save them. You might have thought that the new columns are there and you can query for something like "myNewColumn == null". No such luck. GAE makes a stark distinction between null and missing columns. Until you explicitly set your newly added columns to null they are non-existent in the eyes of our beloved App Engine.

Back to the show. You need to fetch ALL the objects and re-save them. While not a problem per se, the approach faces a number of technical challenges due to another design feature of App Engine - the limitation on the number of results the query can return and on the duration of a single request. Currently a query is restricted to 1000 results and a single request can't take longer than a certain number of milliseconds. Meaning you have to batch up your work.

Batching up the to-be updated objects can become a non-trivial task and will likely be a one-off solution for every schema update. This is not optimal as what you want is to think once and run everywhere.

If you made it to this point we are on the same page. Now bear with me.

For our batching effort to succeed we need something that we can query reliably to figure out what needs to be updated. To this end we create a special attribute called, say, schemaVersion.

We created schemaVersion attribute for ALL our entities and assign it a default value. From now on all our objects are versioned in a database sense.

Fast forward into the future. Having been in production for a few months we realize we need another attribute on that entity. What do we do?

Add the new attribute to the entity
Increase the default value of schemaVersion
Create a finder method in your DAO tier to retrieve a fixed number of entities whose version number is below current
Create a cron job to retrieve the outdated objects and update them as needed based on their version and the current schema version for the entity in question

Rejoice - you are in control of your database schema again.

The code snippets below illustrate the approach.

In your domain object:

 public class Action implements Serializable {  
    @Persistent  
    private Integer deleted = 0;  
    @Persistent  
    private Integer schemaVersion = 1;  
 }

Somewhere in your DAO layer:

    PersistenceManager pm = PMF.get().getPersistenceManager();  
    try {  
       Query query = pm.newQuery(Action.class);  
       query.setFilter("schemaVersion < :schemaVersion");  
       query.setRange(0, 100);  
       actions.addAll(pm.detachCopyAll((Collection<Action>) query.execute(currentVersion)));  
    } finally {  
       DAOUtil.closePM(pm, logger);  
    }

In your batch job:

    List<Action> actions = actionDAO.findForSchemaUpdate(1);  
    for (Action action : actions) {  
       int currentVersion = action.getSchemaVersion();  
       switch (currentVersion) {  
       case 0:  
          action.setDeleted(0);  
       default:  
          break;  
       }  
       action.setSchemaVersion(1);  
       actionDAO.save(action);  
    }

Cleaning up Indexes in Google App Engine/Java

noreply@blogger.com (Borys Burnayev) — Fri, 12 Feb 2010 01:19:00 +0000

This is so peculiar I still can't decide if I should laugh or cry...

In short, if you use GAE Java SDK you can't delete indexes in your App Engine application.

To give you some context, indexes is GAE's only way of executing queries against the data store and a single query can use a maximum of 1 (one) index. For the things to be entertaining there is a free quota of 100 indexes per application. Before you know it the indexes quota goes in the red area on the dashboard and your next deployment fails.

At this point you realize a good deal of the indexes out there are not relevant any more and should be disposed of. You head to the dashboard and verify that it is the case indeed. You look for Delete button. For Remove button. For Purge button. For any button... No such luck. There are no buttons on Datastore Indexes page of GAE Dashboard.

Alright, you think. There must be a utility of some kind to get those darn indexes out of sight. And yes there sure is one! In GAE Python SDK...

This is the hilarious part. You program in Java and you use Python to "vacuum" your indexes. Isn't that intuitive?

This must be one of their April Fools jokes that slipped through the fingers. To remind the fine folks at Google we are not there yet star this issue.

On iPad and Business Opportunity

noreply@blogger.com (Borys Burnayev) — Fri, 29 Jan 2010 11:27:00 +0000

Like it or not - iPad is there to be unleashed on the consumer in less than 60 days.

Will it outsell its older diminutive cousins? Probably not. Will it sell in quantities? Likely so. Which leaves me wondering what kind of business opportunity lies behind the polish and gloss of Apple's latest brainchild.

iPad has a modestly good screen resolution of 1024 x 768 pixels and sports a screaming-fast browser. All that makes it a good candidate for running web applications. While "native" apps will definitely run better and look nicer on the tablet, the web applications on iPad should be quite usable as compared to the experience on other mobile i devices.

Now imagine you have a web application...

All of a sudden your user base might expand into the segments you'd never thought of as your "customers". Those people are likely going to be less computer-savvy than you might imagine. Yet iPad will make it ridiculously easy for them to access your web application.

The moral? If you are a web application... Look good at 1024 x 768. Be utterly intuitive - no iPad user is going to read the manual.

Looks Matter. Even If You Are a Smartphone

noreply@blogger.com (Borys Burnayev) — Thu, 14 Jan 2010 23:45:00 +0000

It must have been the thousandth time I saw a Nexus One ad for the past week. And every singly time I see it I ask myself the same question: why that trackball thingy panel?

Since the first time I saw the phone a few month ago when it was still called HTC Passion I couldn't grasp the grand idea behind the exterior design of the device. It must have been something beyond the design realm that prompted the lower panel. They must have desperately needed that space to ensure proper cooling or something.

One of iPhone appeals is its symmetric design. Somehow Android phone manufacturers at large try to "differentiate" themselves with chins, hips, and other nonsense. Motorola CLIQ comes closest to an eye-pleasing design. If it had decent hardware and software I could have bought it.

Apple figured out the optimal exterior design of a smartphone and Microsoft understands it. That's why Windows Mobile flagship device looks remarkably familiar. When it hits the market, preceded by a monumental marketing push from Redmond, the consumer will go for it.

Google's experimental approach to everything works great with gratis online services. Unless the plan is to give Android phones away, it might make sense to build something that not only works but also looks great. Or just photoshop those ads...

Google vs Android Developers

noreply@blogger.com (Borys Burnayev) — Wed, 13 Jan 2010 01:22:00 +0000

Android SDK 2.1 is out together with a number of questions I'd like to ask.

The first device leveraging the platform was released a week ago. The developers were left in the dark till now. How comes?

This release is yet another manifestation of the lack of well-thought policy over there at Google on what stands behind a version number.

2.1 corresponds to API level 7 ("API level" is an internal SDK version identifier used by Android). It's interesting how 2.0 (API level 6) and 2.0.1 (API level 5) got moved to "Older Platforms" area of the Android developer site while Android 1.6 (API level 4) and 1.5 (API level 3) are still among the "current" platforms.

Is any new Android SDK version going to deprecate it's highest ranked predecessor from now on? With great ancestors 1.5 and 1.6 staying there forever?

Developers need clear version numbering that can be correlated to stability and longevity of the corresponding SDK. Preview and beta versions should be named as such. API-breaking versions should get an incremented minor version number (i.e. 2.o.1 shouldn't have existed, it should have been 2.1.0).

While software versions have been increasingly used for marketing purposes, it's important to remember that they do have a meaning in software engineering.

Here's a painfully true quote of MG Siegler of TechChrunch:

Simply put, iPhone apps, as a whole, are much, much better than Android apps. Maybe that’s because Android apps aren’t quite as mature yet. But I don’t know. The Android Market has been around for over a year now, and the fact that there still isn’t a Twitter app that’s as good as the top five iPhone Twitter apps is a bit odd to me.

Developers are the crucial part of Android ecosystem. Google has some thinking to do. Maybe eventually the horse will be put in front of the cart.

Twitter Lists are Great. Now I Want Twitter Categories

noreply@blogger.com (Borys Burnayev) — Tue, 12 Jan 2010 01:40:00 +0000

It's been quite a while since Twitter unleashed lists and I'm finding them quite useful for organizing the accounts and people I follow.

TwitHive - an excellent web application for Twitter - has been providing list-like functionality since long before lists came to be. Lists made it a commodity and as it stands now most Twitter clients allow us to access the content we care about naturally via channels.

Which brings us to the current day and makes me think about something very similar to lists but serving a totally different purpose - the ability to split the content I create into separate slices, or categories, so that the people following me can choose either to follow the stream in its entirety or to limit themselves to just a subset of it. In this setup when I configure a new service to auto-post my content to Twitter I'll choose whether I want to post to the "raw" stream or to a particular "category" so that only people following that category of mine will get the update. This way I'll be able to easily separate my lunch-time musings from Android developer tips and such.

Wishful thinking? Sure enough. Yet we all know that Twitter growth has flattened recently and they must be on a desperate search of ways to turn the situation around. Categories might be a step in the right direction.

The Perfect Android Phone

noreply@blogger.com (Borys Burnayev) — Fri, 08 Jan 2010 23:54:00 +0000

Different people choose Android to be the OS that powers their smartphone for different reasons. My reason is Android provides the best Java implementation in the mobile domain. Forget about Java ME. Android's Java is a real thing that in many respects is on par or better than its desktop counterpart.

Your reason is probably different but you decided to be on the lookout... And found this post talking about my vision of a perfect Android phone.

1. Affordability

Mobile landscape evolves quickly. A smartphone has to be affordable. Affordable to me means less than $200. Enough said.

2. Google Voice and Data-only Plan

I don't mind if the phone's price tag is attached to a contract with a major carrier. The plot is to port my number to Google Voice and run away with a reasonably priced data-only plan.

3. Upgradability

The dictionaries don't know such a term but it's as simple as being able to upgrade your phone to the most recent version of Android. For better or worse Google produces new Android versions at mind-boggling pace and you want to stay on top on that. There are hardware limits to how far you can go with it but you should be able to have a reasonably recent version.

4. A MID (Mobile Internet Device) Will Do

Does it really have to be a phone? Not necessarily. An Android-based tablet a la yet-to-be-announced Dell Streak will do just fine. Tablets typically offer a slightly larger screen (5 inches is a good way of thinking about it) but are still highly pocketable. Due to the larger screen size the on-screen keyboard becomes quite usable and the lack of physical keyboard is less of an issue.

Currently this fine strategy faces a number of obstacles.

1. You can't really port your number to Google Voice (yet).

2. Reasonably priced Android phones are outdated on arrival. I'm going to speculate that Google treats its partners as bad as it treats developers by not providing either with timely information and by frequently changing its plans, conventions, and intents without prior notice.

The moral of the story is that if you are shooting for an Android phone, either as a user or a developer, you'd better look for a future Google-branded device. The odds are you are better off with a MID rather than a phone. If Google happens to plan to offer one that is.

Android will take over the world in about 6 months. I've been saying that for the past year and half.

Another Day, Another Android AppStore

noreply@blogger.com (Borys Burnayev) — Fri, 08 Jan 2010 12:47:00 +0000

Yesterday at CES that's currently taking place in Las Vegas Lenovo announced its first Android phone - LePhone. It's a nifty phone but that's not what I'm going to talk about. As I figured out Lenovo is working on its own Android AppStore.

The phone is originally bound for China and Android Market is not accessible in that country. Understandably there needs to be an app distribution channel for the platform to be successful. However as far as I can tell there are other efforts in this direction by other Chinese companies. Barring the obvious option of Android Market as the preferred distribution mechanism, both consumers and developers want a single application distribution channel, at least per country.

Hopefully Lenovo realizes what they are up to.

Why Unlocked Phones Don't Matter in the US

noreply@blogger.com (Borys Burnayev) — Thu, 07 Jan 2010 23:15:00 +0000

This is the second post in a row with a title that start with "why". I wonder if it's due to Google Nexus One "why" moment.

Anyway, as the title says unlocked phones don't matter in the US. Here's the reasoning that made me believe so.

There are four major cellular network carriers in the states: Verizon, AT&T, Sprint, and T-Mobile. Verizon and Spring use CDMA technology that seem to be used primarily in USA while AT&T and T-Mobile employ a more recent GSM tech widely deployed worldwide.

CDMA and GSM are not compatible at all which reduces the number of major networks an unlocked phone can be used on to just two. That means you can potentially use your unlocked phone on either Verizon or Sprint or on either AT&T and T-Mo. They keyword here is "potentially".

Further "research" reveals that portability between the major US CDMA carriers Verizon and Sprint is not universally guaranteed and an arbitrary phone will unlikely to work on the other network even if unlocked.

While GSM was designed for portability, there are still minutiae on the technical side that can prevent full compatibility on the data side, which is essential for smartphones such as Nexus One. Specifically, different GSM carriers use different radio frequency bands for GSM 3G data transfer. It happens to be the case that AT&T and T-Mo are just such carriers meaning an unlocked Nexus One will only work on T-Mo's 3G network but not on AT&T's.

Now I'll ask you a question. What is the point of buying a $530 unlocked phone if the only major network you can use it on is T-Mobile?

Why I'm not Buying Nexus One

noreply@blogger.com (Borys Burnayev) — Tue, 05 Jan 2010 22:34:00 +0000

Today Google has officially become a hardware company with the debut of its Android-based smartphone called Nexus One, which is available via the only channel - online from Google.

A lot has been said on how this thing is better than iPhone and the sliced bread. However as the title says I'm not buying it and here's why.

1. The Price

$530 might sound great across the pond but here in the US folks "en masse" are not get used to swasting (swasting = (s)pending + (wasting) - got it?) half a grand for a toy that's gonna become outdated in three weeks or so. That rules out the unlocked option.

The other option allows you to have the phone for $180 with a 2-year T-Mobile contract on an $80/month plan. I've been with T-Mo for the past umpteen years and despite that can't just upgrade one of my phones. That pisses me off.

2. Battery Life

Good luck with a 1400 mAh battery on a beast with 1GHz processor... My biggest gripe about G1 is miserable battery life. To be usable a phone should survive a full day on a single charge while being used.

3. Keyboard (or Rather the Absence Thereof)

I use my smartphone primarily as a GTD system (ActionComplete). Keyboard is an essential element of a satisfying user experience in such a scenario.

4. Design

Some might find the lower panel with the lonely trackball attractive but I just don't like it.

5. Google's Disrespect for Developers

The new shiny thing runs Android 2.1. Where the heck is Android 2.1 SDK that I can use to make sure my applications work on the device?

I'm not buying Nexus One.

What's up with Android Guys at Google?

noreply@blogger.com (Borys Burnayev) — Thu, 03 Dec 2009 23:06:00 +0000

Today witnessed the release of 2 (two) new versions of Android: 1.6, Release 2 and 2.0.1, Release 1.

I'd like to know two things:

Who happened to come up to this horrendous versioning schema and
Where is Android 2.0, Release 1

Just in case the news went past the fine gentlemen at Google... Apache Software Foundation has for ages had written versioning guidelines that Java community came to respect and follow. While the desire to innovate is understandable, the developer community will highly appreciate sticking to the standard.

Android 2.0 Platform is gone from the developer site. What does that mean? Was it a royal screw-up that nobody wants to remember?

Anyone has a plausible explanation?

Android Developer Howto: Integration with Quick Search Box

noreply@blogger.com (Borys Burnayev) — Mon, 30 Nov 2009 23:55:00 +0000

Quick Search Box is a feature introduced in Android 1.6 that I lauded in a previous post. If you are an Android developer, the good news is you can make QSB suggest results from within your applications.

The purpose of this post is to provide a human-understandable overview of the process that will allow you to integrate your application with QSB quickly and painlessly.

To get the job done you need to supply four things: an xml/searchable.xml file, a few entries in your manifest, a content provider that QSB will query for the data, and an activity to handle the taps on your suggestions. In addition to that you'll need to somehow communicate to your users that your application is searchable so that they enable it for search on their phones.

searchable.xml

This file, usually named as above and found in res/xml directory, seems to be the logical beginning of the story. It should look similar to this one:

<?xml version="1.0" encoding="utf-8"?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android" android:label="@string/search_label"
android:searchSettingsDescription="@string/search_settings_description" android:includeInGlobalSearch="true"
android:searchSuggestIntentData="item" android:searchSuggestAuthority="com.burnayev.actioncomplete.search">
</searchable>

android:label defines the text that a user will see as the name of your application under More results... when QSB spews out its suggestions.

android:searchSettingsDescription is used as the description of your searchable items in Settings/Search/Searchable items (this is the place where your users will need to navigate to enable your app for QSB suggestions). This is what goes into the second line of the row. What goes into the first line (i.e. denotes the name of your application) you'll know in a moment.

android:includeInGlobalSearch="true" is the magic word that makes QSB care about your efforts.

android:searchSuggestAuthority tells "the system" what content provider to look for to get the search results from your application.

The Manifest Magic

You application's manifest has to declare two things: the content provider and the activity that's going to handle the taps on your suggestions in QSB.

The provider declaration looks like this:

<provider android:name=".SearchProvider" android:authorities="com.burnayev.actioncomplete.search"
android:syncable="false" />

and defines the provider class name (android:name) as well as the "authority" (android:authorities), which is an identifier that the system uses to figure out who provides what kind of data.

<activity android:name=".activity.GlobalSearchHandler" android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.SEARCH" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
<meta-data android:name="android.app.searchable"
android:resource="@xml/searchable"/>
</activity>

The snippet above says that GlobalSearchHandler (android:name) is going to handle QSB suggestion taps (intent filter android.intent.action.SEARCH).

Now the drum roll, please... android:label defines the name of your application in Settings/Search/Searchable items. And you thought it wasn't straightforward...

The Content Provider

This is the centerpiece of the story. It goes like this:

public class SearchProvider extends ContentProvider {
public static final String AUTHORITY = "com.burnayev.actioncomplete.search";

private static final String[] COLUMN_NAMES = new String[] { "_id", SearchManager.SUGGEST_COLUMN_TEXT_1,
SearchManager.SUGGEST_COLUMN_TEXT_2, SearchManager.SUGGEST_COLUMN_INTENT_ACTION,
SearchManager.SUGGEST_COLUMN_INTENT_DATA_ID };
private static final int SEARCH_SUGGEST = 0;

private static UriMatcher uriMatcher;
static {
uriMatcher = new UriMatcher(UriMatcher.NO_MATCH);
uriMatcher.addURI(AUTHORITY, SearchManager.SUGGEST_URI_PATH_QUERY, SEARCH_SUGGEST);
}

@Override
public boolean onCreate() {
searchDAO = new SearchDAO(getContext());
return true;
}

@Override
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
String searchString = uri.getLastPathSegment();
MatrixCursor cursor = new MatrixCursor(COLUMN_NAMES);
List<Action> actions = // get your stuff, e.g. query a database or something
for (Action action : actions) {
Object[] rowObject = new Object[] { action.getId(), action.getName(), action.getProjectName(),
Constants.ACTION_ACTION_DETAILS, action.getId() };
cursor.addRow(rowObject);
}
return cursor;
}

@Override
public String getType(Uri uri) {
switch (uriMatcher.match(uri)) {
case SEARCH_SUGGEST:
return SearchManager.SUGGEST_MIME_TYPE;

default:
throw new IllegalArgumentException("Unknown URI " + uri);
}
}

@Override
public Uri insert(Uri uri, ContentValues values) {
throw new UnsupportedOperationException();
}

@Override
public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
throw new UnsupportedOperationException();
}

@Override
public int delete(Uri uri, String selection, String[] selectionArgs) {
throw new UnsupportedOperationException();
}

}

Notice the AUTHORITY constant. QSB looks at authorities in searchable.xml and queries a matching provider.

COLUMN_NAMES array is used to define both the way your search suggestions are presented in QSB (SUGGEST_COLUMN_TEXT_1, SUGGEST_COLUMN_TEXT_2) and the manner a suggestion tap is processed by your application (SUGGEST_COLUMN_INTENT_ACTION, SUGGEST_COLUMN_INTENT_DATA_ID).

The query method is where you perform the real search within your application, build a Cursor, and return it for further processing by QSB.

You gotta decide on a communication mechanism between your search provider and suggestion taps handler. In this example I use SUGGEST_COLUMN_INTENT_ACTION to specify the intent and SUGGEST_COLUMN_INTENT_DATA_ID to specify the particular item id.

Handling Suggestion Taps

Last but not least you have to decide what to do with the taps on the QSB suggestions for your application. A possible approach is illustrated below:

public class GlobalSearchHandler extends Activity {

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

Intent intent = getIntent();
String intentAction = intent.getAction();
Uri intentData = intent.getData();
Long id = null;
try {
id = intentData.getLastPathSegment() != null ? Long.valueOf(intentData.getLastPathSegment()) : null;
} catch (NumberFormatException e) {
// null id may be just fine or it may be not
}
if (id != null) {
Intent targetIntent = new Intent(intentAction);
// configure the intent based on the retrieved id
startActivity(targetIntent);
}
finish();
}

}

The noteworthy part of the code snippet above is this:

String intentAction = intent.getAction();
Uri intentData = intent.getData();

Both intent action and intent data are based on the cursor fields you set in your search provider. They allow you to properly delegate further processing to the appropriate part of your application.

By now you should have a working prototype of your application nicely integrated with Android Quick Search Box. It's time to tell your users to go to Settings/Search/Searchable items and enable your application for QSB search suggestions.

Google Maps Navigation vs Garmin Nuvi 265WT

noreply@blogger.com (Borys Burnayev) — Fri, 27 Nov 2009 13:35:00 +0000

I've been pleasantly surprised by a recent announcement about the back-port of Google Maps Navigation to Android 1.6, which all happy T-Mobile G1 owners are supposedly running.

For the few days since the announcement I've been test-driving the new application to get a feel of whether it's an epochal event or a blip on the technology radar.

I also happen to have Garmin Nuvi 265WT GPS unit at hand, which currently goes for $159.99 at Amazon, thus feeling to be in position to make comparisons and draw conclusions.

Without further ado I'm going to present my humble findings to the avid reader.

The best part of the deal with Google Maps Navigation is that it comes to your nearest Android phone at absolutely no cost, i.e. free no strings attached.

The worst part of the deal with Google Maps Navigation is that you get pretty much what you paid for.

Diving into the details now...

GMN (that's Google Maps Navigation) is nicely integrated with GM (that's Google Maps). You get your directions as usual, then choose Navigate option and you are in the game.

Soon after the device gets itself oriented a nice metallic female voice tells you something. After a little practice you come to realize that what is being said at this point is the direction to the start of the route such as "drive South-West ...". Garmin unit would just say something like "proceed to route", which is more succinct and understandable. Garmin's voice sounds much more human-like and is quite a bit more understandable.

Next goes the regular routine of voice commands that makes you feel good about your navigational abilities. I'm still trying to decide if I prefer quarter miles GMN style or decimal miles Garmin style. I do prefer "turn to Main Street" Garmin style announcement to "turn at Main Street" GMN style announcement.

I happen to live in an area where a lot of road construction is going on and was expecting GMN to beat Garmin to the punch with the accuracy of the maps. No such luck. Google maps are as inaccurate as one year old Garmin maps installed on my GPS unit.

My major expectation about a GPS navigation system is it's going to tell me where to go when I need it and that's exactly what my Garmin unit does. GMN does the same except when it doesn't feel like that... At one point on a test drive I realized that my phone was rebooting itself instead of telling me where to go.

GMN builds routes as quickly as Garmin but Garmin's routes are generally faster in terms of travel time and better in terms of convenience.

My Garmin GPS unit came with a nice dashboard mount and a car charger. My phone didn't. Unless you are voice-guiding your short office commute, which you probably know as the back of your hand, you'll want a charger. Unless you absolutely don't care about the route your GPS unit happened to choose, you'll want a dashboard mount. Both the charger and the mount are going to spoil that great "get-for-free" feeling for some.

There's been a lot of talk recently on how Google Maps Navigation is going to drive traditional providers of GPS navigation systems out of business. My brief testing makes me believe that as of now GMN is highly beneficial for Garmin, TomTom, and other GPS nav manufacturers as it essentially provides them with free marketing services demonstrating what one can expect from a GPS navigation system to a crowd that might have not ever considered such a system otherwise.

Android Developer Tip: Regenerating R.java

noreply@blogger.com (Borys Burnayev) — Tue, 17 Nov 2009 23:25:00 +0000

I've just spent half an hour trying to fathom how to get back my auto-generated R.java that magically disappeared at some point.

The usual ways of resolving issues such as clean build, restarting IDE, and wiping the screen clean with a damp cloth didn't work.

Googling around did reveal a lot of similar complaints and revived a stark deja vu feeling. The hilarious thing is that once the R guy is gone, a good chunk of your code goes red thus adding to the insult.

Rather than continuing the discovery of all the conceivable strains of the issue found in the wild, I decided to leverage the tried-and-true approach of staring at the code. Having done so for a while I spotted a few red guys under res folder. They were a leftover of my current redesign work that I was about to delete before things went awry. Sure enough, as soon as I hit Del on them the darn R thing automagically reappeared.

The moral of the story is there's just so much magic Google can do for us. Bad resources (e.g. layouts with errors) are not treated gracefully by Google Android Eclipse plugin and can deceive it into deleting R.java with no sound reason.

Quick Search Box Makes Android Smartphones Genuine Google Phones

noreply@blogger.com (Borys Burnayev) — Fri, 02 Oct 2009 21:45:00 +0000

Android 1.6 aka Donut that's being pushed over the air to happy owners of T-Mobile G1 brings us a number of new and exciting features. The one that I'm going to highlight in this post is Quick Search Box.

The idea behind the quick search is to allow a user to enter a search term and intelligently find the most relevant results be it a person in the Contacts list, an application on the phone, a nearby restaurant, or a web property. It goes as far as finding relevant results within applications enabled for such functionality.

What's interesting is that such a seemingly minor feature radically changes the way you interact with your Android phone. Need to call Jim? Type "Jim" in the search box and go from there. Out of gas? Type "gas" in the search box and go from there. Want to launch The Weather Channel app to check the weekend forecast?.. You got the idea.

Search-focused navigation paradigm promoted by quick search box brings Google spirit to Android phones. Like with Google.com or Gmail you search and find. In addition to that what you find on your Android phone is highly personalized and location-savvy. If you don't have an Android phone, buy one and try it for yourself.

Let the Epic Divide Begin - HTC Announces Tattoo

noreply@blogger.com (Borys Burnayev) — Wed, 09 Sep 2009 00:19:00 +0000

In today's press release, HTC announced yet another Android phone - Tattoo.

I'm not too fond of tattoos but that's not the point. What differentiates this phone from all of its Android predecessors that made it to the market so far is its meager screen resolution of 240 x 320. Yes, that's what you get when you put a dated BlackBerry on its side.

As Android framework engineer Dianne Hackborn points out:

One of the important things to know about the QVGA devices like this is that
none of the existing apps will show up on the market there, because until
1.6 developers have had no requirement to design for a smaller screen, and
there is little the platform can do to make existing apps work on a smaller
screen with a good experience.

Then she goes on about UI fiddling, alternative layouts, and low-density graphics.

It's all good and well other than I'm not gonna do that.

For many Android applications, ActionComplete included, the main differentiating factor is a neat and clean user interface. Addressing a different screen size is roughly equivalent to redoing 50% of the application.

Given the current Android market share, it's strictly prohibitive to develop for particular screen sizes or anything particular for that matter.

If you are an indie Android developer, here goes my advice. Don't waste your time on all kinds of weird configurations that device manufacturers might come up to - keeping up with that is a losing game.

Reach out to you users and ask them what they want, separate the wheat from the chaff, and create a beautiful user experience for a screen of your choice.

Don't let the fragmentation happen. When they see there's nothing ahead for outdated phones, the device manufacturers will have nothing to do but to accept the developer-friendly rules of the game.

SpringSource Course on Infrastructure Pays Out

noreply@blogger.com (Borys Burnayev) — Tue, 11 Aug 2009 00:50:00 +0000

This is unexpected but logical. SpringSource has been acquired by VMware.

As Rod Johnson mentions in his blog post there are no product overlaps between two companies, which makes the acquisition a conglomeration type of a deal.

On the other hand, if we looked closely at the developments within SpringSource during the past year or so, we would see an accelerating deviation away from the core Java framework business and towards the deployment infrastructure business.

There is a lot of synergy between the companies indeed. In the enterprise, Java is increasingly deployed on virtual infrastructure powered by VMware. An integrated solution seems like a very solid business opportunity and will likely have a significant buy-in in the Java-heavy enterprise.

What's bothering about SpringSource is the stagnating rate of innovation in their core business of Java frameworks. Most of the development on the Java front seems to be shaped around SpringSource's commercial offerings. Valuable projects of general interest like Groovy/Grails Eclipse integration don't seem to get enough resources allocated to drive them to a release fast.

Which leaves us with Google as the innovation leader in the Java space. Not to diminish the role of the search titan, a healthy ecosystem needs many living things to thrive. Another entity will eventually step up and challenge. Who that will be?