iPhone vs Android vs webOS from a developers point of view

I’ve been fortunate to have developed apps in the last year for the iPhone, Android, and Palm Pre, and on a few occasions been asked to compare the platforms.  So without further ado … comparing these platforms from a developers point of view.

Android

Android

Programming ease – B+
Although Java is one of my least experienced languages;  it’s also one of the most intuitive for me.  Not having to deal with garbage collection and nasty memory management bugs definitely gives Android a leg up in programming ease over iPhone.  I find the application model (intents, and activities) about as natural as the iPhone, which is to say, fairly intuitive.
One big downside is supporting multiple devices and operating systems.  I’ve spent countless hours trying to debug device or OS specific bugs.

Documentation – B+
A strong developer community provides some fairly solid support.  Blogs, text books also exist for those looking for these resources.  However, I don’t find the library documentation that Google provides or the developer site very rich.  Not nearly as rich as the apple documentation.

Tools – C+
Development tools aren’t great; although I don’t think their “horrendous” as Joe Hewitt famously says.   An eclipse plugin is fairly mature now, the debugger works well, the emulator works well.

Market – B+
There’s a hungry (and growing) market of Android users.  One downside as admob has reported is that they seem less inclined to pay for apps compared to those on iPhone … due largely to the free precedent google has set.
Getting your app to market is much easier as well.  Getting an app published is a matter of posting the app, as opposed to the hoops Apple has you jump through.

iPhone

iPhone
Programming ease – C+
I actually really love objective C.  It’s a very elegant language.  But compared to the other players, I think it requires much higher learning curve.  This probably has a lot to do with it’s lack of memory management.  I also find the separation of  UI (Interface Builder) and application (XCode) particularly obtrusive.

Documentation – A
Apples reference guides, tutorials and texts are incredibly rich.  Furthermore the hordes of iPhone developers have contributed a wealth of information available online.

Tools – A+
The iPhone SDK and XCode IDE is awesome!  Great debugging tools, NSZombie, instruments, integration with source code, etc.  are heads and tails above any other toolset.

Market – B
It goes without saying that *a few* people have heard of the app store.  However, throwing the app into the store can sometimes be like a raindrop in the ocean.  It’s tough to get exposure for your app.

webOS

Palm Pre webOS
Programming ease – A
Anyone with a bit of web dev experience will LOVE webOS programming.  I had a bit of Rails experience and with this, programming for the Palm Pre was a breeze.  Familiar Model view controller paradigm using Javascript, HTML, and CSS, makes things natural and quick.
Documentation – C
Documentation is pretty week for webOS.  A lack of community resources, inferior reference material from Palm, can make things pretty hard to troubleshoot.
Tools – D +
If you think the android tools are bad … you’ll think the webOS tools are despicable.  Maybe things have improved, but my last project required a gdb command debugger and hundreds of log statements to get any debugging done.  The emulator lacks many of the on device libraries.  A big fail here for developing with webOS.

Market – B
I could make an argument that if you’re a small shop looking to release an app, you should do so in the webOS catalog.  No, if you’ve got a winning app, you’ll never get as many users as you would on the iPhone.  But … webOS users are HUNGRY for apps and willing to try anything.

The winner?

I can’t really say there’s any clear winner and think it’d obviously depend on what expectation you had for your app.  But for the sake of the argument I’ll give ya 2 winners.

If I was releasing an app which I knew was able to get some exposure, I’d probably suck up the learning curve and release it on the iPhone.  The iPhone truly is the leading device, it’s beautiful, it has the market share, and users are willing to download (and pay) for apps.

But if I was building an app that I felt was gonna have a hard time getting much exposure, I’d actually consider building it for webOS and hope HP revs up the community.  It’d take half the time, and while there aren’t many of them, webOS users have proved to be hungry, willing and able to try out new apps, and pay for them.

iPad far from a living room device

Apple released the iPad as a device aimed at the living room.  I agreed with this position and fully expected to use the device while sitting on the sofa, casually watching TV, to check email, Facebook, surf the web etc.  However … I actually have found that I reach for my iPhone when I’m in these situations.

Why?  I think it’s actually pretty simple (and perhaps lazy).  I’d rather grab a device that I can operate using one hand.  The iPad is a 2 hand device, and for something as simple as checking email, twitter, or Facebook, I’ll simply grab my phone.  For doing any surfing that’s more involved … such as online shopping … I’ll grab the laptop.  It’s just too painful to type anything more than 2 sentences on the iPad.
In all honesty, the only place the iPad’s taken over for me is inside an airplane.

Another hurdle for Edmonton Startups?

My frustrations with working in technology, but more specifically, starting a tech company in Edmonton are well documented.  Since writing my original “Why Edmonton is Deadmonton for Startups” blog post 3 years ago, I’ve met several really impressive technology influencers, founders, venture partners, and technologists in Edmonton.  Furthermore, I think the city has been making  strides towards a better tech scene, and companies like Empire Ave have been succeeding despite their location … but I believe these are outliers and looking back, my original points really resonate for me.

I still find myself frustrated at times and reflecting on what might be lacking.  On this note, pointing out that a region requires an attractive lifestyle for it to become a tech hotbed is nothing new.  But this point really hit home while socializing at Startup event in Vancouver several months ago.  After spending 2 days at the event I realized I hadn’t met a single native Vancouver resident.  Every person had migrated to the area in search of a better lifestyle … not just for a better job in tech.

Tech Entrepreneurs share this “do it yourself/break the mold/never settle for less” characteristic.  This attitude exists at every level of their lives.  Work, social, family, and pleasure.  The type of people proactively striving to expand and improve their standard of living by moving closer to the ocean, closer to skiing, closer to ethnic diversity, closer to the arts, etc. are typically the same type of people taking initiative to improve their 9-5 work life by starting their own work ventures.  Seattle, the Bay area, Boulder, Boston, New York, Vancouver … these are all cities that young, energetic, creative, *won’t settle for less*, curious, and innovative people seeking a better lifestyle, amenities, more diversity, and natural beauty move to.  Not only do these people share this value, but they also transfer it to their children, and to the communities they inhabit.   These people initially may not move with the intention of starting a company, but their values lead them in this direction or spread to their children and their communities, which in most cases is more valuable than starting a company themselves.

With exceptions, Edmonton in recent years, has attracted young men from across Canada in search of riches that a job on the oilfields would bring.  Completely opposite from San Francisco, Seattle or Vancouver, I’ve yet to meet someone who moved to Edmonton because they were looking to improve their life quality via the city’s amenities, natural beauty, diversity, or creative energy … all areas I think Edmonton is weak.

There will always be outliers in Edmonton like the impressive people leading Empire Ave, Seek your Own Proof, Nexopia, and Start Up Edmonton.  As mentioned before,  I’ve been incredibly impressed after meeting or working with many of the people working and leading these groups.  They’re all great people, and great technologists / founders / leaders.  But until Edmonton is seen as an attractive place for young energetic, creative and driven people, it will never reach a critical mass of these types of people required to become a tech hotbed.  Until then, I recon, it’ll continue to grow and attract the nations finest oil workers; and export it’s talent to Vancouver, and the US.

Flurry keynote at iPaddevcamp

I had a chance to attend ipaddevcamp last weekend at the Paypal offices in San Jose.  Great event, some great keynotes, and some amazing people in attendance.ipaddevcamp

One of the speeches that really stood out for me was the one given by Flurry / Pinch media.  In short, Flurry (who merged with Pinch media this year) helps gather usage metrics for application developers.  As such, they’re swimming in data which shows how and what users are using their iPads and iPhones for.

Flury presented some pretty interesting usage metrics.  Most of it which aren’t that surprising.
– iPad sessions are on average 2~3X as long as those on the iPhone
– iPad game, video and book sessions are about 10X as long as those on the iPhone
– iPad book sessions average about an hour.  (I was a bit surprised it was that long)

One stat that was a bit of a surprise to me was that social app usage on the iPad was far less than on the iPhone.  They attributed this to the lack of social apps on the iPad.   But I have to disagree with this explanation.  I think social apps are all about quick interactions consuming or producing content. Quickly check twitter while you’re waiting in line.  Check into gowalla when you enter starbucks.  Look at your facebook stream while you’re waiting for the light to turn green, upload a photo to flickr that you just shot.  The iPhone is perfect for this type of quick consumption and generation of content.

So I think Steve Job’s was right that there’s a market for a device situated between the mobile device and your laptop.  It’s all about the hour you have to kill while sitting in the airport, sitting on the sofa as opposed to the 10 second interaction perfect for the iPhone and the 4 hours you have with you laptop.  The iPad has it’s flaws, but to me the tablet fills this hole perfectly … and Flurry’s analytics seem to reinforce this.

EAVB_GYIQHNMYSY

Why I love my iPad

Yes, I’m a bit of a tech gadget geek.  I own way too many toys for my own good, But  99% of the time I don’t think the hype lives up to my latest toy.

Despite it’s ridiculous and never ending hype, my iPad has exceeded my expectations.

It’s not the Version 1 of the iPad … but it’s the computing shift that it so obviously represents.  The iPad has it’s short comings – a keyboard that’s still only about 30% as effective as a real one … limited multi tasking … just to name a few.  But these are minor notes … and are gonna be washed away in future hardware and software updates.

What do I really like about it?

1.  Limited device, all your apps and data

It’s been several years since we’ve been talking about dumbed down devices that connect to your media and applications hosted in the cloud.  I was reminded today that we were looking at doing this 4 years ago at Saflink with the miValet project.  But the iPad is the first device that really nails this.  It’s a limited device (crummy CPU, memory and hard drive space), but it gives you access to apps and content hosted from the cloud.  The iPhone was a step in this direction too, but lacked the screen real estate to really allow you to consume your content.

2.  Usable multi touch

While multi touch has been around since the iPhone, it’s finally usable with the iPad.  The set of supported gestures is rich, given the extra space.  Not only can an individual manipulate the interface, but multiple people can interact on the device at the same time.
3.  Intuitive interaction using multi touch

To me this is the big one.  I often forget what a barrier the mouse is between a user and the computer.  We’re accustomed to it, but when you think about it, it’s a completely unnatural medium between you and the machine.  Try to teach someone who’s never seen a computer (good luck with that) how to use a mouse and you’ll see how bizarre the mouse is.  On the contrary, manipulating the user interface using touch and gesture is just so natural.  Treating objects in the UI as if they were real objects just makes sense.  Flip pages in books by … flipping pages in a book.  Steer the racing car by … steering the iPad …. sign your name on a document by … signing your name on the document with your finger.  The list goes on and on.  I was reminded of how natural the interface is when my friends 4 year old got a hold of my iPad.  Sure … kids these days … even 4 year olds are pretty good with a computer …. but I was amazed how quickly he picked up using the iPad.

OK … I’m done my apple fan-boy-ism …. I swear I’m not a fan-boy, but this device is awesome.

could not find any SCM named `git’

Attempting to deploy code to my hostingrails account configured with Git and FastCGI, I ran into the following error when running cap deploy:check

could not find any SCM named `git’

This message was particularly confusing as I had access to git from both my remote hosting rails machine and my local machine.

The resolution was to upgrade my Mac OSX version of capistrano from 2.0 to 2.5 via gem update capistrano

That got me up and running … although still has me a bit puzzled about the previous error.

const vs. readonly in C#

In c# what the hell is the difference between const and readonly?  I looked this up today and:

Here’s what I found.

Constants (const):

  • Are slightly less expensive to evealuate
  • Are static by default
  • Can be declared inside functions
  • Have gotta have compile time value
  • Are set at compile time inside assemblies that use them

Readonly (readonly) instance fields:

  • Must have set value by the time constructor exits
  • Are evaluated when instance is created

So I tend to use readonly fields if I ever think the constant will be referenced outside of my assembly.  Otherwise I’ll take the microsecond and use a const.

C# WebBrowser swallows redirect uri

Using an embedded C# WebBrowser, we developed a Linkedin Oauth login library which would allow a user to receive an oauth access token.  We set the callback uri to something specific to our app – “myapp://success”  Within the WebBrowser_Navigating event, we’d look at the uri.  If it included “myapp://success” we were able to extract the access token from the query params.  However, this technique breaks down in a few scenarios:

1.  Using a Winform browser, the redirected uri was never sent as event arguments if the URI wasn’t http://, or mailto or other special cases.  This meant that we had to use a WPF browser which requires a bunch of overhead libraries to be loaded when all we really need is a winform.

2.  Previous versions of Internet explorer do not honor  passing the redirected uri to the WebBrowser control if the uri doesn’t actually exist.  So in other words, because the system didn’t know how to handle linkedin:// uri’s the browser would never redirect to that uri.

To solve the problem I tried to register a NOP callback in the registry to handle this URI scheme:

Register a NOP command line for the liconnect scheme in the registry as a URL scheme (i.e. a command line program that does nothing).

http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.createsink.aspx

The webbrowser still didn’t honor passing the URI scheme to the navigating or even the navigated event.  The URI being navigated to must actually exist for the Webbrowser to actually pass it to the event.

So, to solve it:

We set the callback URI to a URI that we own.  ie.  “http://mydomain.com”

This way, we’re able to intercept the callback when we see this uri in the navigated event.  I’m not thrilled with this solution since it relies on a server.  You could just as easily redirect to http://linkedin.com or some other known domain, but it still leaves your client code dependent on a server.

I’ve uploaded the most recent code to the original linkedin thread.

“shhhh don’t tell anyone; it’s a winning idea”

I was out for drinks a couple nights ago with a friend who had a “winning idea” that he wouldn’t share with anyone in the room.  I can only imagine that he feared someone scooping his idea.

Much like that evening, whenever I see someone guarding their idea like it was their first born, I can’t help but think they’re going to spill the beans within minutes.  Of course though, they’ll make you swear until you’re blue in the face that you won’t tell a living soul.

In my mind, this person, or anyone who has a “winning idea” has failed already. Ive met enough “ideas people” to know that ideas are worthless; the value lies in the execution of the idea.  So if there’s anything you should fortify, it’s the execution of the idea, not the idea itself.  Better a mediocre idea brilliantly executed than a brilliant idea with a mediocre execution.

Linkedin oAuth desktop c# sample embedded webBrowser

I’ve created and uploaded some sample code for using Linkedin’s oauth library in a c# desktop app.  Faith Yasar’s c# code was my starting point.  A bit of a refactor of the oAuth librarie to include the oauth_callback parameter was needed, as well as code for displaying the login dialog.

Code can be found here in a forum post I made on linkedin.

The code contained includes a test harness as well as the oauth libraries for oauth login dance and Linkein API requests.  Oauth login is handled with an embedded webBrowser which is shown modally for the user to login.  Upon login completion, dialog will be closed and the token and verifier will be available from the dialogs property.

To use the code, simply Add your Linkedin consumer secret and Consumer key to the OauthLinkedIn.cs file:

private string _consumerKey = "ENTER_YOUR_CONSUMER_KEY";
private string _consumerSecret = "ENTER_YOUR_CONSUMER_SCRET";

Then you can make api calls following a few steps:

OAuthLinkedIn _oauth = new OAuthLinkedIn();
String requestToken = _oauth.getRequestToken();
_oauth.authorizeToken();
String accessToken = _oauth.getAccessToken();</div>

Hope that helps