Antonio Licon's blog

iPhone vs Everyone Else: The Apps Trap

My First (not so) Smartphone
A couple of years ago, I bought the Blackberry Storm 9530 (the first one). It was ok, even snappy... until I downloaded more than 2 apps on it. Apparently it wasn’t designed to hold very many apps (like 3, boo).

Let’s Go Shopping!
I’ll spare you the laundry list of problems with my Blackberry. The point is, I have been making due with this neglected stepchild of RIM’s for over 2 years. I have been uncharacteristically restrained and fiscally responsible. And now I am due for a phone upgrade! Lucky for me, the Droid Bionic, and possibly the Samsung Galaxy S2 will be out shortly (rumor has it, August/September).

But If You Don’t Have An iPhone...
But some would say I should wait for the iPhone 5. After all, Apple’s “App Store” has over 500,000 apps in it. But what does that mean? Am I going to download 500,000 apps? Probably not.

What’s In An App?
So what is important about these apps then? 500k is an impressive number, but less impressive without context. How many USEFUL apps are available? I don’t have need for 300 apps that make fart noises. How many of these apps are “I gotta have this, can’t live without it” good?

And if I went with an Android device, how many of these apps would I have to do without? So far, my experience has been that all the best app developers publish for Android at the same time, or very near at the same time as iOS. Rare indeed are apps I would call truly useful that exist only on one of these platforms.

Integration Sensation
So another thing to consider is integration. I download apps to extend my the abilities of my device. One thing I have enjoyed, and use on a regular basis on my poor old Blackberry is the send/share feature: when I take a photo I can upload it directly to Facebook. This is a feature I love, and would miss. Unfortunately, in iOS you need to be in the Facebook app to do the same thing. It’s not as integrated an experience. When I take a photo on an Android device, just like my BB, I have the option of sharing via multiple services (depending on what I have installed). Each new app I install has the ability to extend my experience in a way that is just not available on iOS.

But The Walled Garden Keeps Out The Bums!
All iOS apps go through a stringent approval process. It doesn’t necessarily make them good apps, and is certainly no guarantee they are going to be useful. In addition, development in the iOS environment is subject to certain restrictions that actually REDUCE the quality of my experience. Amazon, Google, and Rhapsody (amongst others) have all recently removed buttons that would make purchasing content easier. The reason? If the button is going to stay, Apple requires a 30% cut of sales. The result? My experience is less integrated, less seamless.

The iOS development and submission process is a minefield of restrictions, many of which are strictly geared towards Apple protecting their share of my disposable income. Yes, there are more apps on iOS. Does that really matter? 

Big Numbers Are Impressive!
Android is claiming over 550,000 new activations per day. iOS is claiming just over 300,000 new activations per day.   Analysts predict iOS will hold between 18% and 16% by the end of 2011, while Android is expected to have captured easily double that. 

Developers tend to go where the audience is. I am not saying iOS is in danger of becoming obsolete... but as a Developer I might look at where I can get the widest adoption and develop for that platform first.

The Next Two Years
2 years is an eternity in mobile tech. That said, I am hoping to live happily with my next phone for 2 years. During that time, I think the App landscape will change radically. Mainly, general focus and favor will shift from iOS to Android. My next phone will be a Bionic. Or Samsung Galaxy S2...

Blogger.com + SVG + iframe + IE9 = fail

I have run into this interesting 'edge case' which is actually a lot more common than you might think.  I have this code:

<iframe width="640" height="480" src="http://www.croczilla.com/bits_and_pieces/svg/samples/butterfly/butterfly.svg"></iframe>

Which should look something like this:

 

And for most modern browsers, and Typepad (as you can see for yourself, check this page on IE9) this isn't a problem. 

But check this out: http://icarusinflightmagazine.blogspot.com/2011/07/and-ladybugs.html

It's the same code, but if you visit it in IE9... the butterfly never shows!  The odd thing is, if you use the developer tools (hit F12 key) and check out the Network, you will see the SVG loaded.  Not only that, but if you dig into the object details you can see the actual contents of the SVG.  It just never appears on the screen.

I suspect this is a Blogger.com only issue, so I am filing a bug report with them.  I will also check out a few other blogging platforms to see if they exhibit this strange behavior.  I would love to hear from anyone else out there who has a blogging account on another service and is willing to try this out.

WHY does this matter so much?  Design Review QuickShare depends on this for 2D document viewing!  For example:

 

 

 

UPDATE: AHA! I found Blogger sets the document mode to IE7, like so:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

 

Oh, if there were only a way to override this... or get blogger to include support for IE9 in it's doc compatibility...

UPDATE 2: There is a way to fix this!

in Blogger.com you can modify your template.  See: http://feedback.autodesk.com/cloudservices/topics/embed_fails_for_ie9_on_blogger

SVG + Object + Caching = Trouble for IE9

While building a web based viewer that uses the SVG format to display 2D documents, we have run into some interesting issues. There are many ways of getting an SVG into your HTML, and each comes with it’s own set of features and problems.

We needed access to individual elements within the SVG document. That pretty much narrowed our choices down to injecting the SVG inline (this has x-domain issues), placing the SVG in an iframe, or using the <object> tag.

We also needed to be able to Pan the document... this means we need drag and drop functionality. Unfortunately the default click event handlers didn't function properly in iframes in our initial tests. This left us with the <object> method.

The <object> tag is generally the preferred method of displaying SVG files. It has wide browser compatibility and allows access to the inner DOM, important when you want to manipulate sub items like layer visibility.

So we’ve been using <object>, and it works fine in our development and testing... right up until we put it on an external server. And then came the problems with IE9 (oh IE, you wily minx!).

We started to see that (only in IE9, and only from behind our corporate firewall) the initial header request for would stall for 2-3 minutes. That’s a long time to wait for an SVG to start to download!

It’s gotta be the firewall, right? Then we thought, maybe something else in our viewing application might be effecting it. Maybe it was a mis-configuration server-side?

In the meantime, we started to see the same issue pop up in another project that was getting ready to launch. It started to appear right after we introduced CloudFront for content delivery.

We made a reduced reproduction of the case, a basic html page with a SVG in an <object> tag. This time the problem was evident everywhere, even outside our corporate network... as long as the SVG was requested from CloudFront.

As it turns out, when there is a caching layer such as a packet-shaper/firewall/CDN, the <object> method for SVG embedding kinda sucks on IE9. I am going to say this is a bug in IE... it doesn’t seem to effect the other browsers that support SVG.

If IE9 support is important to you, then my recommendation would be to use an iframe to embed your SVGs. We have since conquered the event handler issues we were having with iframes initially, and iframes seem to have consistent compatibility and still allow us DOM access.