Tag 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.

Ubuntu Phone OS: Initial Thoughts

ubuntu-logoLooks like Canonical is serious about making 2013 a big year for the Ubuntu project. As I am sure you are aware, Canonical revealed the Ubuntu Phone OS earlier this week. Unfortunately, like most Linux enthusiast, I have not been able get my dirty little mitts on a device running the new operating system but have been reading everything that Canonical and other sources have written about it. I really would love an Ubuntu-based phone, but have some serious misgivings about the OS: Canonical  doesn’t have carrier relationships, the mobile market is maturing, and you can’t buy an Ubuntu Phone today.

Carriers are incredibly powerful in the mobile space and it is more than a little difficult to release a product without their approval and cooperation. To date, Canonical has no public relationship with any carrier and has never released any sort of device that uses cellular technology*. If you know the history of the iPhone and Apple’s interactions with the major US carriers to get the original iPhone on the market, then you know how difficult dealing with them can be. The telcos are old companies and they run their business in a very old school manner, basing a lot of what they do on relationships.

For the sake of argument, let’s say that Canonical can get a good carrier relationship to the point where the carrier actually promotes and pushes the Ubuntu Phone; make no mistake here — the carriers do push certain phones over others in the stores via ‘sales incentives’. The last time a carrier really stood behind one platform was a huge success for the platform — the platform was Android and the campaign was Verizon’s ‘Droid’ campaign. It’s fair to say that Verizon made Android a household name and can be credited with a lot of the platforms early success, but would they do it again? Would any carrier when they can just work with any of the hundreds of Android manufactures and get a platform they know they can sell? It is widely held that the ‘Droid’ campaign was designed to compete directly with the iPhone, an AT&T exclusive at the time. The market today is different, however, and if the carriers want to push handsets other than the iPhone (perhaps because they can strike a better financial arrangement with a different manufacturer than Apple), they already have the Android powerhouse and the Windows 8 darkhouse. The market is matured and there isn’t just one platform anymore. Worse still for Canonical (and Microsoft but more on that later), a lot of everyday users have spent a lot of money on apps for Android and iOS. I believe that this creates something of a platform lock in scenario that most consumers would be unwilling to move from one platform to another, because they have purchased apps and other content that cannot be moved between platforms.

It’s 2013. You can’t make a huge mobile announcement and not actually have anything consumers can buy, but that’s just what Canonical did. Of course, they will get a lot of Ubuntu fans (myself included) installing the OS on a spare Nexus but, for the mass market, they have just squandered the excitement that the market displays around a new platform launch. Worse still, they have not announced any retail partners. The sad truth is ‘normals’ (non-geeks) buy their devices in carrier retail stores or other outlets. If the Ubuntu Phone does not have a retail presence, then, for a huge market segment, it might as well not exist.

This article has been focussed on showing the issues with an Ubuntu Phone. That does not mean that I am not an Ubuntu fan. In fact, I would it to do well, since more competition in the space is good for developers and the market as a whole. Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

 

*UPDATE: Thanks to Arthur for pointing out that they did in fact release a netbook running Ubuntu in cooperation with Vodafone. However, they have never released a phone with carrier support.

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.

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.

Bad Synchronous Call! Bad!

Back in the dark old days of Commodore 64 and its brethren computers were pretty much all synchronous; instructions executed one after the other, one at a time. It was a simpler time. Users did expect a responsive UI during slow operations or so I have been told. Wondering what a slow operation is? Well, how about any sort of IO? or large data transfer? or how about just pretty much any data transfer over 3G? Of course, there are other cases of long operations but no need to open old wounds….

Now I can hear you already, arguing ‘the platforms today are so much more multi-threaded / multi-core by default I don’t have to worry about writing asynchronous code.’ Well sir (or madam), you are dead wrong. It is true that or more modern platforms have done a lot to run their internal operations in a thread safe / optimized way, but there are a lot of cases where YOU MUST make your code asynchronous. The platform is not going to waive a magic wand and make your operation run asynchronously. Need an example? Here you go:

UIImage* image = [UIImage imageWithData:[NSData dataWithContentsOfURL:someURL]];

Looks reasonable, no? Wrong! That code though deceptively simple is actually very bad. Let’s take a look at what is actually happening in this little one liner:

NSData* imageData = [NSData dataWithContentsOfURL:someURL];
image = [UIImage imageWithData:imageData];

Still pretty simple, right? That’s the exact same functionality as the one linear above and the same problem. Take a closer look at that first line. Pretty simple, right? All it is doing is reading the contents of a URL (in this case an image) downloading the data, and creating an NSData object from it. See the problem yet? That is all happening in order synchronously. If the network is slow or the server is slow to return, the UI on your lovely app will lock for a second or so. Bad UX. Very bad. It is important to note that this code is using one of the most direct ways to create an image from an external service provided wholly by Cocoa. Not to hit this too hard, but the platform vendor’s framework (Cocoa in this case) is not doing anything magical to prevent this from happening. Your code is causing the problem and you have to fix it — yourself.

Oh? You actually want to see a correct version of this code? Well, ok. What needs to happen here is that the image needs to be dealt with asynchronously. I like to use the popular (albeit somewhat dated) iOS / Mac library ASIHTTP to accomplish this. For one request it is really easy:

ASIHTTPRequest* request = [ASIHTTPRequest requestWithURL:someURL];
__weak ASIHTTPRequest* _request = request;
[request setCompletionBlock: ^{
UIImage* image = [UIImage imageWithData:[_request responseData]];
}];
[request setFailedBlock: ^{
// handle failure
}];
[request startAsynchronous];

Not too bad, right? Just a quick walkthrough. If you are new to Cocoa you might not be familiar with the concept of blocks. It’s a pretty big topic and worthy of its own post (or series of posts) but they are similar to closures in other languages. Also, the “__weak” is to prevent a retain cycle for developers using ARC; if you are not using ARC in your new iOS or Mac OS X projects, consider it. Ok so what if you have to deal with a large number of images for something like a UITableView full images? Well check this out:

ASINetworkQueue* q = [[ASINetworkQueue alloc] init];
[q setDelegate:self];
[q setQueueDidFinishSelector:@selector(networkQueueDidFinish:)];
[q setRequestDidFailSelector:@selector(requestDidFail:)];
[q setRequestDidFinishSelector:@selector(requestDidFinish:)];
for (int i = 0; [someArrayOfImagesURLS count]; i++) {
ASIHTTPRequest* imageRequest = [ASIHTTPRequest requestWithURL:[someArrayOfImagesURLS count]];
[q addOperation:imageRequest];
}
[q go];

// delegate methods
- (void) requestDidFail:(ASIHTTPRequest *)request {
// something bad happened -- handle it!
}

- (void) requestDidFinish:(ASIHTTPRequest *)request {
UIImage* image = [UIImage imageWithData:[request responseData]];
// do something with the image
}

- (void) networkQueueDidFinish:(ASINetworkQueue *)q {
// do something magical when the queue is done
}

Ok so all that has changed is that we iterate through an array or URLS for the images, create ASIHTTPRequests based on them, add them to our operation queue, and deal with the delegate methods. One thing of note is that there are separate callbacks for when each individual request finishes and for the queue itself and if you fail to implement one of those required delegate methods your app will crash.

Hope this helps someone. I am going to be posting more about writing asynchronous code to best take advantage of the multi-threaded / multi-core nature of our favorite platforms. Stay tuned for a look at this type of thing on Android! Find me on Google+ or Twitter if you have feedback.


WWDC 2012 Keynote Let Down

Earlier today I hosted Coder Radio with Chris Fisher of Jupiter Broadcasting and in the episode we discussed my reactions as a developer to the WWDC keynote this year (2012). First things first. I did not attend WWDC nor have I installed the iOS 6.0 developer release, so some of my information may be incomplete; I have to do this in this way due to Apple’s developer NDA. You can listen to the show to hear what I didn’t like, but I’d rather go through a few things that I would like to have seen that to my knowledge aren’t coming.

Inter-app Communications
This is by far my largest pet peeve with iOS development and using iOS. Why isn’t there are robust way for apps to work together and share data; within reason of course. Android has a version this in the form of “intents” and Windows Phone 7 has a incredibly powerful system called “contracts”. This really gets to me when I consider that iOS is a BSD system yet does not adhere to the UNIX philosophy of allowing many small applications to work together to do big things; yes, I know that iOS apps tend to be smaller in scope than their desktop counterparts but to date there is no real way for them to work together. There is so much functionality that cannot easily be done on iOS due to this restriction.

Widgets
On my Android and Windows phone I can glance at the screen and get the latest tweets, view other data (such as a stock ticker), and play a song, or begin or pause listening to an audiobook. On iOS, almost all of those things require me to launch separate apps. That’s silly not to mention a bad user experience. I know there are definitely battery life concerns if you have too many widgets open, but there is no reason that Apple can’t add some sort of restricted mode for simple widgets to run in.

Siri integration
Ever since I got my hands on my 4S I have been waiting for a full Siri API. Apple has been working on it, but to date there is no fully functional Siri API for third party developers. This is understandable given how often Siri simply does not work but it is still a shame.

That’s all for now. Now I can finally take a look at the dev preview! For feedback please find me on Google+ or Twitter.

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.

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.