App Store Blunders

Posted in Air, Android, App Stores, Mobile on December 15th, 2011 by Ian Ford – Be the first to comment

After weeks of wondering why my submission to the Amazon App Store was not yet publicly available, I finally received an e-mail from Amazon explaining that they were having a hard time installing the app.

Upon launching the application, the user is presented with a message reading “Complete action using” and is given the option to select either ‘Internet’ or ‘Market’; when the user selects ‘Market’, they are directed to the Android App Market, presumably to purchase the upgraded version of the application.

Now I’m sure there are some slimy developers, but to assume that I would insert code in a free app that forces users to purchase the full version *on launch* is a bit much. Would Amazon even allow that kind of behavior?

Anyway, I ended up republishing the app in Flash with it set to search for Adobe AIR in Amazon’s App Store, resubmitted the app, and waited.

Then I waited some more.

Then I waited even more.

Finally, today I was fed up. I decided I was going to go in and resubmit the app, again, to get their attention. That’s when I noticed one important detail. While I had updated the .apk associated with the app on Amazon, I hadn’t bothered to click the  submit button, so my app had effectively been in limbo for weeks for no reason except my own habit of overlooking small details.

Doh.

Anyway, hopefully Warhol Lite will be available soon on the Amazon app store, at which point I can submit the latest update and start all over again.

HTML E-Mail Fail

Posted in Advertising, Fail on June 29th, 2011 by Ian Ford – Be the first to comment

An auto dealership keeps sending me e-mails despite the fact that I purchased from another dealer over a year ago. I opened the latest e-mail today and saw this beauty:

Dear Steve, please either use an appropriately sized image in your e-mail, or learn how to properly size the image you have available. Thanks again. (Go Angels!!!)

Google Music

Posted in Bugs on June 17th, 2011 by Ian Ford – Be the first to comment

Dear Google,

I love Music Beta. Please fix this:

It doesn’t break the player, but it is a little annoying. It seems to happen when I pause the song I’m listening to.

Google Music

Posted in Article on June 2nd, 2011 by Ian Ford – Be the first to comment

I think google music still has a few bugs to work out.

 

Adobe Media Encoder CS5.5

Posted in Video on May 20th, 2011 by Ian Ford – 2 Comments

So apparently media encoder 5.5 has a pretty sweet new feature.

If you look closely at the bottom panel, you’ll see that it lists “watch folders.” A checkbox at the top right of the window will allow you to auto-encode the contents of watch folders. This could be pretty useful for automating video encoding. Very sweet.

What I’ve been working on

Posted in Algorithms, API, Experiments, Flash on May 10th, 2011 by Ian Ford – Be the first to comment

I’ve been working on building a library for bezier curves and editable paths. I’ll share more results later.

Design Study – Swords And Earrings: Tales of Andaria

Posted in Android, Design Study, Graphic Design, Mobile on February 9th, 2011 by Ian Ford – 1 Comment

So I was browsing around the android marketplace today and I came across something baffling:

This screenshot is taken from the Mangobile homepage.

First of all, why on earth would the developer abbreviate the name of the game as “Sw&Ear?” While glancing up and down the page, I kept reading that as “Swear.” Is that supposed to get my attention?

Second of all, although I now realize the developer’s name is meant to be an amalgamation of “Mango” and “mobile,” I can’t help but continue to read it as “Mango Bile.” That doesn’t sound very nice.

Don’t let these criticisms fool you. Go ahead and watch the trailer for the game. It looks quite competent.

Question of the Day

Posted in Android, Mobile on January 26th, 2011 by Ian Ford – Be the first to comment

Why, in the Android SDK, does onCreateOptionsMenu return a boolean while onCreateContextMenu returns void? Why oh why?

This is my question of the day. This is also one of the most direct things I’ve posted about Android. I may have mentioned before that I’m getting into it. I’m actually working on a long article describing my first app (not released) as a learning experience.

There will likely be more of this stuff in the future.

The Power of Free Data

Posted in API, Data, Links, Visualization on January 18th, 2011 by Ian Ford – Be the first to comment

If you haven’t yet, check out freebase.com. It’s an awesome repository of free data with an api you can use to access it. Dig it. I found a great example of its use in the form of an interactive map that allows you to browse military conflicts around the world by time range.

Bugs and Quirks: Capabilities.playerType

Posted in Article, Bugs on January 17th, 2011 by Ian Ford – Be the first to comment

This isn’t technically a bug, but it is a strange quirk in ActionScript 3. I’ve discussed the Capabilities class before. I still like it. I still think it’s very useful.

I have one problem.

The Capabilities class has no public string constants. I was looking for an article or document explaining why you should use string constants, but I couldn’t find one so I suppose I’ll write my own later.

Anyway, most every other class that passes string values around uses constants to store those values. The Capabilities class does not. This results in code like the following:

if (pt == "ActiveX" || pt == "PlugIn") {
  //...
} else if (pt == "External" || pt == "StandAlone") {
  //...
}

Remember, it should be “PlugIn,” not “Plugin,” “plugin,” or “plugIn.” If you use any of the latter three your SWF will publish just fine without any compile errors to let you know something is amiss. It won’t be until your conditional fails to select either option that you start scratching your head wondering what went wrong.

I propose that adobe add a PlayerType class to the flash.system package. The class would simply contain four static values:

public static const ACTIVEX:String = “ActiveX”;

public static const PLUGIN:String = “PlugIn”;

public static const EXTERNAL:String = “External”;

public static const STANDALONE:String = “StandAlone”;

The benefit of having such a class is that as long as you used those values, if you committed a typo or some other minor error the compiler would let you know. Wouldn’t that be nice? I’ve submitted this as an issue in the Flash Player Bug management system. Go vote on it.