Archive for Android

Chrome > Android

chrome-iconAndy Rubin is no longer working on the Android project at Google but, at least for now, is still part of the organization — see his parting email here courtesy of the Wall Street Journal. The good news is that Sundar Pichai is going to be in charge of Android, but the bad news is that he is the head of Chrome / Chrome OS (referring to Chrome and Chrome OS by simply Chrome going forward) and the departments seem to be doing something of a merge; or at the very least the distinct positions of Android head and Chrome head have been merged into one. The question is what does this mean for Android and, more importantly, what does this mean for Android developers and Chrome developers?

First off, let’s face the hard truth about Android it. It is quickly spinning out of Google’s control; one one end Samsung basically has a monopoly on the high end Android device market and on the other there are tons of Asian manufacturers taking Android and slapping it on sub-par devices, further diluting the brand. Chrome, however, is 100% Google. Sure, there is the Chromium open-source project, but guess who sponsors and, for all intents and purposes, controls that? That’s right, Google. Open might be a great marketing term, but let’s be real, it’s a lot easier to monetize an operating system that you control.

Many of you may not necessary agree that Google would be interested in maintaining control of Android, but it is hard to argue that Chrome isn’t  more in line with Google’s goal of a web based world built in HTML and related technologies. It’s called synergy, baby! You don’t need an MBA to see that Android (aka glorified Java) is not exactly in line with an HTML future. If only Google had a web based operating system it could focus on…. As web development technologies continue to evolve and become more capable for developing full featured applications with rich experiences, Android will become increasingly less important to Google.


My guess is that the conversion will start slow. Perhaps Google will start to push Chrome apps for the Android version of Chrome. Maybe in a year, when those rumored Google stores start to show, we’ll see a Chrome for Mobile “developer phone.” Regardless of the conversion starts, my bet is that within the next five years Google will start publically pushing Chrome  as its next generation  operating system. In fact, I think it would move faster, and probably had plans to, but is being thwarted but regions with little or poor connectivity — this is a particular issue in large portions of the United States.

The good news is that, overall, developers stand to do well in this scenario. Android developers have little to fear from Google, since Android is largely beyond Google’s control at this point; if Google ever stopped supporting it, hardware manufacturers, chiefly Samsung, have enough riding on the OS to keep some sort maintenance and development effort going. Google’s focus on Chrome will be a boon for web developers. Sure there was WebOS, a good and severely underrated web focused mobile OS from HP, and there will be FireFox OS, but it’s going to take a bit of muscle that HP and Mozilla didn’t have, in the case of HP, and will never have, in the case of Mozilla.

Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

My Android Christmas Wish

Android developers will know that there are some serious issues of fragmentation on the platform. These issue have been well recorded and, at times, greatly exaggerated. The truth is that in the last year Google has taken great steps toward making the Android development experience more on par with iOS and it could be argued that developing for Android is now as enjoyable as developing for iOS. However, there is still one larger of weakness is the blessed Android development tool chain: a good GUI designer.

Let’s face it — there really aren’t any good GUI designers for relative layouts. Certainly, the one Android developers are provided in Eclipse is a far cry for Apple’s Interface Builder. To be fair, Interface Builder traditionally has not had to deal with relative layouts and there is an element of added complexity in dealing with them. Still, that doesn’t excuse Google’s lackluster tool.

Like many Android developers, I’ve taken to working almost exclusively with layouts by editing the actual XML code. There’s nothing wrong with this, but it can be somewhat tedious when developing a complicated layout, since you have to keep rebuilding your application as you make changes to the layout.

If Google could improve or replace the Android layout tooling, I am confident that we would see more complex and attractive user experience in our Android apps. So, what do you say, Google? Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Crisis Coding: Stop The High-Res Madness

As someone who lives less than five miles from the Atlantic ocean in NJ, I’ve been having a bit of a bad time recently due to  Hurricane Sandy. Luckily, I was not harmed nor were any of my loved ones in the crisis. I did, however, notice something important: even  my non-techie friends and relatives were glued to their smart phones, hoping to hear some news about the storm, find out when their vital services (power / gas) might be restored, or (most importantly) check on their loved ones.

There are plenty of mobile apps that can be very helpful for handling a crisis, however, this recent crisis has shown me that there is something rotten in the state of app development — especially on the iOS side.

Let’s frame the scene a bit. During Sandy battery power was worth more than gold-plated platinum; for those of you unfamiliar with mobile development one of the most battery intense things most apps do is download data — especially image data. Up until today, I was out of power and the only access my fiance and I had to the outside world was out smartphones. Between us we have an iPhone 4S, a Galaxy Nexus, and a Lumia 900. We used all three phones to find pertinent data regarding the crisis.

I noticed some trends for roughly equivalent apps on each platform. The Windows Phone apps tended to load the fastest with the Android apps loading about as fast — I had no tools to do any real benchmarking, so these observations are all anecdotal. Sadly, my iPhone did not perform so well. I wondered why for a few minutes. After all, they were all on  3G  (the LTE Nexus had LTE turned off to conserve power) and the Lumia which was on AT&T should have been at a distinct disadvantage since Sandy had already claimed one of the local AT&T towers.

The difference was not with the network or OS’s or devices. It was about priorities in the apps themselves. While the Android and Windows Phone apps focussed on providing pertinent data in simple text based lists, the iOS apps were constantly trying to download images alongside the data. These images took a long time to load and therefore used an unnecessary amount of battery power. Worse still, after I regained my power earlier today, I reopened the iOS apps in question and they committed what is in my mind a mortal sin of mobile development: they all tried to download ‘retina’ resolution images over 3G.

Ridiculous. I understand that high-res images can make an app look good, but there is no need to download them over the air. Still, if you insist on downloading images that large, then please only do so over wifi. This is especially true if you app is geared toward helping people in a crisis.

The Kindle Fire and Developer Experience

Update Note: This article was first drafted before Amazon announced that there would be a way to purchase your way out of the Kindle Fire lock screen ads.  An effort has been made to remove references to the ads being mandatory.

Amazon made something of a splash this week with three new versions of its Kindle Fire Android tablet. The original Kindle Fire was something on an enigma to me: in a lot of ways it’s a bad product and the only virtues it had was that it was two hundred dollars when the standard tablet price was (and pretty much still is) five hundred dollars and that Amazon had (and still has) a pretty good ecosystem. These new models seem to be aimed at fixing a lot of the issues found in the original; slow reaction times to user interactions, poor scrolling performance, and generally inconsistent / jagged animations. I have not been able to test the (to date, yet to be released tablet) myself but would love to give it a shot first hand; Amazon if you’re out there, call me. Let’s assume that for the sake of argument those performance issues have been resolved in these new models. All of the new Kindle Fire models are reported to have built in OS level ads. That means that ads will be shown on the lockscreen and possibly elsewhere. Any fan of user experience (especially those who appreciate Apple style design / UX will see that as a possible deal breaker. Amazon has just announced that these ads can be removed with a fifteen dollar upcharge.  The issue I would like to discuss is not the built in OS level ads, but rather what impact Amazon has been having on the mobile developer ecosystem: developer experience if you will.

I know that Joe user may not mind seeing a bunch of ads on his lockscreen, but my concerns, as I’ve mentioned before, are more for the ecosystems as a whole rather than for the individual user, though it follows that a deterioration of the an ecosystem would eventually affect even the most casual of users. Apple has managed to change the software industry and commoditize software to the point where even selling an app for $0.99 is challenging. Now with these new devices Amazon aims to build on that by commoditize tablet hardware. In this new world that Apple blazed the trail for and Amazon hopes to push further into content is king, not apps.

Amazon isn’t too shy about this. To their credit, they push the Fires as ‘media tablets’ primarily and are quicker to push their growing video content libraries and large Kindle e-book library. Additionally, they’ve done some good things for app developers in the past: they offer effective DRM for the piracy concerned, a great infrastructure for app backends for app developers to connect their apps to, and the offer powerful in app purchase API’s. However, they also done some harm: they’ve followed Apple’s lead regarding commoditizing apps and their ‘free app of the day’ promotion is not as good for developers as you might think. Worse still, in discussions with ‘normal’ Kindle Fire users (original) I know, it has become clear that Amazon is seen as the place to get free apps, not pay for quality software.

On the other hand the Amazon App Store has proven to be the better market for Android developers to generate revenue when compared with Google Play. Does revenue trump all? I don’t know, but it would seem that Amazon is in no rush to end the race to the bottom on app prcing.

Questions comments? Find me on Google+ or Twitter

Smart Client / Dumb Server?

These last few weeks I have been writing here and posting elsewhere about Parse, a service that stands up a simple backend for mobile application developers to connect to their apps. There are lot of good things that can be said about Parse. Unfortunately, it is based on a sub-optimal development model: dumb server / smart client. For the purposes of this article I am defining this development model as putting all or most of the validation on the client and reducing the server to little more than a thin layer over the database. Some of my more experienced readers will have their own ideas as to why this development model is sub-optimal, but for the rest of you I am going to go through the two that I see as the most important / relevant for today’s mobile development landscape: inherit functional limitations and slowed update cycles.


Parse does a great job and is a joy to work with, as long as you are doing what it was designed to do: authenticate users and store some data. For instance, try to pull a random object from your Parse data store but ensure that you get the same object on every client while making only one network request per client; hint: it is not currently possible to do with one network request and you will have to make at least two. In my experience, the best network request is the one that was never made. Once you send data over the air, the integrity of your user experience is out of your control and we all know how unreliable 3G can be. Getting a little more specific to Parse, you are currently placed into a higher pricing tier if you make over a certain number of requests to Parse.


Let’s be real here. If we are talking about mobile development projects, then we are most likely talking about iOS. Unfortunately, getting an update to your iOS app approved can take weeks and the situation doesn’t look to be changing soon: Windows 8 RT is adopting a similar review model and Android developers who target Amazon’s app store are subject to a similar review period as well. That’s bad enough taken alone, but consider that most software has bugs and that there is a correlation between the complexity of the code and the number of bugs in that code; that is why we try to follow KISS (keep it simple stupid). Given that, there is a clear incentive to keep the code on the client as simple / elegant as possible. However, running a dumb server and forcing validation on the client prevents that in most cases; your client code will have to take on most of the validations that the backend code would have had, thus making it that much more complex. Imagine a bug that you can’t get a patch out for in less than twenty days but worse still you can’t guarantee that all of your users will update as soon as possible or even at all. With a real backend API you could make the fix and the bug would be taken care of for all users in most cases.


These are real risks and either of them can derail your project. Should you just avoid these type of things wholesale? Maybe… but there is certainly an argument to made for extremely low budget projects or prototypes.  Let me know what you think on Twitter or Google+. Also, if you have not already, pick up your copy of Code Journal today either from the Mac App Store or direct.

A Look at PFQuery

Querying data is a pretty common task for most if not all mobile apps. iOS and Android have made the work pretty easier for developers, but Parse has thrown their hat into the ring to make it even easier for developers who choose to use their development tools and backend system; yes, I know this sounds a little like a commercial, but I am genuinely excited about this functionality and no I have no business or personal relationships with Parse or anyone therein.

PFQuery is a simple class that, as its name suggests, allows you to query your Parse dataset and getting data returned based on certain criteria. No need to stand on ceremony, let’s take a look at some code:

- (void) someMagicalFunction {
	PFQuery* query = [PFQuery queryWithClassName:@"SomeClass"];
	[query whereKey:@"SomeProperty" equalTo:@"MagicString"];
	[query findObjectsInBackgroundWithBlock:^(NSArray* objects, NSError* error) {
		// do something with the objects


And now for you Android fans:

void someMagicalFunction() {
	ParseQuery query = new ParseQuery("SomeClass");
	query.whereEqualTo("SomeProperty", "MagicString"
	query.findInBackground(new FindCallback() {
		public void done(List< ParseObject >objects, ParseException e) {
		// do something with objects

Yup, that’s it. It really is that simple. If you want to know more take a look at the Parse docs. For those of you that are critical of Parse, I will be doing more than just code samples with it; in fact I have found a few deficiencies that I will be discussing in a future blog post.

Phonegap the Bad and the Ugly

Times are tough and development budgets seem to be getting smaller and smaller, assuming that you are not Draw Something or Instagram. My experience has been that clients who are interested in supporting both Android and iOS do not generally want to develop two native applications. The reasons are obvious: cost and time.  So the conversation tends to turn to cross platform solutions. Currently, there are two types of cross platform mobile solutions for non-games: web based ones and Mono. I am currently doing a little work in Mono for Android and will write about that at a later date.

The most obvious web based solution is probably Phonegap. Phonegap has been around for a while and allows developers who have HTML/CSS/JS skills to leverage those to develop rich cross platform mobile apps. That’s all true. However, there are a few issues with Phonegap: it is not a mature platform, is a huge dependency, and is nowhere near as performant as native code.

This will probably be the most inflammatory issue I have with Phonegap, but I stand by it. Phonegap is not mature and it shows. A lot of the more complex and useful functionality comes from community plugins. However, the platform has to date been in such a state of flux, that you are likely to find that many plugins don’t work or at least don’t work without some form of modification on the most recent version of the platform. This may seem like a relatively small issue but if you look at it in terms of developer efficiency, then it becomes a bit more serious; do you want to be hunting down the right version of the right plugin for your version of Phonegap?

Dependencies are a necessary evil on any project and plugins are dependencies. Even if you are developing a native app you are taking a dependency on at least a language and one or more frameworks. Using a tool like Phonegap adds a big dependency on Phonegap itself which also depends on those native dependencies you were trying to avoid. Worse still, since the Phonegap must interact with Cocoa Touch or Android, there is a chance that you will have “mystery meat crashes” on one or both platforms. One example on iOS is that Phonegap does not do a great job with memory management, so your choices are use ARC (only recently an option), dropdown to Objective-C and write some “release” statements, or run the risk of seemingly random crashes in the wild.  Another issue with such a large dependency that depends on one or more distinct dependencies is that you end up with the lowest common denominator between all platforms. For example, there is no iCloud support in Phonegap nor is there Newsstand support. Someone could write a plugin for these but those would be yet another dependency in your app and any changes to Phonegap or worse Newstand or iCloud could break your plugin.

It is unlikely that you will be developing the next Infinity Blade, but performance still matters even outside of the games space. Phonegap is not as fast as a native app. It can’t be. Normally, this isn’t a huge issue for most apps but it is important to consider during the planning stages of your app especially if you want to use the camera or have a flashier UI; the camera is noticeably slower in Phonegap. As always, your app’s tolerance for the performance hit will depend a lot on the spec, but it is something to keep in mind.

Having said all that, there are cases in which Phonegap is a good choice. If budget is a huge issue, cross platform is a must on day one, the app will be pretty plain, and performance is not a chief requirement. As always, you need to pick the right tool for the right job, but remember there are no silver bullets. Questions? Comments? Rage? Find me on Twitter or Google+.

Programming Pitfalls: Android Keystore Files

Programming Pitfalls is a series that aims to help new and seasoned developers avoid common and at times terribly painful programming errors and other missteps.

Ever submit an Android app to the Market… er I mean Play Store? If you haven’t I hope you do (mobile development is a lot of fun), but if you have do you remember that .keystore file Eclipse had you make? You don’t? Well, you’re in trouble. If you don’t find that file you will never be able to update your app. Poor design on Google’s part? That argument could be made, but the point of the system is to ensure that no one, other than you,  can submit an update to your app; imagine what would happen to mobile security if a malicious entity were able to submit a virus laden update to Angry Birds?

My recommendation is that you back up you key to a remote service, such as Dropbox or even GMAIL works. Just make sure that it is something that is in the cloud and have mutiple copies of your keystore in multiple places.

Hope this saves you some pain in the future.

A Month in Eclipse

As anyone who reads this regularly will know, I spend most of working day in XCode developing for Apple’s iOS and OS X platforms. However, I have had a long affinity for Java and am a fan of the Android operating system; I have a number Android devices including the fantastic Galaxy Nexus and the much less awesome Kindle Fire (more on those in another post) and have done some Android development both as a hobby and on a professional basis.

When I first decided to jump into Android I resisted Eclipse pretty strongly and ended up on IntelliJ. Things were going pretty well for a while. The code completion was nice and fast and the IDE had enough hooks into the Android tooling that I didn’t feel like I was at an efficiency disadvantage compared to Eclipse developers.

That all changed when  a friend gave a me a look at the built in user interface builder that had recently been added to Eclipse. Interface Builder is something that I sorely missed in my Android tool-chain and up until then I had been using DroidDraw to fill the gap. That was a passable solution, but I still needed to spend a good deal of time editing layouts in XML and eventually I ended up just coding all of them by hand; this felt inefficient, so I caved.

I downloaded the latest version of Eclipse, read some docs regarding the IDE’s Android specific functionality, and abandoned my trusty IntelliJ. Right off the bat I was disappointed in the layout tool. It is no Interface Builder and I still felt that working with the raw XML was easier than working with the tooling.

Still, I soldiered on for about a month and tried to get into the Eclipse mindset. More and more I became increasingly frustrated with Eclipse. One of the biggest issues that plagued me was the inconsistent code completion / suggestion;  most of the time the tool didn’t make any suggestions until after I had finished typing a line of code. I am not sure if this is to do with the Eclipse ‘content assistance’  engine, since the IDE was running pretty slow overall on my machine; I was running a 2011 Macbook Pro with an i7 and 8 gigs of RAM, which one would think would be more than adequate for running an IDE. I have been told but have not been able to confirm that these performance issues do not exist on Windows, so take that for what it is worth.

Of course, there are some things that I really like about Eclipse. To start, it is a great example of an extremely successful open-source project. I love that it is highly extensible and that additional functionality can be added at no cost; one of the reason that I wanted to evaluate Eclipse is that some of the additional functionality I wanted in IntelliJ requires the paid version. Eclipse make the Android Market submission process a matter of clicking through some simple wizards; on IntelliJ, I have to drop to Terminal and do the signing from there, which can be a little confusing the first few times that you do it and is not nearly as efficient as simply clicking a button. On the same line, Eclipse seems to keep track of your signing keys for you, however, it does not back them up, so be sure that you do that; if you are unlucky enough to lose the key that you signed a Market app with, then you will quickly find that you cannot update your app at all. Period. Probably my favorite aspect of working with Eclipse is the community. There are tons of tutorials and every community member that I have contacted in IRC  has been more than gracious in helping me get productive with the tool.

At the end of the day efficiency is what really matters to me, so I am going to revert back to using IntelliJ and I am going to be evaluating purchasing the commercial version of the product; stay tuned for a post on that in the coming month or so. Also, if you are interested in developing on Android and do not have your tool-chain set up yet, I recommend that you give Eclipse a look; this goes double if you are new to developing software or the Android platform, since most of the tutorials for Android assume that you are using Eclipse.

If you have feedback, drop me a line on Twitter (@dominucco) or Google+.

Kindle a Kindle Fire?

I’ve been playing with my new Kindle Fire for a little while and I have to admit that I was really excited about the device. My excitement tapered off after I opened the box and was immediately prompted that an update was required. Still, that is not too bad and I’ve come expect, though I stand by the assertion that it is a terrible user experience, that pretty anytime I buy something new that has network connectivity I will be required to sit through an update or patch of some kind.

Ok so I was finally able to use my new Kindle Fire after the update, so the first thing I did was poke around the main screen and settings. Once satisfied with that, I decided it was time to take a look at what I could with the device. I started by doing some reading in the built in Kindle app, which was good, but nothing spectacular. I then took a look at streaming my Amazon Prime content to the device. Again, it worked very well and just as expected but didn’t bring anything new to the experience.

Finally, I decided to take a look at the Amazon App Store on the device. This the worst part of the experience for me. I could not find really anything unique for the device that was worthwhile; if you know of a good Kindle Fire apps please let me know, particularly if it is an SSH terminal. To be fair, it is hard to blame Amazon for the lack of good Kindle Fire apps at launch. For starters, it has been out for one day and it takes time to develop an ecosystem. Additionally, I have to empathize with developers who decided to not focus on the Fire, given how cagey Amazon has been about actually committing to Android; there are also rumors about Amazon purchasing Web OS and using it for future versions of the tablet.

I don’t want to sound too negative and I do intend to not only use the device but also develop apps specifically tailored to it This is still the very beginning of the Kindle Fire and I am holding out hope that the app ecosystem will improve. As long as Amazon remembers that its developer ecosystem is at least as important as its content ecosystem, the Fire could be to the iPad as the IBM PC was to the Apple II.