Hybrid apps (apps that include native content and web content) are becoming more popular by the day. One question that naturally follows development of a hybrid app is “What’s the agent string so I can track it?”
Unfortunately there isn’t as simple one line answer to this question because of the way our platform has evolved over time. On the phone, for example, we send manufacturer and model information about the device in use. But beyond hardware we’ve also had an evolution in development platforms. At our //Build conference this year we announced the new Universal App model, which more or less allows you to run Windows 8 apps on your phone. In most cases this supersedes the classic Silverlight model but we still need to let web sites know the environment they’re running in so that they can tailor their experience accordingly.
Below is a list of agent strings for our current OS’s and dev platforms as of 5/14/2014. When this changes in the future I’ll try to come back and update this post. I’ve highlighted the changes in the agent strings for each scenario as compared to the “traiditional” mode for that platform. Below the agent strings you’ll find more notes about special cases and I even include bonus information at the end on how to test your site for Windows Phone using only your desktop browser!
IE Traditional (Desktop) Mode
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
IE in "Modern" Mode
Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; Touch; rv:11.0) like Gecko
Universal App WebView (C#)
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; WebView/2.0; rv:11.0) like Gecko
Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; Touch; MSAppHost/2.0; rv:11.0) like Gecko
Windows Phone 8.1
IE in Traditional (Mobile) Mode
Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; <manufacturer>; <model>) like Gecko
IE in Desktop Mode
Mozilla/5.0 (Windows NT 6.2; ARM; Trident/7.0; Touch; rv:11.0; WPDesktop; <manufacturer>; <model>) like Gecko
Universal App WebView (C#)
Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; WebView/2.0; rv:11.0; IEMobile/11.0; <manufacturer>; <model>) like Gecko
Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; MSAppHost/2.0; rv:11.0; IEMobile/11.0; <manufacturer>; <model>) like Gecko
Silverlight App WebBrowser
Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; rv:11.0; WebBrowser/8.1; IEMobile/11.0; <manufacturer>; <model>) like Gecko
Desktop Mode for IE on Phone
IE on Windows Phone has an option to render sites as the desktop version under settings.
Many users prefer this mode, especially users with larger screens.
These are new to Windows Phone 8.1. Going forward, this is the mode that most developers will chose to use. Silverlight is the "classic" model in use today.
Simulating IE for Windows Phone on the Desktop
IE 11 and 12 on the desktop have the ability to simulate IE for Windows Phone pretty closely. To simulate Windows Phone IE (and use the desktop debugging tools in all their glory):
- Start IE
- Press F12
- Scroll down to the last tab in the dark bar on the left (Emulation) and set:
- Document Mode: 10
- Browser profile: Windows Phone
- User Agent String: IE10 – Windows Phone
- Orientation: Portrait
Note: These options will change going forward as IE for phone moves up in version numbers.
If you were nice this year (or maybe even a little naughty), Santa and his elves are preparing something just for you. But how will you know when jolly old Saint Nick leaves the north pole? And how do you know what time you need to be fast asleep? With Where is Santa for Windows Phone and Windows 8 of course!
So grab the apps and a cup of hot chocolate. Set out the cookies and watch to see when Santa is on his way to see you!
The Problem with Ratings
It’s no secret that apps with higher ratings (and more of them) receive better placement in the store. Better placement means more downloads, and more downloads means more money. But part of the problem with ratings is that people rarely think about doing them. And when they do, it’s usually because they’re either really satisfied or really dissatisfied. InfoSurv, a company that provides market services to companies like CocaCola, Nestle and Emerson, has this to say in their FAQ:
There is a observed response bias in customer satisfaction surveys towards the customers on either extreme of the satisfaction scale, particularly those who are very dissatisfied. In other words, very satisfied or dissatisfied customers are more likely to respond to a survey invitation than those more towards the middle. The best way to combat the resulting “polarization” of customer survey data is to assure the maximum survey response rate possible, thus capturing more of the ambivalent customers and making the customer survey responses more representative of the overall customer base.
So as app developers we have to solve two problems: 1) Getting more users to rate our apps and 2) Finding happy customers.
Solving the Rating Problem
Obviously it doesn’t make sense to ask someone for a rating on the first application run – the user wouldn’t know what to say! On the other hand, if a user continues to use an app over time we can infer that they’re getting value out of the app. Therefore it’s repeat users who we want to ask for ratings.
With that in mind, a rating reminder should:
- Keep track of the number of times the application has been run. – It helps us find happy users.
- Keep track of whether the user has already been asked to rate the application. – So we don’t keep bugging them if they’ve already rated or said they don’t want to rate.
- Bonus: Keep track of the number of days since an application was installed. – Valuable for short-lived or seasonal applications. For example, a Christmas application might want to remind after two days regardless of usage since after December 25th they won’t use it again for a year.
- Bonus: Have the ability to display the reminder in the local language. – Important for applications that support multiple languages.
The code to implement these features isn’t overly complex but it does involve several components (storage, dialogs, marketplace APIs, localization, etc.). It’s also boilerplate – meaning it’s the same across applications. That makes it a great candidate for being factored into a library.
App Promo is a tiny control library for Windows Phone and Windows 8 created to help with promoting applications. Right now it contains one control – RateReminder – and by now you probably have a good idea of what it can do for you.
RateReminder has four main properties:
- RunsBeforeReminder – The number of application runs before the reminder will be displayed. The default is 7.
- DaysBeforeReminder – The number of days before the reminder will be displayed. The default is zero (disabled).
- TryReminderOnLoad – true if the control should try to show the reminder as soon as it’s loaded; otherwise false. The default is true.
- CustomReminderText – The customized reminder message to display to the user. The default is null (which means the control will use its built-in localized message).
As you can see, RateReminder is configurable but its default settings mean you can drop it on your main page and forget about it. And since App Promo is available as a NuGet package, there’s no reason not to add it to your app today!
Using App Promo
Let’s take a look at how to add App Promo to a project. I’ll be showing App Promo for Windows Phone, but the steps are the same for Windows 8 (just using a different NuGet package).
- Before we get started we need to make sure you have NuGet installed. In Visual Studio click on Tools –> Extensions and Updates. If you see NuGet in the list you’re already set. If not, type NuGet in the search box and install it (a restart of Visual Studio will be required).
- Next we need to install the App Promo NuGet package. You can do this through the Package Manager Console but I prefer to use the GUI. In Solution Explorer, right-click on your project and choose ‘Manage NuGet Packages’.
- Make sure the ‘Online’ branch is selected on the left and type ‘AppPromo’ (no spaces) in the search box.
- Click the ‘Install’ button next to App Promo for Windows Phone 8 (or for Windows 8 if you’re building a Windows 8 app) and when the installation completes, close the NuGet window.
- Expand the toolbox if it’s not already expanded, then right-click and select ‘Choose Items…’. In the window that pops up, click the ‘Browse’ button.
- Navigate to your project folder, then to packages –> AppPromo.WP8.#.#.#.# (or AppPromo.Win8.#.#.#.#) –> lib –> wp8 (or winrt45).
- Double-click on AppPromo.WP8.dll (or AppPromo.Win8.dll) and click OK. The RateReminder control should now appear in your toolbox.
- Drag the RateReminder control onto the first page of your application (this is usually MainPage.xaml or GroupedItemsPage.xaml).
NOTE: The RateReminder control is completely transparent and has no appearance. You’ll want to remember where you placed it or use Xaml view or Document Outline if you need to select it.
- Optional: Change the number of runs (default 7) or the number of days (default 0 – disabled).
- You’re done! You just added a rating reminder to your application.
NOTE: App Promo has been added to your project but NuGet can’t add the control to your toolbox. We need to do that before you can drop it on your page.
Testing the RateReminder Control
Testing the RateReminder control is easy. Just remember that the application has to be closed and re-launched in order to be considered a “run” (otherwise the user is just fast switching). In Visual Studio you can quickly simulate a close and a re-launch using the Restart button:
If you don’t have Visual Studio attached you can use the phones hardware Back button to leave the app and then launch it again. For Windows 8, use the Reset button above or drag the window to the bottom of the screen to close the app between runs.
Important Note!: On Windows 8.1 apps are not actually closed unless you hold them at the bottom of the screen until they flip over (about 3 seconds).
After 7 runs (or however many you configured), the rating reminder will be shown:
Tapping OK will display the rating page if the application is already in the store. Otherwise, you’ll see an error message telling you that the application is not currently available.
RateReminder provides a small amount of usage statistics through the TryReminderCompleted event (if run automatically on load) or through the asynchronous result returned from TryReminder (if called manually). Both return an instance of the RateReminderResult class, which provides the following usage statistics:
- Runs – The number of times the application has been run since it was installed. This count is only calculated if the runs reminder is enabled and hasn’t already been shown.
- Days – The number of days that have passed since the app was installed. This count is only calculated if the days reminder is enabled and hasn’t already been shown.
- ReminderShown – true if a reminder was shown on this attempt.
- RatingShown – true if the user accepted the reminder and the rating interface was shown on this attempt.
The source code includes a sample that displays usage statistics. It’s important to note that the counter will read zero after the reminder has been shown. This is to avoid the cost of reading and updating settings after the reminder has been displayed.
The counters can be reset by calling the ResetCounters method on the RateReminder control. This will cause the reminder to be displayed again, which may be desirable after the application has been upgraded to a new version.
App Promo has been translated into more than 35 different languages, but it’s important to know that your app must also be localized for these languages to be shown. This is because the resource loader tries to be as efficient as possible. For example, when your application is run on a device set to Spanish, the resource loader will look for Spanish resources in your application. If it doesn’t find them, it won’t continue to look for Spanish resources when it loads the App Promo library.
Localizing your application is beyond the scope of this article, but as soon as your app is localized App Promo will show up as localized too. By far the easiest way to localize your application is using the Multilangual App Toolkit. This article is one of the best written guides I’ve found, and the Introduction and Testing videos are both excellent resources for getting started quickly.
The source code for App Promo is available on on GitHub and includes two sample applications. Don’t forget that App Promo is already ready-to-use on NuGet. Here are direct links to the Windows 8 and Windows Phone 8 packages.
I’d like to extend a special “Thank You” to my co-worker and friend Paul DeCarlo. Paul created the NuGet packages for App Promo and he’s got a lot of experience when it comes to marketing Windows Phone and Windows 8 apps. I highly recommend you check out his blog post on Monetizing your app with AdRotator.
From the app description:
"App Enthusiasts showcases applications created by developers around the world on Windows Phone and Windows 8. Stay up to date with the coolest creations by students, indie developers, and companies in your area. App Enthusiasts can filter apps by region, country, state and city, and it even keeps track of the apps you’ve seen across all of your devices! Microsoft employees are using App Enthusiasts to showcase apps at local events around the world, so if you’re interested in having your application promoted or if you’d like to find out about Enthusiast events in your area, please email AppEnthusiasts@Microsoft.com."
What is exciting is that App Enthusiasts is more than just an app, it is a movement to bring visibility to applications created by Windows Phone and Windows 8 devs. Microsoft field employees are planning to host events at Microsoft retail stores across the U.S. At these events, developers featured in App Enthusiasts share their creations and speak to the audience about their inspiration. We believe that an application like this can help create a community of supportive developers and fan interest alike. I certainly suggest reaching out to AppEnthusiasts@Microsoft.com if you have an app that you would like featured in this program! Seriously, we want your best work to shine!
Let’s take a look at the app itself:
Upon launching either version of the app, the user is asked to authenticate with their Live credentials and is then greeted with a listing of applications organized by date:
Users can see at a glance what City, State, and Country an app has been published in. Upon clicking an item, the user will be brought to the download page in the marketplace for the selected app. When an item has been viewed, a checkmark appears next to the item indicating that it has been seen.
With these applications it’s really easy to discover cool apps from my region. By setting the filter to my city I was able to see creations from people in my area. From here I could easily install apps built by people I’ve actually met in the field. Being able to curate and find their work made it incredibly easy for me to provide feedback and ratings. It is a really great way for me to keep in touch with my community and help promote the Windows ecosystem. If you want to know more about the upcoming events and how to showcase your app, send an e-mail to AppEnthusiasts@Microsoft.com.
I was recently asked how to add a “Submit a Bug” feature to an app but only make it visible for Beta builds.
The code to actually send the bug was quite simple:
EmailComposeTask emailComposeTask = new EmailComposeTask();
emailComposeTask.Subject = "My App Feedback";
emailComposeTask.To = "firstname.lastname@example.org";
Now the question is where to put it. Obviously this could be triggered from a button click, a menu item, or any other control on the screen. But if we only want the item to show up on beta builds we have some extra work to do.
One of the ways I like to deal with this is by adding a new configuration to the Configuration Manager.
In Visual Studio click the Configuration drop-down and choose ‘Configuration Manager’.
In Configuration Manager, choose to create a new configuration.
Call the configuration ‘Beta’ and choose to copy settings from Release.
Click OK to close the dialog.
Make sure ‘Beta’ is selected in the configuration drop-down.
Right click on the project and choose ‘Properties’.
Switch to the ‘Build’ tab.
Add a new conditional compile symbol called BETA.
Close the project properties window and make sure you saved your changes.
Now, anywhere in the code you can use BETA as a conditional compile statement.
contactButton.Visibility = Visibility.Visible;
Now you can easily switch between Debug, Release and Beta builds using the configuration drop-down at the top in Visual Studio!
Apps can specify that they prefer portrait or prefer landscape in their appxmanifest by checking one or more boxes:
However, the app is not guaranteed to get the preferred orientation. The classic example is a game that requests portrait but is being run on a desktop machine with a monitor that cannot be rotated. The game will be forced to run in landscape instead and it’s up to the game to deal with this (e.g. letterboxing or putting content on the sides of the otherwise vertically laid out game).
At //build it was clearly stated that with 8.1 and the smaller 7” devices, most users prefer to hold the device in portrait. Of course in this scenario the device is portable and the OS knows that the device can be rotated, so if an app requests to run in landscape the OS would honor it. But be aware that it’s still possible for an app to get locked in portrait too. It’s less common but can happen. On my old desktop rig I ran dual 27” monitors where one was landscape and the other was portrait. On that machine if I ran store apps on the portrait monitor, the OS would force them to run in portrait.
In summary, you can ask for whatever orientation you want but be prepared not to get it.
For more information see the InitialRotationPreference element.
A developer contacted me just after the //build conference asking “I’m a new developer for Windows 8 coming from an iOS development environment. I was looking to purchase an inexpensive Windows 8 Tablet so I contacted [a vendor] to try to understand their offerings.” Unfortunately the vendor didn’t do a good job explaining the differences between Windows 8 Pro and Windows 8 RT. Since I know that’s been confusing from the beginning, I decided to turn my reply to this developer into a blog post that others can share.
There are three main technical differences between Windows 8 Pro and Windows 8 RT:
- Windows Pro devices use x86 or x64 CPUs (Intel and AMD) while RT devices use ARM (Qualcomm and NVidia)
- Windows Pro devices come with little or no software pre-installed, while RT devices come with Microsoft Office
- Windows Pro devices allow applications to be installed from the store and to the desktop, while Windows RT devices only allow store applications to be installed.
So RT devices have very long battery life thanks to ARM, and they can do a lot of the same things Pro laptops can do since they run the same store apps and they come with Office pre-installed. However, since RT devices don’t run x86 and since you can’t install “desktop” apps on them, you can’t install programs like Visual Studio or Photoshop.
The easiest way to summarize:
- Pro is for laptops and desktops and getting “heavy lifting” done.
- RT is for “light” work like e-mail, games, browsing, movies, fun.
You can think of RT as a direct competitor to the iPad but with a shockingly large number of features you previously had to buy up to a full laptop to get (Windows, Office, USB, ability to Print, Flash in the browser, Networking, etc.)
I hope that helps