Installation Error: ApplicationVerificationFailed

04 Dec

For future reference: if you're compiling a mobile app for Adobe AIR and you get this error, it basically means that there's something wrong with the certificate that you're compiling with. The app I'm working on at the moment is using TestFlight for distribution and after pushing a build, I was unable to install to any of my devices. The installation on both iPad and iPhone went as normal until after the install, where it just said that it "Failed to install".

Turns out I had mixed up release and development versions of the certificates. Duhh... Posting it here to help others doing the same and not finding a solution.

Feb 11 2013 update: so got this error again and my own explanation showed up in Google - but - it didn't help me. So some more detail on the problem I had today. I have several identities on some of my accounts. Some are for companies I work for and for some reason - I have two developer identities with Apple.  Let's hope I don't pay for both hmmm

This time, I got the error for trying to export the app, or rather the provisioning file with a company certificate for wich i didn't have the Key (.p12/.cer). As soon as I connected the right certificate to the provisioning file, I was able to install the app on my phone. What made me solve it eventually was to open the Organizer app in XCode. This will actually tell you if the Provisioning profile is valid, whereas Flash Builder will not. It was a bit of a facepalm when i realized it, but I'm posting it here so it can help others.

Here's Organizer showing me what Flash builder should have told me half a day ago...

Update May 2014: another way to get this error -> if you're toggling between release and development versions of the app, you must be sure that the "aps-environment" are set to "development" and not "production" when testing.

The slow climb of HTML5

27 Nov

The slow climb of HTML5

Many people I meet these days ask why I still use Flash as a base for development of applications and games. It is downright scary to hear that virtually all these people still don't know that you can author your apps in Actionscript and then easily cross-compile to very performant native code for iOS and Android. Targeting the desktop with Flash has been around for more than 10 years. Using AS3 as the language and Adobe AIR to export gives you great performance and access to really advanced tools that allows for proper debugging, even directly on the GPU.

Using this stack comes with an overhead, but I would say that it's only 5-15% slower than pure native code. Perception of speed is of course subjective, but my Arduino Companion app have now been installed on more than 60.000 devices and both major app stores show a 4.5 of 5 rating. This app is currently not using any form of GPU acceleration, but the users still love it. I am currently in the middle of a cross-platform game that IS using acceleration and I'm really happy with what I'm seeing this far.

When it comes to HTML5, I see lots of good stuff happening on the desktop. HTML5 has replaced Flash for many purposes on the desktop and I don't mind this. In fact, I encourage it. I've always been a huge fan of using the right tool for the job. That's why I switched Flashmagazine to HTML more than ten (!) years ago. Flash became big because there were no good alternatives and it's only natural that it's role should change.

HTML/JS/CSS is part of my toolset and it has always been that along with PHP for the serverside. However, if you are one of those that think that HTML5 is a good solution today, you should read this great article by Ben Savage of Spaceport.io. It summarises most of my experience from the mobile HTML5-game I made for NASA recently. My biggest problem with HTML-based apps is that they're slow and have little contact with the device they run on. I absolutely hate going to a website that asks me to install it "as an app". All this does is add a desktop shortcut and the poor developers can't even know if I already did install the shortcut. Due to the lack of this they keep nagging me with their stupid "install-me" dialogue every time I visit their site (yes - I'm looking at you Google Calendar).

I'm sure that omissions like this eventually will annoy enough mobile vendors so they create a way to reliably detect if a shortcut has already been installed. The problem is just that this is but one of many things that need to fall in place before HTML5 is really useful. I also got a shock recently when a friend bought a brand new MacBook Pro and Safari couldn't show the default HTML5 video. All he got was green flickering squares. The fix was simply to install Chrome, but this highlights a core point in Ben's article - browser vendors have no interest in making Browser apps really good.

My other experience is that doing an app as HTML5 adds development time. I've discussed this with others and their ballpark is about the same as mine. 30-50% extra time is required to make a good cross-platform HTML5-app. Most developers ignore mobile for this very reason, but come on... Isn't the whole point of HTML5 to get that extra reach? To actually make it work Mobile first and fully responsive?

So why do I still use the Flash Platform for apps and games? I use it to deliver on my promise of real crossplatform apps. I can use the very same code-base to make a game for iPhone, iPad, iPod, desktop, Facebook-apps, Web as well as all the funky flavors of Android. All I would want extra at the moment is Windows 8 support. That would make my toolkit complete.

Now if only Adobe could start telling the world how good this stack really is...

SafeFrames for mobile apps

25 Oct

SafeFrames for mobile apps

When designing a mobile app for multiple devices and resolutions, it's important to know how the different aspects can limit the positioning of design elements. For a recent project, I made some SafeFrame images that the designer can overlay to make sure all important elements are within the limits of typical iOS devices and a popular Android tablet that we target. I guess this can be useful to others so here's the image for centered designs and here's the image for Left-adjusted designs (transparent PNGs).

Flash Builder fails to start

25 Oct

Flash Builder fails to start

After upgrading my Mac to Mountain Lion, I keep having problems with the machine not going to sleep as it should. Instead, some process (that I never started) hangs the machine at full load. I usually find my machine with the fans blowing hot air and in an unrecoverable crash state. Many of my friends have the same problems with Mountain Lion, but I've found that the problem disappears if I unplug my external screen before putting it to sleep? I dunno why, but this works.

Anyway - yesterday I for got to unplug the screen and upon rebooting I could no longer start Flash Builder. It took a while to Google the correct result so here's the quickfix and link. If Flash Builder 4.5, 4.6, 4.7 or any other version fails to restart, it's usually your workspace that have become corrupted. The fix is simple. Open a terminal window and navigate to your workspace directory. In this folder, there is a hidden directory called .metadata. This is what is corrupt. Solve the issue by changing the name like this:

mv .metadata .metadata.old

On next restart, Flash Builder (or rather Eclipse) will recreate this file. Unfortunately it won't restore your projects so you'll have to manually import these again. There's also a more complex option for the command-line savvy. 

AIR package has no certificates at entry in AIR

24 Oct

AIR package has no certificates at entry in AIR

Had a stupid Adobe AIR issue here that I couldn't find the answer to online, so I'm posting it here for future reference. If you get the error

AIR package has no certificates at entry /path/to/META-INF/AIR/appdescriptor.xml; ignoring

when installing your AIR app, it it probably something wrong with your certificate. In my case, I installed the APK and after a little time I simply got the message "Application not installed". I tried searching the usual sources, but didn't find the right answers. Eventually I installed a "logcat" tool on my Android phone to view the logs on the device directly. There it was - something about the certificate apparently?

I pondered this for a while and then it dawned on me. I had thought that I could use the same ".p12" certificate file that I use for exporting AIR to iOS. Apparently, you can't do this. You have to generate a separate ".p12" file (with no certification at all) for Android. So it's not like Android will accept ANY .p12 file - only those that are random and are not based on an authenticated real user. Obvious, right?

Warming up to browser apps

11 Sep

Warming up to browser apps

I recenty did a really fun game for my friends at Last Friday in Stavanger. The game itself was a typical fly-in-space-and-shoot-asteroids-type of game. A simple, but easy to understand concept. However - what was special was how you controlled the game and the size of the screen!

The display was projected on a 8x12 meters screen located right in the middle of the Stavanger town square. People walking by could just pick up their smartphone, open a URL and then play the game. I did the code for client, server and game/display while Last Friday delivered the graphics, the physical installation and helped out on bits and pieces.

This is the solution that we came up with:

  • JS/HTML5 game controller that works on any smartphone / pad / desktop
  • Node.js on the server with socket.io as the transport
  • AIR app for the game and display

Node.js kept a queue of clients waiting to play the game. This was sent back to the clients so they could see what position they had in the queue. The info was also sent to the huge game display that showed the game-queue in between games along with instructions on how to join. Once it was your turn, your phone displayed a "Get ready"-message and the game controls faded in so you could play.

Sounds simple? It wasn't all smooth sailing and here's some lessons learned along the way.

The original idea

The original idea was to use a local socket server and a native game controller-application that people would have to install. I wanted a challenge and thought this was a good project for testing the maturity of mobile browsers and node.js/socket.io that I had heard so much hype about. Last Friday liked the idea and I started making a "proof of concept" browser-app. This turned out to work really well and Last Friday could sit in Stavanger and play the game running on a display and server in Oslo without serious lag. Not shabby? I hacked together the concept in just one day, including learning node.js... Maybe the hype around node.js could have some substance?

As the game progressed we realized that there was no need for making a custom app and there was also no need to set up a special access point for the players. They simply connected through their 3G connection and that provided sufficient speed. Users with iPhone's got the best experience since they can use WebSockets. For Android the default Webkit browser can't do websockets, so socket.io (the transport used with Node.js) falls back to using HTTP-calls. We initially thought that this would prove to be a problem, but it worked rather well.

The solutions

I initially spent 2 days on the server, 2 days on the game/display and initially just 2 days on the mobile client. This is before some minor game tweaks and starting the dreadful job of fixing browser bugs and incompatibilities. That part took another 3 days and then some. Here's some lessons learned:

  • When making a game-controller, it's important that you can hold the button to repeat the action. The problem with this is that if you tap and hold an image in a mobile browser, the Save-as dialogue will appear. This prevents controller input and crashes spaceships... Mobile Safari has a super-neat css property called "-webkit-touch-callout: none !important". Adding this line in your CSS prevents the dialogue from showing, but - oh joy - this is a proprietary CSS tag so it only works on iOS devices.

    For Android, you'll have to hijack all possible events (ontouchstart, ontouchmove, ontouchend, ontouchcancel) for the image and then kill any default responses to this (preventDefault, stopPropagation, cancelBubble, returnValue AND return false).
     
  • Another problem with mobile clients and game-controller input is that if you drag your finger on an image, the browser thinks you're dragging it. As before - mobile Safari has a proprietary CSS-tag for this as well: -webkit-user-drag: none;
    Mobile browsers will also try to highlight selected objects. This can be also be turned off using webkit magic: -webkit-tap-highlight-color: rgba(0,0,0,0);
     
  • Using jQuery Mobile accelerated development overall, but it also caused some extra debugging when it "killed" the first fix for the above problem. I'm guessing jQuery Mobile comes with its own set of hacks and that we did something that cancelled something that our app need? Not sure how it resolved, but Edvard at Last Friday got it working again.
     
  • Calling "window.scrollTo(0, 1)" is the clue to remove the address bar in mobile apps. Works well, but not fault free.
     
  • Mobile clients don't really tell that they've closed a connection. To solve this we implemented a polling from the server that cleaned out clients that didn't reply within a reasonable time - indicating that the browser was wither closed or fully disconnected.

The game was made only for the annual ONS conference so unfortunately you can no longer play it. While having a short lifespan, the project was a great learning experience. I have to say that overall, I'm not impressed by the current state of mobile browsers. However - node.js really is a beautiful piece of Open Source software!

Node.js

Working with Node has more or less changed my mind about making apps based on Javascript. A library that allow you to learn, implement and run a custom server in just hours is nothing less than stunning. If you're a Flash developer reluctant to move into Javascript - I urge you to go check out node.js and work through this tutorial. It's fun to play with, you can easily use it with your Flash / AIR projects and you'll probably learn something new about Javascript along the way grin

Oh - did I mention the coolest part? As you can see from the screenshot above - the client was IRIS & NASA. I've actually made a space game for NASA! How cool is that?

The game in all it's 100m2 glory in Stavanger

Rock in the road

10 Sep

Ages ago since I posted some animation. I totally loved this one! The punchline is indeed very true.

Rock in the Road from SVAD Animation on Vimeo.

In other news - Arduino Companion now has passed 40.000 downloads across iOS and Android.

 

Arduino Companion 1.1

23 May

Arduino Companion 1.1

I just published an update to my Arduino Companion app to Google Play, Apple Appstore as well as Blackberry's App World. 

How's the app doing?

It's doing rather well I would say! Across the Google and Apple stores, it now has more than 20.000  140 000 (!) downloads. Not shabby, given that the only promotion I've really done for it is a single post at the Arduino.cc forums. I also don't really know what a good number is, but this isn't a game so it seems pretty good? It's also now listed as the number 1 app for the keyword Arduino in all the app stores, so I take that as some kind of compliment.

Based on feedback, the users really like the app. It has an average score of 4.6 of 5 on the Android Market and 4.5 of 5 stars on AppStore. On Market (or Play that it's called now) there's been three one-star reviews. These all complain about having to install the AIR runtime, so now I've skipped that by packing it all using the Captive Runtime capability. It's now a 10Mb download (rather than 1.6Mb) just because of those complaints. Oh well... User Power is for the good I guess?

I've also received a lot of positive feedback and it's been a great test at making view-based cross platform apps. I've done the project based on a simple framework that resides in it's own project for simple re-use, so making more apps should be fairly swift.

What's new?

I added the two most requested features from the more than 50 emails I have received from users: searching and internal linking. If a page is in the cached data, the app will now just open that page internally. Before I had this in place, all links in the reference went online to the original Reference-page. Now I check the URL requested against the cached URLs and only open the browser for those I don't have cached. The search will first search through all titles since that is usually what people want. Next it will search all the text of the cached content to look for hits there. The data is stored as XML, so it's super-fast to search that with e4x and AIR.

I've also added an omission from the last time. Many classes have an overview-page and now this one is also included. Due to the timing, I was also able to include the latest updates to the reference for the Arduino Leonardo that enables you to use the device for both receiving data from as well as controlling both keyboard and mouse. Can't wait till I get my first Leonardo board from ehobby.no so I can play with this! All versions now use Captive Runtime and if you make AIR apps, make sure you do too. Those 1-star reviews for a free product that you've worked hard to make are really hard to digest so just avoid them?

I've also fixed several minor bugs, but I can't seem to nail the one affecting certain Android tablets (including my own). I've tried asking my contacts at Adobe, but they've all failed to follow up and I don't want to push too hard...

Playbook difference

This is the first Blackberry app I'm publishing and It actually cost me a couple extra days just to get the app out for the Playbook. While compiling the AIR project for the QNX OS was more or less just the push of a button (as with Android and iOS), the app itself had a bug that only showed on the Playbook.

In the app, all listings are done in Flash but display of pages are rendered in the internal Webkit browser in the AIR runtime. The StageWebView worked flelessly on the desktop, Android and iOS, but on the Playbook it just showed a white page. I found lots of others that had the same bug, but no answers. In the end I figured out what was causing it and yeah - it was sort of my own fault. In the WebView, I capture clicks all on external linksso that I can show the internally cached version instead of the one that is online. In this handler, there was a "event.preventDefault()" that for some reason acted differently on the Blackberry device. All I had to do was to tweak the logic here and the app worked perfectly. Things like this is a little sad as it sort of breaks the advantage of having a platform that can target 3 different OS's across hundreds of devices with just one codebase.

Anyway the app is out on Google Play and the iOS and Playbook versions will come soon after (when approved) - enjoy the app!

ExpressionEngine: redirecting based on group_id

07 May

ExpressionEngine: redirecting based on group_id

Just a quick update - I've published a very simple plugin for EECMS that can redirect based on group_id. I made this so that admin users could go to one URL and members somewhere else after login, but you could use it in other ways as well. I also use it for basic redirection in a SAEF-based application based on EE, so it's good for that as well.

SAEF’s annoying default

02 May

SAEF’s annoying default

I love the Expressionengine CMS and these days I do a lot of projects with it. Today I lost an hour hunting for a stupid bug, due to a strange default. In my current project I needed a tooltip, so I did what I've done in dozens of projects before: I added jQuery + jQuery Tools at the top in addition to my own "ready-function" that would init the tooltip. It didn't work and it took me a long time to figure out what this error meant:

Uncaught TypeError: Object [object Object] has no method 'tooltip'

It looks like there's a problem finding the object, right? All the links I found led to things about the incorrect loading sequence of the Javascript files, but I knew that wasn't the fault here. I DID include the files in the right order. It worked standalone, but not in my EE templates. In other words - there had to be something inside EE that caused the problem? Strange!

A very nice module that I've only had a need for recently is SafeCracker (formerly called Stand Alone Entry Form or SAEF for short). It turns out - even if you don't use any features that require it, SAEF will include it's own version of jQuery and JQuery Tools? The code will be embedded at the bottom of your form, so even if you have everything in order at the top of the file, it'll be overwritten at the bottom. 

Fixing the problem is  as easy as adding a tiny snippet to your Safecracker tag

{exp:safecracker ...  include_jquery="no"}

This is 2012 and JS libs are updated on a weekly basis to fix browser bugs. Auto-incuding unrequested features based on outdated libraries is NOT the way to go (as default). Hope this post can help others to not spend time on this...