With ARM devices like the Microsoft Surface and those from other OEMs, where it's not possible to run Visual Studio directly, it's good to know a few details on how to run/test apps on them.

First is remote debugging, described on http://msdn.microsoft.com/en-us/library/windows/apps/hh441469.aspx. It's quite easy to set this up–install the Visual Studio remote debugging tools, then select the Remote Machine option in VS on your dev machine and go from there. (Note: the link to the tools on the hh441469 page is broken as of this writing. Go to http://www.microsoft.com/en-us/download/details.aspx?id=38184 instead.) Just be sure that if you restart the ARM device, you need to restart the Remote Debugger (see the Start screen) for VS on your dev machine to pick it up on the network.

Testing on the ARM device specifically can reveal performance and responsiveness issues, as when you're doing an animation that's not running in the GPU (such one that affects CSS properties other than transform and opacity). It's also essential when you're working with sensors that aren't available on your dev box.  I also noticed with one app that running on the Surface revealed a latency issue in generating the layout, which was good to know of course!

Next, if you don't need to run the app in the debugger, and want to test as when it's directly installed, you can sideload the app. Just copy an appx package files created on your dev machine to the device, then run the PowerShell script. This does require that the ARM device has a developer license on it, which should happen when you install the remote debugging tools. (You might be prompted otherwise…I haven't tried this exact configuration so I can't say for sure.)

Next, there are occasions where you need to get a crash dump on an ARM device. You can enable generation of a local dump through some registry settings described on these two pages: http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/bb513638(v=vs.85).aspx.

Finally, if you ever need to obtain a screenshot (especially for filing bugs and such), you'll quickly find that Print Screen keys and other standbys just aren't on the Surface, the touch keyboard, or the on-screen keyboard. The trick for Surface, at least, is to hold down the Windows button on the front of the Surface (the one that goes to the start screen) and press and release Volume Down on the side.

Addendum (4/23/13): In working with my own Surface I found today that my developer license on the device had expired, which resulted in an error on my dev machine when trying to use remote debugging. To remedy this, open an Administrator Command Prompt, the enter powershell, then from that prompt type show-WindowsDeveloperLicenseRegistration. That shows the UI that you normally see in Visual Studio to renew the license. Once I did that, and waited about 1-2 minutes for the renewal to take effect, I was able to run the remote debugger again.


As you’ve probably heard many times, the use of asynchronous APIs is a key theme in Windows Store apps to help them be “fast and fluid,” and to remain responsive to touch input and so forth. Simply said, async operations run on non-UI threads, so they don’t block the UI thread (and therefore input) while their processing is going on.

However, at some point the results from those async operations (as most of those APIs produce) do have to make their way back to the UI thread. That is, some completed handler that runs on the UI thread will be called with those results, wherein that handler processes them in some way.

For small numbers of parallel async operations, this isn’t typically a problem. Problems can arise, however, if an app kicks off many simultaneous operations within a short amount of time, such that the completed handler will at some point get pounded with each individual result. For example, let’s say you have a StorageFolder for some part of the user’s pictures library, and you call its getFilesAsync method. This is a single operation that produces a vector of StorageFile objects, so no problem there.

Now let’s say you use forEach to iterate that vector and call StorageFile.getThumbnailAsync on each one. If that folder contains 1000 files, you’ll quickly kick off 1000 background threads. This might cause the CPU usage to spike, but it’s all in the background so the UI is still responsive.

Then those thumbnail results start to come into the completed handler, where you might be extracting more information from each thumbnail or calling URL.createObjectURL to turn it into a displayable image, like so (where listItemImage is, say, some img element in a ListView):

file.getThumbnailAsync(Windows.Storage.FileProperties.ThumbnailMode.picturesView).done(function (thumb) {
    var stream = MSApp.createStreamFromInputStream(thumb.contentType, thumb.getInputStreamAt(0));
    listItemImage.src = URL.createObjectURL(stream);
});

thumb.getInputStreamAt, MSApp.createStreamFromInputStream, and URL.createObjectURL are all synchronous APIs, however, and assinging an image source can trigger rerendering as well once you return from that handler. So with every callback you might be blocking the UI thread for some time as well as triggering additional UI work as a consequence. In the end, even though you’re using async APIs to do some of the work, the UI can sluggish nonetheless.

So beware of situations where you’re creating a many async operations in a short span of time, you’ll want to implement a kind of batching strategy to stretch the work out in the time domain somewhat. I don’t have any specific numbers to offer here, but in the example above, you’d want to prioritize items that are actually visible and do those first, then continue doing the work for non-visible items within some setTimeout delays.

 


When designing apps for children, the UX guidelines for Windows Store apps are generally applicable. However, there are a couple of additional tips that have come out of research on this demographic.

First, as with just about all new things, children tend to pick up the Windows 8 UX patterns more quickly than those adults who has preconceived notions about how the system should work. My six-year-old son is a good example here–he hasn’t once thought “this should work some other way” even though he’s worked with desktop apps as well. To him, it just is what it is, and because he’s primarily interested in the app, he doesn’t let other considerations worry him! In other words, don’t spend much time worrying whether children will be able to learn the Win8 paradigms that are represented in the design language: they just will.

Along these same lines, research has shown that children pick up on transient UI like the app bar after being shown once or twice. I think to them it’s something like a peek-a-boo game…which makes it fun!

As a side note, I’ll add that having a picture password is invaluable with pre-readers. I have an older Dell Duo that we use in the car for my son’s video player, as it has a 500GB had drive onto which I’ve ripped most of his DVDs. Before picture passwords, one of the adults in the car had to log in whenever we turned the machine on or woke it from sleep. A picture password, on the other hand, is very easy (and entertaining) for a youngster.

Finally, the other bit from research is that early learner apps should have primary commands on the app canvas and secondary commands in the app bar. For apps in general, the recommendation is that only “commands that are essential to a workflow” should be on the canvas, but for early learners it makes more sense to have more of those visible all the time. As an example, a video play command should be on canvas when the video is not playing. During play, other controls like forward and back can be in the app bar; again, as children will quickly learn to look there for such commands, they’ll find what they need.


When using different contracts that broker interaction between two apps, it’s a natural question to wonder if your app is really going to work with all other arbitrary apps. This is the intent of contracts in the first place, but it’s good to put apps in the Store when you’re reasonably confident that they’ll work according to that intent.

With sharing data through the Share contract, in particular, it really boils down to finding target apps that can consume the data formats you provide. If you’re using only known formats (HTML, text, bitmap, files), then the Share target sample app in the Windows SDK provides a good generic target. When you invoke it through Share, it basically shows you all the data it finds in the shared package, which is very helpful for checking out that the package contains the data you think it should.

You’ll then likely want to test with some likely common targets. The built-in Mail app is a good candidate, as is the Twitter app that you can find in the Windows Store.

For custom formats, you probably don’t share such data without having some target app in mind, so you’ll know who to test with.

Beyond that, the APIs for sharing are actually designed so that you don’t need to worry too much about more extensive testing. The only way standard format data gets into a shared data package is through method calls like DataPackage.setBitmap and DataPackage.setUri. That is, rather than having the source app just drop a string or some other object into the package directly, these method calls can validate the data before making it available. This guarantees that the target app will have good data to consume, meaning that the target app can just examine the available formats and use them how it will.


Even though this capability does not exist in WinRT directly, it is possible to determine the processor architecture at runtime through the Win32 API, GetNativeSystemInfo. This API is included in the list of Win32 APIs that can be called from Windows Store apps (see the system page specifically). You can call this directly from a C++ app, of course, and from C# or Visual Basic you can use PInvoke as described on this MSDN forum thread.

To use the API from JavaScript, as with any other Win32 API, you’ll need to create a WinRT component wrapper. I show how to do this in Chapter 16 of my book, with the resulting DLL/WinMD being small. The short of it is that within your JavaScript app project, right click the solution in Visual Studio and select Add > New Project… then choose Visual C++ on the left and Windows Runtime Component in the middle. Call it SysInfo for lack of a better name.

In pch.h, add this line:

#include<Windows.h>

In the component’s header (.h) file, define a method like this:

namespace SysInfo
{
    publicrefclassInfosealed
    {
    public:
        Info();
        static Platform::String^ GetProcessorArchitecture();
    };
}

 

Here’s the implementation of the class in the .cpp file:

#include“pch.h”
#include“Info.h”

usingnamespace SysInfo;
usingnamespace Platform;

Info::Info()
{
}

String^ Info::GetProcessorArchitecture(void)
{
    SYSTEM_INFO sysInfo;
    String^ str;

    GetNativeSystemInfo(&sysInfo);

    switch (sysInfo.wProcessorArchitecture)
    {
        casePROCESSOR_ARCHITECTURE_AMD64:
            str = “x64”; //AMD or Intel
break;

        casePROCESSOR_ARCHITECTURE_ARM:
            str = “ARM”;
            break;

casePROCESSOR_ARCHITECTURE_IA64:
            str = “IA64”;
            break;

        casePROCESSOR_ARCHITECTURE_INTEL:
            str = “x86”;
            break;

        default:
            str = “Unknown”;
            break;
    }

return str;
}

 

To use the component from JavaScript, right click the JS project in Visual Studio and select Add Reference…. In that dialog select Solution on the left and the component name in the middle. Then you can use this line and do what you want with the resulting string.

var arch = SysInfo.Info.getProcessorArchitecture();

You could also return numeric codes from the C++ component, of course…your choice.

 


First, we’re sometimes asked whether it’s possible to give out promo codes for paid apps, or otherwise gift apps? Answer: not at this time.

Second, if you have an app that’s certified but just waiting to go live according to your indicated release date, can you change the date so that it publishes earlier? Answer: same thing, not at this time. Another good idea for future implementation, as currently you have to resubmit the app and go through certification again.

On the subject of release dates, the documentation for this says that the date guarantees that the app won’t be released before that date (GMT time), but can’t guarantee that it will go out on that date. The latter caveat is there because the app might not have made it through certification yet; otherwise, if it’s certified, the release should happen pretty quickly. At present, it’s also not possible to set the release for a specific time.

 


When a Windows Store app written in JavaScript is installed on a machine, its source code is basically sitting there, ready to be loaded into the apphost process at runtime. This does cause some developer angst, as that same source code is basically sitting there, also ready to be examined by an enterprising user with admin privileges. For this reason, JavaScript developers start thinking about minification or obfuscation to make it at least harder (I won't ever say impossible) for others to borrow or outright pirate their code. It's also important in the gaming sector to prevent cheating (whether real or perceived). In this post, then, I wanted to note a few things you can do to protect your app.

First, check out the post on the Windows 8 Developer Blog called Designing a simple and secure app package – APPX. Most of the article is about protecting the consumer through digital signing and so forth, the but near the end it talks a little about deployed app security. In the former case, the digital signature of a package applies to its entire contents, thereby giving the system the ability to detect whether the package–your source code that's just sitting there on the file system–has been tampered with. Thus if a, shall we say, creative user decides to hack a game to improve their high scores,* the system will prevent that app from running at all.

Next, to protect the source code itself, you can certainly use whatever minification/obfuscation techniques you already know for JavaScript. This makes it harder for someone to read your source code, though reverse-minification tools do exist.

On the subject of minification, note that the reduced size of JS/CSS/HTML files is really quite unimportant for apps. For one, JavaScript is automatically converted to byte code on installation as a startup optimization. Minification could save a little memory at runtime and perhaps make your package size smaller, but this is often insignificant compared to the effect of images. Indeed, making a 3-5% change in compression for PNGs and JPEGs will probably save more space than minifying text files without a noticable impact on image quality. It's also important to choose the right image format–photographs will typically compress better in JPEG than PNG, and if you can use GIFs, those work great for line art or graphics with only a few colors and long runs of similar colors. Similarly, small adjustments of the bitrates in audio and video resources would reduce the package size much more than minification.

Back to obfuscation–at this time, further protections of JavaScript code aren't available at this time. Clearly the platform could do more here, but we'll have to wait and see.

In the meantime, what else can you do? One solution for this is to keep code on a server and acquire it at runtime. This can be intercepted with network sniffers, of course, and one can always attach a debugger to the app at runtime. The Windows Store certification requirements also specifically disallows executing code in the local context that's obtained from a remote source (section 3.9). You can do this in a web context, however, and pass the results to the local context. Similarly, you can execute code on the server and return the results. With Store requirement 3.9, though, you have to avoid about driving the app's interactions with the Windows Runtime with those results lest you violate the policy.

Beyond this, you can move critical or sensitive code–that is, algorithms you want to hide–into Windows Runtime components. These can be written in C# (which is more obfuscated but still reversible, and introduces more overhead when used with JavaScript) or C++ (the best option, as reverse-engineering optimized assembly code is a strong, but not perfect barrier). Private encoding/encyrption algorithms are a typical candidate for such components, but other important logic can benefit as well.

In the end, it all depends on the level of security you're trying to achieve, recognizing that when the code is on a client machine, there simply isn't a foolproof way to keep it safe from the most determined individual. (Even running everything on a server isn't 100% secure, as hacker groups repeatedly demonstrate.) So it's a matter, really, of erecting roadblocks along the way that will deter different levels of threat.

If you've found other methods that work too, I'd love to hear about them in the comments.

 

 

*If you remember the Space Cadet pinball game that first came out with Windows 95, I eventually tired of playing through all the missions and levels. With a little exploration of its massive .dat file, I reverse engineered the data structures that determined how many lights and points you got for each mission. By bumping those up (dramatically) using Visual Studio's hex editor, it was much easier to advance enough to play the more advanced missions. In my case I just wanted to enjoy the game without the frustrations of slogging through all the earlier missions each time, but of course my scores looked pretty good too!


In the Here My Am! app of my book, one problem I didn’t get around to solving was scaling of captured images to fit the display area. Typically this isn’t a problem when you capture an image large enough for that area, but when you have a low-res camera (or a high-res camera set to a low res output), or when you change view states, the image can become distorted.

As I’m working through the book now for a  second edition, I fixed this particular problem in Chapter 2’s version of the app, and fortunately the solution turns out to be pretty simple. The trick is to first wrap the img element in a div where that div contains a 1×1 CSS grid. The img element, as a child, is then centered within that cell. So in default.html I replaced the <img> element line with these:

<divid=”photo”class=”graphic”>
<imgid=”photoImg”src=”#”alt=”Tap to capture image from camera”role=”img”/>
</div>

And added these bits to default.css:

#photo {
    display: -ms-grid;
    -ms-grid-columns: 1fr;
    -ms-grid-rows: 1fr;
}

#photoImg {
    -ms-grid-column-align: center;
    -ms-grid-row-align: center;
}

Within photoImg, then, we can style that element to be 100% width or 100% height depending on whether the picture’s aspect ration is greater than or smaller than the parent div, photo. The original image size can be easily obtained from StorageFile.properties.getImagePropertiesAsync. So in this added function, imgElement is photoImg, parentDiv is photo, and file is the captured StorageFile object:

function scaleImageToFit(imgElement, parentDiv, file) {
    file.properties.getImagePropertiesAsync().done(function (props) {
        var scaleToWidth = (props.width / props.height > parentDiv.clientWidth / parentDiv.clientHeight);
        imgElement.style.width = scaleToWidth ? “100%” : “”;
        imgElement.style.height = scaleToWidth ? “” : “100%”;
}, function (e) {
        console.log(“getImageProperties error: “ + e.message);
    });
}

I then call this function from within the completed handler of captureUI.captureFileAsync, after setting the img.src URI. I also have a window.onresize handler to call this again with the most recently captured file, which handles scaling the image again for new view states.

With this approach, specifically centering the image in the parent div’s one grid cell, we get automatic letterboxing around the image.

I believe it would also be possible to solve this with a WinJS FlexBox control, which effectively does the same thing. I don’t think it would mean any less code, however. The solution here, of course, depends on the WinRT APIs and having a StorageFile object. For use with pure HTML/CSS, you can create a new Image and assign its src, and once loaded that object’s width and height properties will be available. When you have those values, you can then use the same calculation as above to scale the image without changing the aspect ratio.

 

 


With the option to create Windows Store apps with HTML5, CSS3, and JavaScript, developers often wonder what it will take to turn a website into an app. A while back I scribbled out some notes on the process that I thought to share here.

If you have other thoughts, please add them in the comments!

 

First are those requirements that come from the Store policies themselves. All of the requirements are important, of course, but the following are those that apply especially to converted web apps:

  • Section 2 is a key consideration: “Windows Store apps can display ads but are more than just ads or websites.” This means, especially section 2.4, that you can’t be a link farm that opens the browser all the time, and that you can’t just repackage a website wholesale into an app and expect it to pass certification. However, pulling web content into the context of the app, where the user can see that they’re in the app, is just fine.
    • Also note section 3.1: “You must use only the Windows Runtime APIs to implement the features of your Windows Store app.” This does include HTML5 and JavaScript APIs, even though they aren’t technically part of WinRT, and doesn’t exclude using third-party libraries. It’s really saying that you can’t use local IPC or services which are blocked anyway.
  • Also skip down to section 5 of the requirements that deal with content (as well as age ratings). Some content will not be accepted into the Store at all, so if your web app deals with such, it’s not a good app candidate.
  • The app must support touch input (section 3.5 of Store policy). Much of this comes for free, as touch events are automatically translated to legacy mouse events as web apps typically listen for. Nevertheless, you have to make sure the app is fully functional on a touch-only device. Note that requirement 3.5 also says “Your app must not use an interaction gesture in a way that’s different from how Windows uses the gesture.” Make sure to revisit any custom gesture work.
    • Note that this requirement also says “Your app must provide visual feedback when user touch interactive elements.”
    • Typically, web apps being converted to Store apps also need a little work to make links and other clickable content large enough to work with touch. This often just means increasing the spacing around multiple interactive elements that are otherwise too close together.
  • View states: the app needs to handle snapped, filled, landscape, and portrait modes (requirement 3.6). Technically, the policy only speaks to snapped view (as a specific point of rejection), but really, aim to make an app that looks good in any view state.
  • Honor process lifetime states of suspend and resume, and have no close affordances in the app (requirement 3.6–typically not something a web app ever has anyway). It’s important for apps that use online content to refresh that content if necessary when the app is resumed, as it may have been suspended for a long time.
  • Requirement 3.9 says, “All app logic must originate from, and reside in, your app package.” Specifically, any code that interacts with the WinRT APIs has to be in the package and cannot be downloaded from a remote source. This means any libraries you use in the main app (the local context) must be bundled in the package (along with whatever those libraries depend upon). Parts of the app that use the web context are allowed to access remote script, as the web context cannot access WinRT. Avoid downloading such script and passing it between contexts to execute/eval it in the local context. This opens security holes and is a basis for rejection.
    • Related to this is the fact that the local context also disallows script injection, e.g. via innerHTML attributes, and imposes other security constraints within the app container. This can affect third party libraries.
    • The underlying purpose of this requirement is security more than anything, that is, to avoid having potentially untrusted code execute in the local context where it could possibly do some damage. Admittedly, this is a gray area. Clearly, something like a magazine, book, or other multimedia content is not “app logic” and can certainly be downloaded, processed, and displayed in an app. Definitions for new levels of a game fall into that same bucket, even though such configurations might ultimately drive how the app code executes. Downloading a program or script in some other language, on the other hand, that then runs as an app inside your app, will cause rejection. In the end, I think this is primarily about the difference between data that’s rendered visually and instructional code or script that drives execution. Still, it’s a gray area to me, so I think we’ll see further refinements of this policy as new kinds of apps are developed.
  • Privacy policy (requirement 4.1, 4.1.1, 4.1.2)–essential if you’re hitting the Internet in any way. You must also have a means for support (requirement 6.3)
  • Protect against large transfers on a metered network (requirement 4.5)
  • Be mindful of age ratings (requirement 5.1 and 6.2). This isn’t something you deal with on the web, but is required when submitting an app to the Store.

 

Store requirements are, of course, the min-bar for Store submission and certification. To be a good app on the platform, however–which means creating an app that Windows users will actually want to install!–you’ll need to go beyond those basics. The following, then, represents the core of platform integration:

  • Horizontal orientation: although web apps are typically designed for a vertically-scrolling experience, the design of Windows Store apps are primarily horizontal (except in snapped view). This may affect your app’s interaction model significantly, but is what users will expect.
  • View states: again, support all the view states, not just landscape and snapped as required by policy.
  • Handle resolution scales well, both varying display sizes (what we call responsive design in the web world) and different pixel densities. The latter means having raster graphics that work well on 100%, 140%, and 180% scaled devices.
  • Beyond suspend/resume (as required by policy), the app should be able to be terminated while suspended and then restart where it left off. This means saving transient session state and being able to rehydrate the app from that state.
  • For any commands that are not essential to completing a workflow, move those commands/controls off the app canvas and into flyout controls like the app bar, settings panels, and the Search and Share charms. There are many guidelines for this found on Commanding design.
    • Note that it’s OK to leave some search and sharing functions directly in the app; just think about how to also integrate with the charms.
    • Move app settings into Settings charm along with logins and profile management. You can have some on-canvas login/user controls, of course, but use Settings for additional features rather than separate app pages.
  • Minimize chrome (non-functional UI elements), which happens automatically when you move commands off-canvas, but also means using layout and typography to group functionality rather than lines, boxes, and so forth.
  • Migrate from <a href> navigation to a single-page model with DOM replacement. This will greatly simplify managing state in the app, although you can transfer state in other existing ways. It’s just much easier to not have a new script context with every page.
  • Have great branding graphics including tiles, splash screen, Store logo, etc.

 

 

Beyond that, some additional considerations will take the app to the next level:

  • Handle variations in network connectivity or lack thereof. On the web, you assume connectivity because the app has to be loaded into a browser from the web. An app exists on the client, however, and can be run without connectivity. So think about your offline behavior and caching strategies.
  • Live tiles: what can you surface on the tile more than your logo?
  • Roaming experience—what settings transfer to the user’s other devices when they have the same app installed?
  • Localization (depending on your target markets)
  • Accessibility
  • Good use of progress indicators when transitioning pages. In browsers, users come to depend on the browser’s indicators about page loading. In a Store app, you need to indicate such states yourself, and implement strategies to minimize wait times and increase responsiveness.
  • Honing performance especially if using collection controls.

 

Your thoughts and/or experiences?