Figure 14-1: Using a unit test framework like QUnit.
Chapter 14
Preparing for the Store
In This Chapter
Making sure your app works as advertised
Getting approval from Microsoft
Keeping the app up to date
As with many of the mobile app stores, Microsoft has an approval process for apps that go in the Windows Store. If you want your app to be up for sale to the general public, you have to go through that process.
Although Microsoft has made the Store certification process very transparent, it is still quite complex. There are a lot of moving parts, and keeping an eye on everything is important.
Before you ever have to go to the Store, you need to make sure your app meets certification. There is a guideline for this, and I go over it in this chapter. The readier you are, the faster you start making money.
But before you worry about certification, you need to make sure your app works. I haven’t talked a lot about unit testing this far, but I do here.
After all of that, you need to get the app in the Store and keep it up to date. Aside from fixing bugs, you also need to keep the app fresh so that you have happy users. This is really simple using Visual Studio, but I go over it in this chapter.
Testing Your App
No unit testing or code analysis template for JavaScript apps in Visual Studio exists. Testing is a “bring your own” experience.
That being said, you still have to test your apps. Just clicking through the app before you send it off to the Store is not enough, but it does have to be part of the testing process.
Because there isn’t any unit-testing project type in the JavaScript projects, you need to come up with auxiliary options.
Old-fashioned testing
One of the tricks I’ve come up with is testing JavaScript with JavaScript. It isn’t the optimal situation because you don’t have a testing framework, but it’s better than nothing:
1. Right-click the project and add a folder. Name it Tests.
2. Right-click the new folder and add a new Page Control.
The default name is fine.
3. Open the HTML file it created and drag all of the .js files onto the code surface next to the other .js files.
4. Add a function that does something in the main project.
This is the test method.
5. Add a button that calls the test method.
That might be as good as it gets for many projects. Without a unit test project type, you’re pretty much back to old-fashioned “Click the button to see if it works” testing.
Getting a unit testing framework
Some of the new research in Windows 8 revolves around using a unit testing framework with your JavaScript, just as if you are writing a jQuery or Node.JS project. Some of those frameworks work well with Windows 8.
For instance, take QUnit as an example. Originally created to be the unit testing environment for jQuery projects, QUnit is now a standalone project. The source can be included in a Windows 8 project, and your tests can get a lot more interesting.
To run tests using QUnit, download the QUnit file and the CSS file from GitHub (at https://github.com/jquery/qunit), and then put this into your default HTML in your tests file:
<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8” />
<title>Qunit</title>
<!-- WinJS references -->
<link href=”//Microsoft.WinJS.1.0.RC/css/ui-dark.css” rel=”stylesheet” />
<script src=”//Microsoft.WinJS.1.0.RC/js/base.js”> </script>
<script src=”//Microsoft.WinJS.1.0.RC/js/ui.js”> </script>
<!-- Qunit references -->
<link href=”/css/default.css” rel=”stylesheet” />
<script src=”/js/default.js”></script>
<script type=”text/javascript” src=”js/qunit.js”> </script>
<link rel=”stylesheet” type=”text/css” href=”css/qunit.css” />
</head>
<body>
<div id=”qunit”></div>
</body>
</html>
<tip>
Make sure the script source matches.
This gives you a reference point to start your tests. We just need to insert a test into the Windows 8 code. A test looks like this, from the sample website:
app.onactivated = function (args) {
if (args.detail.kind === activation.ActivationKind.launch) {
if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
test(“hello test”, function () {
ok(1 == “1”, “Passed!”);
});
} else {
// TODO: This application has been reactivated from suspension.
// Restore application state here.
}
args.setPromise(WinJS.UI.processAll());
}
};
QUnit gives you a nice output on the HTML page, just like Figure 14-1.
I had to comment out line 1021 of the QUnit.js file because it failed a security requirement of Windows 8. This might not be the case in the final version.
Clearly you need to write tests that work with your code, but QUnit is a good start. You can find more information at qunitjs.com. For more about unit testing, I recommend James Bender’s excellent Professional Test Driven Development with C#, published by Wrox. It’s in C#, but the concepts are as sound as they come.
Verifying runtime behavior
There are some things that unit tests can’t fix. The first and most significant is the apps interaction with the user. Windows 8 is all about the user experience, and that is just hard to unit test.
First, you need to manually check all of the possible activations of the app. Just clicking the tile and launching isn’t good enough. There are lots of ways to launch an app.
If your app is a search target, run a search from another app and launch your app from there.
If your app is a share target, check to make sure every share type that you support works as expected. This means you will have to go get a lot of apps that make the kind of output that your app shares and test them. Don’t forget to test all features both from suspension and from a cold start.
Click the tile, but that’s kind of a given. Just testing from F5 in Visual Studio ain’t good enough.
Check to make sure secondary tiles work as expected. Lay down secondary tiles from every page in the app that supports them, and make sure the app launches as expected.
If you have registered for a protocol, like handling irc: or something, activate your app from a link.
Do you have Toast notifications? Launch your app from them.
Finally, if you have any file registrations, or are using the File Picker contract, make sure clicking a registered file type launches your app in the correct state.
Now that your app is running, the next check is to test all of the interactions with Windows 8. All of the contracts, charm commands, animations, and anything that uses something in WinRT basically needs to be checked.
Check all of the contracts. Anything that you have declared in the package.appxmanifest should be checked against as many different apps as you can get your hands on.
Look at your tile. Are you updating it with WNS or within the app? Make sure it works as expected. Reboot the machine, and make sure it is there.
Check all of the possible views. Use the emulator if you have to and check every resolution. Test snapped and filled view in all resolutions. Then rotate it all four ways.
Make certain that all of the expected touch features work. Check the app bar on every page. Check the Settings flyout. Make sure you don’t override the Charms bar on every page. Test every control on every page with touch, pen, and mouse.
Make sure the sound works. Try it on every device you can. If you are using feedback sounds, make sure the app still makes sense if the device is muted.
Turn off the networking and make sure the app still works, or at least fails gracefully. Assure yourself that the roaming profiles, if you are using them, have a fallback position and still work without a network.
Check every animation. Look at them in snap and fill view. Make sure they work when the machine is busy doing other things. Make sure that long-running animations work if the user rotates the screen while the animation is playing.
Is the app responsive? Remember, the fast and fluid rule of Windows 8 is taken very seriously by the testers. The app should respond instantly to any user interaction.
Enter junk into the app and make sure it fails gracefully. Let your cat walk on it. Touch where you aren’t supposed to. Upload corrupt files. Make sure your error-handling works.
Assure that your app meets the baseline for accessibility. Test it with the magnifier and the screen reader. Test speech input.
Change the base language of your machine and make sure the app still works. The Store is global. Change your time zone. Change your date format. Use a virtual machine if you have to.
Finally, if you want to allow people that use the ARM architecture (the lightweight mobile chip that runs Windows RT devices) to use your app (and I would recommend that), test it on an ARM device. The emulator doesn’t seem to support that yet, but maybe it will by the time you read this.
Verifying lifecycle
If your app’s process lifecycle management (PLM) doesn’t meet the standards, it will get you tossed from the Store. The Certification Kit (which I cover in the next section) tests some of this, but it will be manually tested, too.
The first thing you should do is to check suspended status. Launch your app from the tile, switch to another app, and then switch to the desktop. Run the Task Manager, and click View⇒Status Values⇒Show Suspended Status. It will look something like Figure 14-2. Watch your app suspend. Make sure the memory footprint reduces.
Figure 14-2: The Task Manager with suspended apps.
Then switch back to your app by swiping from the left (you might have to swipe a few times). Make sure the app resumes gracefully. You can keep the Task Manager on in the foreground and watch the suspension go away, and make sure the resources go back.
Test termination, too. In the Task Manager, right-click on the app and select End Task. Make sure it terminates. Then go back to the Start screen and start the app. Make sure it resumes gracefully. It doesn’t nave to restart the user on the same page they ended on, but it shouldn’t completely forget everything that has ever happened.
Finally, make sure the app does everything is it supposed to do when it isn’t running. Terminate it from the Task Manager and then check the tile, Toast, and any background tasks you have coded for. Do they still work? Do they behave as expected?
There is more about the PLM in Chapter 11. Test it well. Microsoft will.
The Windows App Certification Kit
The WACK, as the Windows App Certification Kit is called, is a tool provided by Microsoft to run the kinds of tests that your app will go through in the certification process. When you think your app is ready for the Store, be sure and WACK it first!
The WACK is basically an automated test suite that runs your app a few times on what amounts to a baseline computer (virtually, of course) and looks at a few things. Specifically, it tests whether
All interactions with Windows are recorded in the package.appxmanifest file
Your app is localized for all languages you say you support
Your app recovers if it crashes
You are still in debug mode
The package is encoded correctly (in other words, that it’s not corrupt)
The performance eats the processor
You use any disallowed APIs
All of the security specifications are followed (learn more by running WACK)
Running the Windows App Certification Kit is pretty straightforward, but there are a few tricks:
1. Run WACK by pressing the Windows button and typing Windows App — it’s probably the only app named that on your machine.
2. On the startup screen, click Validate Metro Style app.
It might be called something a little different by the time you read this, but you don’t want to click Desktop Application.
3. After the app has surveyed the WinRT apps on your system, you’ll get a list of them like Figure 14-3.
Check the ones you want to check — I am testing ToDoToday, which is the original name for POINTtodo.
Figure 14-3: Selecting your app for testing.
4. Click Next, and go get a cup of coffee.
WACK runs your app a number of ways. You’ll see the screen flash a lot — don’t interact with your app. Sometimes it will take a long time to run the test. Just be patient. It will come back.
You will also see the console a number of times. Wow, this really does take a while. Eventually, the tests finish and prompt you to save an XML file.
5. Save the XML file someplace you can find it.
This is the file you upload later to show that you have passed the basic tests. That doesn’t mean you will pass app certification, however.
6. Next you get your result — Pass, Fail, or Warning. This screen has a link to the results. Click it.
My app failed because of a known bug in the current version of WACK. It shows nearly all apps as being in debug mode, even when they aren’t. That will likely be fixed by the time you get the tool.
Manually Checking Windows Store Style
In the early stages of Windows 8 app building, to get early placement in the Store, you had to meet personally with a Microsoft engineer. They used a manual checklist to walk through the user experience points of an app to make sure that all of the bases were covered.
Given the possibility that this list might go away, I’ve paraphrased it here. I found it useful in designing the POINTtodo app, and in designing this book, for that matter.
Scenario
• Has a clear mission and scope; implementation is far enough to represent the final scope
UX Polish
• Follows Windows Store style principles
• Conveys brand and purpose
• Follows a consistent layout and alignment
• Leverages typography and whitespace, and follows a font hierarchy
• Embraces Windows 8 personality
• Designed for a great first impression
• Animations are purposeful, create continuity, and convey confidence to the user
• Designed for touch
User Experience: Controls, Navigation, Animation
• Content is primary navigation mechanism
• Makes appropriate use of the app bar
• Makes appropriate use of commanding surfaces and respects the edges
• Displays unobtrusive, meaningful, and actionable error-handling
• Leverages Semantic Zoom appropriately
User Experience: Views & Form Factors
• Supports landscape and portrait views
• Adapts to different form factors and aspect ratios
• Handles snapped, filled, and full view states
• Pans and scrolls in single axis to create sense of stability
• Is functional and feels natural on a system that has only a mouse or keyboard
• Is functional and feels natural on a system that uses an onscreen keyboard
User Experience: Settings
• Implements Settings charm and does not have settings and preferences anywhere else in the app
• Roams user settings and user state
• Has a great sign-in/sign-out experience
User Experience: Contracts
• Implements search contract
• Implements share target contract
• Implements share source contract
• Has beautifully branded contracts UI
• Leverages file pickers
User Experience: PLM
• Handles PLM states appropriately
• Makes appropriate use of background tasks
User Experience: Networking
• Behaves well while offline and while on intermittent network connectivity
User Experience: Tiles and Notifications
• Has a beautiful, branded tile
• Has a live tile or a secondary tile
• Uses Toast notifications for time-sensitive, relevant information
• Properly handles activation from contracts, secondary tiles, and notifications
Store
• Expected to pass the Windows 8 App certification requirements.
• Passes the Windows App Certification Kit (WACK) tests
Performance
• UI is always responsive and provides visual feedback on interactions
Performance: Animation
• Sustains 60 frames per second
Performance: Lifecycle
• Optimize your suspend and resume handlers
• Suspends and resumes in allotted times
Performance: Cache and Local Data
• Rely on local, packaged content as much as possible
Performance: Startup
• First page must load in less than five seconds.
• Take advantage of bytecode caching
Performance: Memory
• Manages its memory working set to desired targets
Performance: Network
• Manages network resources appropriately
Performance: Background Tasks
• Respects allotted timeslots assigned by background tasks
Other
• Is accessible
• Is localized
All of these are things that more or less have to be tested by looking at the app, and that’s exactly how it is done.
Pushing to the Store
In order to push your app into the Store, you start with a developer account. After registering for this, you can upload your package and submit it for testing. After the testing process and anything that goes with it, your app is made available in the Store.
Registering for a developer account
If you don’t already have one, you will need to register for a developer account. You can register for an account — or log into your existing account — right from Visual Studio. In the Project⇒Store menu is an Open Developer Account item. Click that to be taken to your web browser.
You start at the Developer Portal, where your Live account information is shown to you to confirm that is the information you want used. If you are using a browser other than IE10, you might need to log in first. Click Continue.
On the next screen, you need to add a little information to your Live account (I needed to update my phone number). At the bottom is an important step — you choose your publisher name. This is what will be shown when the user installs your app, so it is important for the overall branding scheme.
Next you will see the developer agreement. Read it. I am not going to put it all here because it is long, but you need to actually look through it. For instance, the fee information is there:
“You will pay Microsoft a Store Fee for each of your apps that Microsoft makes available through the Windows Store. Microsoft may deduct and retain the store fees you owe Microsoft from any amounts it receives from customers for those apps. You will also pay any Store fees that Microsoft does not deduct, within five (5) days after you receive a written request. The Store Fee is the percentage of Net Receipts that is retained by Microsoft as a fee for making your app available through the Windows Store. That percentage is 30%, unless and until your app takes in total Net Receipts of USD$25,000, after which time the percentage is 20% for that app.”
That information doesn’t show up very many other places.
After this, you need to part with some hard-earned cash. There is a fee for setting up the account, to prevent people from doing it willy-nilly. As of this writing, the fee was $49 USD, although early adopters got a code to get it for free. I still had to give them a credit card number, though.
You’re done. If you wish, you can set up the account to send payment directly to your checking or savings account. You can also go straight to the dashboard and get started registering your app.
Submitting an app
The dashboard is shown in Figure 14-4. From here, you can submit new apps, see how people are using your apps, and check out how much money you are making. Also, under the Profile heading, you can set up your payout account as promised.
More important is getting ready to submit your app to the Store. You have a multistep process to go through before you even upload the app. The single most important thing you can do, however, is reserve your app name.
Your app name
App names are unique. If you code up a name in your app and your Tile and whatnot, and then find out it isn’t available when you go to submit, you’re going to be in bad shape.
You have a year to submit an app after you have reserved a name. Use it. Register your name right away, as soon as you think of the idea, and then take your time coding. The name is important.
Figure 14-4: Your app dashboard.
Selling Details
In the Selling Details section of the dashboard, you get to pick a price. Of course, one option is free, but what fun is that? (I cover making money with your app in Chapter 16). Other than free, you can set the app price to as low as $1.49, as high as $999.99, or at any 50-cent increment in between. You also get to set a free-trial length, which I discuss in Chapter 16.
That’s not awesome. What’s awesome is Figure 14-5, where you can set the markets in which your app is available. I set the price for POINTtodo at $1.99 USD and Microsoft helpfully points out that in Belgium I’m charging 1.69 euros, in Denmark it is 12 kroner, and in Columbia, it will be 3,500 of whatever Columbians use for money.
Figure 14-5: The app store calculates cost in other markets.
Just set your checkmarks in the markets in which you want your app to be made available. Note this: You had better be ready to support the languages of other countries you choose to be marketed in! In POINTtodo, for instance, I have to make sure I support right-to-left reading order if I pick something like Hong Kong (where it will be 16 Hong Kong dollars). I love technology.
At the bottom of the Selling Details page, you have a few more items to deal with:
Release date
App category and subcategory. This is important because it represents where you set yourself up on the Store.
Minimum DirectX Support
Minimum RAM
Accessibility requirements — are they met?
Advanced Features
In the Advanced Features section, you set up push notifications, Live Connect services, and in-app offers. I cover in-app offers in Chapter 16, so here I focus on the first two. And as it turns out, there isn’t much you need to do on the site, either — most of this work has to be done in Visual Studio.
The most significant thing that you need in order to make use of WNS and Live Services is the Package Security Identifier and the Client Secret. These are used by the Windows 8 app to authenticate with the services.
To get the Package Security Identifier and the Client Secret, just click the Push Notifications and Live Connect services info link, and then click Identifying Your Service.
Age Rating
As part of the app profile, you get to select an age rating. Now, this age rating is for appropriateness, not necessarily functionality. For instance, POINTtodo can be rated as Suitable for Young Children even though no reasonable three-year old needs a task list. Realistically, unless you are targeting children, use the 12+ setting.
Here are the options, right off the site:
3+, Suitable for Young Children: These applications are considered appropriate for young children. There may be minimal comic violence in nonrealistic, cartoon form. Characters should not resemble or be associated with real-life characters. No content should be frightening, or contain nudity or references to sexual or criminal activity. Apps with this age rating also cannot enable features that could access content or functionality unsuitable for young children. This includes, but is not limited to, access to online services, collection of personal information, or activating hardware such as microphones or webcams.
7+, Suitable for Ages 7 and Older: Apps with this age rating have the same criteria as the 3+ applications, except these apps can include content that might frighten a younger audience and can contain partial nudity, as long as the nudity does not refer to sexual activity.
12+, Suitable for Ages 12 and Older: Choose this rating if you are not sure which age rating to select for your app. Apps with this age rating can contain increased nudity of a nonsexual nature, slightly graphic violence towards nonrealistic characters, or nongraphic violence towards realistic human or animal characters. This age rating might also include profanity, but not of a sexual nature. Also, apps with this age rating may include access to online services, and enable features such as microphones or webcams. Can also include more profanity than is allowed in a 7+ app, but the profanity cannot be sexual in nature.
16+, Suitable for Ages 16 and Older: Apps with this age rating can depict realistic violence with minimal blood, and they can depict sexual activity. They can also contain drug or tobacco use and criminal activities, and more profanity than would be allowed in a 12+ app, within the limits laid out in Section 5 of the certification requirements.
Notice that you can’t have adult content (17+) in a Windows Store app. Sorry.
As part of the age certification, certain countries require rating certificates. You can upload those on this page.
Cryptography
I haven’t covered the topics of security and risk in this book very much. They are complex, in-depth topics that have a lot of variables and matter different amounts to different markets, people, and apps.
So if you have found that you need to encrypt something other than password encryption, copy protection, authentication, digital-rights management, or using digital signatures, you need an ECCN for your app. The ECCN is an Export Control Classification Number. It classifies items for export to countries with different standards for content than the Unites States. For more information, go to the Bureau of Industry and Security website at www.bis.doc.gov/.
Packages
Finally, you get to upload your package. If you haven’t finished coding or testing, this would be a good time to stop and take stock of the situation.
If you have finished, you are ready to go. You can drag the package file to the fine input type field that Microsoft chose to use, or you can just use Visual Studio to do it. Because you have to use Visual Studio to create the package, and it will upload it for you as well, I’m just going to focus on that.
1. In the Project⇒Store menu, select Create App Package.
2. Select Yes in the dialog box that asks about creating a package.
3. Sign in if requested.
4. Select the app for which you are building a package.
5. Set the version and build configuration.
6. Click Create.
If you get an error about your temporary key, you may have not yet created a certificate for your project. Check out http://go.microsoft.com/fwlink/?LinkID=241478 about certificates, if you need to work on that — it was a struggle for me and I’m very familiar with public key cryptography and code signing. I hope Microsoft makes the process easier by the time you get to it.
Anyway, when you are done uploading — from the site or Visual Studio — you’ll get notified by the portal. You’re almost done.
Description
Now you get to write a little marketing copy. If you go to the Windows Store and click on any random app, you can see what goes in the Description field. This text is really the one and only thing that will make people look twice at your app. Don’t skimp here.
In fact, if you aren’t of the writing bent, get a writer to write for you. (If you get this far into the book, then shoot me an e-mail. I might write your description. You never know.) But either way, make it good. You may think your app is good and it can stand on its own, but I promise you that no person will ever download it if the description isn’t good.
Here is POINTtodo’s description:
The problem with a task list is that it isn’t ever done. You never get that sense of completion, that feeling of having gotten your work done for the day.
Task managers, on the other hand, are so complex. Outlook and the like have due dates and importance ratings and whatnot. You have to put in a task just to manage your tasks every day.
Enter POINTtodo: the task list for the rest of us.
With POINTtodo, you keep two lists. One of them is that endless Honey-do list that you won’t ever want to think about, but have to. The other is what needs to get done today. Just today — don’t worry about that other list.
Spend three minutes every morning moving a few tasks from the Later list to the Today list, and then tack on a few other urgent matters, and your day is planned. That easy.
It’s not Shakespeare, but it is easy to read, is light on technical details, and gets all of the important details across. If you started well and got a solid design to your app, writing a compelling description should be easy. If not, well then, much luck to you!
Notes to testers
Finally, you get 500 characters to tell the testers what to look for. Don’t get flowery — 500 characters is not a lot.
Most important, give the Windows Store testers a test account, if you have user account management, and tell them how to get into locked features, if there are any. Also, make certain any external service or asset to the app is available when you submit it.
A real human reads this and runs your app, and then makes a decision about whether you get into the Store. Don’t blow this part off. Stop and think about it. I’ll wait.
Surviving testing
Once all of this is done, your app goes to testing, and you wait. When it comes back — usually around a week later — it will be either passed and waiting to get into the Store or failed and waiting for you to fix it. There are a select number of failures you might get, and solutions.
Digitally signed file test: Tests executable files and device drivers to verify they have a valid digital signature.
File-encoding test: Tests the contents of app packages to make sure they use the correct file encoding.
Install-uninstall test: Installs and uninstalls the app and checks for residual files and registry entries.
Launch and suspend performance test: Tests how quickly an app launches when the user starts it and how fast it suspends when the user switches to another app.
Windows Store–style app-manifest test: Tests the contents of app manifest to make sure its contents are correct.
Multiuser session test: Tests how the app behaves when run in multiple sessions at the same time.
Restart manager message test: Tests how the app responds to system shutdown and restart messages.
Safe mode test: Tests if the driver or service is configured to start in safe mode.
Test for apps that crash and stop responding: Monitors the app during certification testing to record when it crashes or stops responding.
Test for changes to Windows security features: Verifies that the app uses the Windows security features and strong ACLs.
Test for correct folder use: Verifies that the app writes its program and data files to the correct folders.
Test for debug apps: Tests the app to make sure it is not a debug build.
Test for use of APIs for Windows Store–style apps: Tests the app for the use of any noncompliant APIs.
Test for use of Windows compatibility fixes: Verifies the app doesn’t use any Windows compatibility fixes.
Test of OS version check logic: Tests how the app checks for the version of Windows on which it’s running.
Test of resources defined in the app manifest: Tests the resources defined in the app manifest to make sure they are present and valid.
User Account Control test: Verifies that the app doesn’t need unnecessarily elevated permissions to run.
Windows platform support test: Tests the app to make sure the .exe is built for the platform architecture onto which it will be installed.
To fix any of these failures, just remedy the situation in the description. Honestly, the e-mail that comes back from Microsoft (at least, the one that came back in my case) has specific instructions on fixing the app and getting it back into testing.
Managing Your App’s Existence
After your app is in the Windows Store, you will want to keep tabs on the way it is used, how much it is being used, and any problems or errors. Microsoft’s management experience is second to none, so you should find this very straightforward.
But so you know before you get in there, the dashboard gives you a very good set of stats on some of the following topics:
Downloads by age group and market
Ratings and reviews
Conversion (views to downloads)
Listing views
Usage per day (isn’t that awesome?)
In-app purchases by age and market
There is also an extensive quality metric, which drills down to some serious statistical usage data that you never used to get with Windows apps:
JavaScript exception rate
Crash rate
App unresponsive rate
These values are very important for improving the experience over the app’s lifetime. Even though you might put out bug-free code, the WinRT library will change, and there will be environments that you didn’t test on. It’s good to be prepared, but even better to be informed. The Windows Store does a great job of informing you about the experiences users are having with your app.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.