Hats off to CodeProject, Intel

CodeProject is currently holding a Windows 8 & Ultrabook App Innovation contest and I was fortunate enough to make it to the second round. It's a great contest, as all first round winners, myself included, were winners of a brand spanking new prototype model Ultrabook for development:

4Gb memory, Intel I-7(Ivy Bridge) Processor 2-2.5GHz,
160Gb HD, 5 Touchpoint Screen, Windows 8 OS.

I don't really have any technical points in this post, but I wanted to give some kudos to the folks at CodeProject as well as Intel, since I did have an issue with my screen cracking after a week or two. Since it was a free laptop, and CodeProject barely knows who I am, I was not hopeful about being able to get this issue resolved. And it's an unbranded prototype, so I wasn't really sure what manufacturer would be able to help me. Plus, it's a touch screen, so you can't just replace the glass like other laptops (even though it was still fully functional using mouse and keyboard).

But Chris at CodeProject pointed me to Premier Intel support, which came with the laptop, and they swapped it out for me as soon as I could give them a UPS tracking number. Five days later, I'm up and running on the replacement, and it's the best laptop I've ever owned. Fast, responsive, and boots to a functional Windows 8 login screen within 5 seconds. Thanks, CodeProject!

Windows 8 Store Deployment - Lessons Learned

After finally getting an app deployed to the Windows 8 Store, I wanted to share some learning experiences. I went through 2 multiple-hour sessions with the MS engineers - the first session focused more on coding and performance and uncovered the fact that the app was consuming a great deal of memory. It ended up that a few simple jQuery animations - which functioned OK in all other browsers including IE9  - went through the roof on memory consumption in IE10. So I minimized the jQuery animations and it resolved that issue, and now I am looking into revisiting it with the current version of IE10 and the RTM version of Windows 8.

The second interview dealt more with Win8/Metro standards and things like using Settings and the positioning of elements on the screen. At that point I was ready to deploy to the web store, which is a time-consuming process. I did find that having concise notes pertinent to each deployment did help speed up the turnaround time - the first submission took about 5 days to be rejected. By the time it was finally approved, I had deployed 3 times in one day, entering very specific details of the changes I was submitting.

A few things that bit me especially hard:
Certification Requirement #4.1 - Privacy Statement. If you use ANY user information, which includes accessing geolocation, you have to mention this in the privacy statement.

Also, if you have a privacy statement you must include it in your settings, AS WELL AS a link to a privacy statement HTML page in your store description.

Certification Requirement #6.2 - Age Rating. You have a clean app, right? Clean content, and you just implement the Sharing source contract so people can share text or an image from your app to Twitter, Facebook or whatever social network. Well, you'll have to make sure your age rating is 12+ for "uncontrolled sharing", or else you'll surely be rejected.

If you want to "control" sharing, you'll have to create some custom code to enable the user to "allow" other users to share from your application. So, assuming you're not targeting the 3 to 11-year-old crowd, you'll want to set your app's age rating to 12+ any time you implement the Sharing Source contract.

Responsive Design and Portability into Windows 8

One of the most common gotchas when you're trying to deploy your Windows 8 Metro* HTML app to the Windows Store, is that the application does not support SnapView. In case you're not familiar with SnapView, it is the mode where your app is "snapped" to a side window while another app is in use in the main FillView window.



There are easy ways to implement this in Windows 8, but one striking things about the width of our SnapView window is the fact that it is 320 pixels wide, which happens to be the standard screen width of many mobile devices in portrait mode.

So if we have an existing web application that is "mobile-friendly" - meaning we've used Responsive Design and CSS Media Queries to ensure it will adapt to whatever environment it is being viewed in - this HTML code is not only portable into Windows 8, it also satisfies the SnapView requirement.

That’s one of the great stories about Windows 8 HTML apps that isn’t really being played up as much as it should – the fact that portability of traditional web applications INTO a Windows 8 HTML project is fairly seamless. As a web developer, one of the things that first impressed me about Windows 8 was the ease of running a traditional HTML application within a default new Metro* HTML project. Even an app that uses jQuery or other JavaScript frameworks.

After merely adding a traditional app’s .html, .css, and .js files to a new, empty Visual Studio 2012 HTML application, the only thing that prevented it from running as a full-screen Windows 8 app was the fact that the references to the WinJS javascript files needed to be added. Once these 3 JavaScript includes were added to the page, the application was instantly running full-screen, like any other Metro* application. Here are the required .js files

<!-- WinJS references -->
<script src="//Microsoft.WinJS.1.0/js/base.js">
</script>
<script src="//Microsoft.WinJS.1.0/js/ui.js">
</script>
<script src="/js/default.js"></script>
<link href="//Microsoft.WinJS.1.0/css/ui-dark.css" 
rel="stylesheet" />

Of course, referencing these WinJS-specific files excludes the reuse of this HTML code outside of the Windows 8 environment. But the “portability in” story is still nice – I say this as a web developer who originally came across Windows 8 as part of an experiment in HTML portability.

*I'll still be using the word Metro until there's an official term for applications that target the WinRT

Deploying HTML5 Metro apps to the Windows Store...some common gotchas

After going through all the effort to build a Windows 8 Metro app before the OS is released, you'd think the hard part is behind you when development is done - what with the in-progress documentation, empty Google searches, and constantly mutating API. Now it's time to deploy to the Windows Store. How hard could that be?  Based on my own experiences, and insights from other early-bird developers, here's a look at some of the common offenses that will surely take you down the path of rejection:

1). Read the Certification Requirements. Really.
2). No items in the left and right swipe margins. No exceptions.
3). Buttons, in app functionality, credits, go down in the app bar or under Settings, not on screen.
4). Snapview - your app has to be usable when "snapped" to the 320 pixel sidebar section in Windows 8.

There are standard ways to handle the switch to Snapview in Windows 8, but for Metro HTML5/JavaScript apps you also should consider using Responsive Design,  Which I'll talk about next week.

PhoneGap HTML5 Portability II - Chrome Web Store Hosted Apps

Last week I talked about the Chrome Web Store being another good high-traffic outlet for your PhoneGap HTML5 codebase.

One of the first issues I encountered with my Packaged App in this new outlet was with advertising.  The ads displayed just fine, as they do on the main website, except for one thing - for every click, the earnings were always $0.00.  That's not good.  After an exhaustive search, I came across this promising answer, but still, $0.00 every time.

The actual problem was that I was using a Packaged App, which essentially is your entire codebase running locally on the user's machine. It ends up that ads within a Packaged App don't have a "legitimate" source URL, according to AdSense, since it's really just local code on the user's machine.  The Chrome Web Store's alternative to a Packaged app is a Hosted App - which is a link to the URL of your application. 

The Hosted App solution is not only appealing as a valid source to display ads, but from a maintainability standpoint I now have one less place to deploy to.  All I need now for deployment is my manifest file and app icons - the Web Store app just piggybacks on my already-existing website.

Here's a sample manifest file for a hosted app:

{
  "name": "My Cool App",
  "description": "This is a test of the Chrome Web Store",
  "version": "1.0.0.1",
  "app": {
    "urls": [      
      "*://www.yourwebsite.com /mail/",
      "*://www.yourwebsite.com /otherarea/"
    ],
      "launch": {
      "web_url": "http://www.yourwebsite.com/"
    }
  },
  "icons": {
    "128": "icon_128.png"
  },
  "permissions": [
    "unlimitedStorage",
    "notifications"
  ]
}

Note that you need to specify a launch URL, as well as any other non-asset URLs you'll be using.  And you will need to verify that you are the owner of this site using Google's Webmaster Tools.

So the quest for a solution to the AdSense problem sent me down the path of investigating Chrome Web Store "Hosted Apps", which not only resolved my advertising issue, but ended up being a better solution in general for my needs.

 If you're debating which type of app would work best for you, here is a good comparison of Hosted vs Packaged apps

HTML5 Portability beyond PhoneGap - The Chrome Web Store

One of the great benefits of doing mobile development using PhoneGap is the portability of the codebase. The same HTML application is easily wrapped and built for all major devices using PhoneGap and/or PhoneGap Build. And since your app is written using HTML, CSS and Javascript, you can make it accessible as a web app as well.

After I had already published a few apps to the Android Market using this technique, I read about the Chrome Web Store. And once I digested their publishing and deployment specs, I noticed that the same PhoneGap codebase could easily be deployed to this outlet as well. I re-deployed the same apps to the Chrome Web Store a few months ago, and my experience was so positive, I wanted to share a quick overview of how to deploy to this store, and some things you'll want to think about:

The deployment is simple for Chrome Web Store Packaged Apps - basically you create a .zip file of your HTML app, along with a simple .manifest file, the app icons, and preview images. Here's a sample manifest that launches splash.html at the root of your app:

{
  "name": "My Cool App",
  "description": "This is a test of the Chrome Web Store",
  "version": "1",
  "app": {
    "launch": {
      "local_path": "splash.html"
    }
  },
  "icons": {
    "16": "icon_16.png",
    "128": "icon_128.png"
  }
}

(Full documentation)

The preview images are not required, but you'll never get very high in the rankings without them... and of course the image sizes don't match the Android Market sizings, so you'll need to create new ones. And they will not accept them until the images meet their aesthetic criteria - I had two go-arounds with them because of font sizing.

...but the pleasant surprise was the traffic:

The identical app in the Android Market after 6 months or so has about 2400 downloads, and is approaching 1000 active installs.

In the Chrome Web Store, there are 3500+ users in less than two months, and 250+ users daily, 14,000+ total. Rarely is there inactivity when using Google Analytics' real-time tools.

The manifest sample I showed was for a Chrome Web Store "Packaged App", but for my needs I found that a "Hosted App" was the better way to go - and even easier. My post next week will highlight the advantages of using a Hosted App, plus some tips on using advertising.