public class EmailService : IIdentityMessageService
{
public async Task SendAsync(IdentityMessage message)
{
MailMessage msg = new MailMessage();
#if DEBUG
// Don't send actual emails while debugging, override to send emails to the sender instead.
message.Subject = "[DEBUG] " + message.Subject;
msg.To.Add(msg.From);
#else
// Production, send email -- if multiple recipients, add each recipient to BCC, else the TO line.
var emails = message.Destination.Split(';');
if (emails.Length > 1)
{
foreach (var email in emails)
msg.Bcc.Add(email);
}
else
{
msg.To.Add(message.Destination);
}
#endif
msg.Subject = message.Subject;
msg.Body = message.Body;
msg.IsBodyHtml = true;
using (SmtpClient smtp = new SmtpClient())
{
smtp.ServicePoint.MaxIdleTime = 1;
smtp.Timeout = 10000;
await smtp.SendMailAsync(msg);
}
}
}

<system.net>
     <mailSettings>
          <smtp
					from="sender@contoso.com"
					deliveryMethod="Network">
               <network
					host="smtpout.secureserver.net"
					port="3535"
					userName="sender@contoso.com"
					password="******"
					enableSsl="false"
					defaultCredentials="false" />
          </smtp>
     </mailSettings>
</system.net>
			

With Continuum for phone on Windows 10 Mobile, your phone can power an external screen allowing you to have the productivity of a PC in your pocket. Any time you connect your Continuum-capable phone to an external screen, you will be in Continuum mode.  Your phone will continue acting like a phone and allow you to use it like how you normally would while your connected screen simultaneously gives you a desktop-like experience with a desktop shell and Start menu showing on that external screen (alternatively, you can go into advanced display settings on your phone and change from Continuum to Mirror mode if you just want to duplicate what you're seeing on your phone onto another screen).  With your phone in continuum mode, your phone can support a mouse and keyboard connected to it.  If you don’t have a spare keyboard/mouse to use with your mobile device, you can use the keyboard/touchpad experience within the Continuum app on your phone to interact with external screen experience.  Any Windows 10 application you have installed on your phone can be launched on that external screen in full screen and used with your physical or virtual mouse/keyboard (unless the developer opted-out of Continuum for that app, but more on that later).   

If you're building a Windows 10 universal app, then you're probably already thinking about different screen sizes and resolutions.  If you built your app with responsive design so that it adapts to work on all screen sizes, then in most cases all of that work you already did can accrue over to your app running on Continuum for phone without any more effort on your part (with some caveats, continue reading to learn more).  Additionally, you can choose to extend your app with casting and projection APIs that can let your W10 universal apps have multi-screen experiences for your users and take advantage of an extra screen connected to your phone (more on this down below as well).  

How to enable the Continuum experience from your mobile device

The only phones that support Continuum for Phone as of TODAY are the Lumia 950, Lumia 950XL, and the upcoming Acer Jade Primo.  You’ll access the Continuum experience by connecting your phone through a display adapter (wired experience through a USB Type-C to HDMI cable or a docking device like the Microsoft Display Dock) or wirelessly through a Miracast enabled device (I recommend the Actiontec Screenbeam Pro).  Optionally, you connect a Bluetooth keyboard/mouse directly to your phone or a USB keyboard/mouse through the Microsoft Display Dock. If you don't have a keyboard/mouse to use, use can use the precision track pad and on-screen keyboard built into the Continuum app running on your Windows 10 phone to control the external screen.  Just an FYI, in case you didn’t know, if you have an XBOX One, it supports Continuum wirelessly from your Continuum-enabled phone through the Wireless Display app found in the XBOX App Store.

App requirements to run on Continuum for Phone

To run on Continuum for phone, the app must be a Windows 10 UWP app. Legacy apps (SilverLight and Win8.1) are NOT accessible in Continuum mode.  This also means your app package must be a universal package or have a mobile build (have an ARM build) in the package else you wouldn't be able to install it on your mobile device in the first place. For those of you who only want a mobile app and not target a desktop, be aware that your mobile app by default will run on Continuum's desktop. To run well on the Continuum desktop, your app or game ideally should implement responsive design to function properly on the large external screen and the app needs to work in landscape orientation as portrait orientation is not supported on secondary screens. Landscape probably isn't a concern for most apps but there are some games out there built only for portrait screens. If your app must be portrait orientated, you may want to implement your own letterboxing in your app when you detect the window your app is displayed on is wider than it is tall (i.e. the continuum desktop). If you’re traditionally a mobile app built for touch, know that the only input method of any secondary screen will be mouse and keyboard. Therefore, you’ll want to make sure your app can work without touch, which might be something new for many traditional mobile developers. 

If supporting keyboard/mouse in your app is not doable, or just don’t want your [mobile] app running in landscape or a larger screen off the phone, you will want to explicitly opt-out of Continuum and disable your mobile (ARM build) app from running in Continuum with the following extension in your app manifest:

<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
         xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
         xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
         xmlns:mobile="http://schemas.microsoft.com/appx/manifest/mobile/windows10"
         IgnorableNamespaces="uap mp mobile">

  <Applications>
    <Application ...>
      <Extensions>
        <mobile:Extension Category="windows.mobileMultiScreenProperties">
          <mobile:MobileMultiScreenProperties RestrictToInternalScreen="true"/>
        </mobile:Extension>
      </Extensions>
    </Application>
  </Applications>

In the future, if you want to have your app opt back in to Continuum, you can just change the RestrictToInternalScreen property to FALSE and your app will be allowed to run on Continuum for phone. 

UI architecture considerations

Apps that have pages that implement responsive design techniques in theory shouldn't have to do anything else to run well on continuum for phone.  Where developers might get themselves into a little trouble is if they heavily lean on tailored layouts that are device family specific implementations (device family specific implementations of a page/control) for their UI.  With tailored layouts, you’ll want to make sure you explicitly test your app on a device with Continuum as your users may face some unintended UX experiences. The main “gotcha” that you should be aware of is that when running your application on Continuum for phone, despite it looking like a desktop, the DeviceFamily property is still “Mobile” and not “Desktop” as one might think.  As a result, if you did implement tailored views and separated phone and desktop UX (i.e. MainPage.DeviceFamily-Desktop.xaml and MainPage.DeviceFamily-Mobile.xaml), know that your desktop optimized UI won’t be seen by users running the app on the Continuum for phone desktop because it’s not actually desktop device family.   

To overcome this, and minimize effort on your part to handle all screen sizes PLUS continuum for phone, here are several paths that you can take as a developer:

1. As a best practice, you ideally should stick with AdaptiveTrigger through visual states and the VisualStateManager to handle different screen sizes as much as you possibly can over tailored layouts.  You’ll handle all screen sizes, no matter what device family, without redundant code going this route.
2. If you must implement tailored layouts for your UX, do your best to replicate all or some or implement some kind your responsive design for larger screens from within your mobile specific page so that your mobile app running in continuum isn’t a poor experience. One way you can tell if you’re in continuum mode from a mobile device is if your screen resolution larger than 800x600 effective pixels (EPX). Anything equal or less, assume it’s on the phone screen.  Another way you can know you’re on continuum is by checking the UserInteractionMode.  On the phone it will be a value of “Touch” but on the desktop thru Continuum for phone it will be “Mouse”.  Be careful with using this property as it can be either value on a desktop family depending on whether or not the user is in tablet-mode or not. So to definitively know your app window is running on Continuum for phone's desktop, you can check UserInteractionMode equals Mouse AND Device-Family is equal to "Mobile". To assist with that, I've created a custom visual state trigger you can have in your solution that can check both and allow you to do UI customizations all in the XAML layer and through visual states. This can help you simplify your XAML and prevent you from having to check multiple values in code behind thus complicating your code. See below for sample implementation of such custom adapter.
3. Instead of using the tailored view qualifier naming convention (i.e. [PageName].DeviceFamily-[FamilyName].xaml) you can handle displaying the appropriate page yourself. Prior to navigating to page, you can do an if/then on the screen size and then choose which page to show. You won’t use the free convention built into UWP but this will give you complete control and let you have different UX for device families while not having to duplicate your desktop design to mobile just for Continuum.

    public class ContinuumMobileExecutingTrigger : StateTriggerBase
    {
        public ContinuumMobileExecutingTrigger()
        {
            this.UpdateTrigger();
        }

        private Page _target;
        public Page Target
        {
            get
            {
                return _target;
            }
            set
            {
                if(_target != value)
                {
                    if(_target != null)
                        _target.SizeChanged -= Page_SizeChanged;
                     _target = value; 

                    if (_target != null)
                        _target.SizeChanged += Page_SizeChanged;
                    this.UpdateTrigger();
                }
            }
        }

        private void Page_SizeChanged(object sender, SizeChangedEventArgs e)
        {
            this.UpdateTrigger();
        } 

        private void UpdateTrigger()
        {
            if (UIViewSettings.GetForCurrentView().UserInteractionMode == UserInteractionMode.Mouse && AnalyticsInfo.VersionInfo.DeviceFamily.Equals("Windows.Mobile", StringComparison.CurrentCultureIgnoreCase))
                this.SetActive(true);
            else
                this.SetActive(false);
        }

}

Considerations for enhancing your app experience when a second screen is available

With your phone having access to a second screen, or any other Windows device connected to more than one screen, you may want to consider extending your app experience and implement a second-screen experience via the ProjectionManager API. Here are a few examples of what you can do with this capability:

• PowerPoint already leverages this to show slides on one screen but then presenter view/notes on the other
• You have a Fantasy Football app where your drafting on your phone while projecting the draft board on a big screen for all others in you draft party to see
• You’re a DJ on your phone (or laptop/tablet) managing the playlist while at a party while displaying current song info or visualizations on a large connected screen
• You’re playing a board game with friends, such as Scrabble, where your letters are shown on your phone and the game board is shown on the second screen. You could even leverage Bluetooth/WiFi direct APIs to enable other devices to connect to your device and play in your game and the projected game board and their own mobile device shows the letters they have.
• You can have a game and the main visuals are shown on a bigger connected screen and your phone then can be a controller and/or have an additional game experience simultaneously on the phone screen, like a map of where you are.

You can detect if your device is connected to a secondary screen through the ProjectionManager API. This API will tell you if there is a connected second screen and if you can launch an additional window onto that screen to enable the second-screen experience in your app.  You can use the same custom trigger displayed above to help optimize your UI based on where the window is executing and tailor the view accordingly for size and input. Or potentially use the same to limit or block content on the second screen such a media content that might have licensing restrictions on screen size, etc.

If you do decide to leverage ProjectionManager in your application, be sure to read the guidelines for projection manager.

Other caveats and considerations for running on Continuum for phone or multiple-screens from a desktop family

• Continuum for phone only works on 1 additional screen. ProjectionManager APIs for desktop, however, can support more than 1 additional screen.
• You can't run two instances of the same app one on each screen. If you launch an app on the phone and then go to START and launch the same app on the secondary screen, the app instance from the phone will move to the second screen. But you can mimic multiple instances of your application by launching the same page in the additional window instances your app can create.
• If your UWP implements multiple windows, you should know:
  • That your phone and also the secondary screen through Continuum for phone only support displaying one window on each screen
  • There is no split view of apps (multi-tasking) on either screen right now and launching a second window from the app on either screen will be another full screen window in place of the previous window (you'll see each window independently in the app switcher and the taskbar however)
  • And apps that implement multiple windows will only run be able to be viewed on the screen running the app window, if you want to have that window show up on the other screen, you'll need to launch the secondary window through the ProjectionManager API instead
  • If your app or multiple window instances are running on the Continuum desktop, when you disconnect from that external screen, secondary windows will be immediately closed and the main window will automatically be suspended, but available for re-launch from the mobile device. Though users will explicitly need to relaunch the app on their phone.
    • As a developer, you'll need to carefully think through how your app experiences continues/resumes after users disconnect continuum
    • You'll want to test your app to ensure the experience can continue when the user returns back to the app on their phone or reconnects to the external screen
  • Each screen (mobile device and secondary screen) have their own app switcher and don't see what's running on the other
  • Your app can detect whether or not an external screen is connected to your mobile device by monitoring the ProjectionDisplayAvailableChanged event from the ProjectionManager class.  Or you can use this custom trigger I created to allow you to adjust your UI when a screen is connected all in the XAML layer:

    //Detecting if your mobile app is connected to a secondary screen

    public class ContinuumMobileAvailableTrigger : StateTriggerBase
    {
        public ContinuumMobileAvailableTrigger()
        {
            ProjectionManager.ProjectionDisplayAvailableChanged += ProjectionManager_ProjectionDisplayAvailableChanged;
            this.UpdateTrigger();
        }

        private async void ProjectionManager_ProjectionDisplayAvailableChanged(object sender, object e)
        {
            await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                this.UpdateTrigger();
            });
        }
 
        private void UpdateTrigger()
        {
            this.SetActive(ProjectionManager.ProjectionDisplayAvailable && AnalyticsInfo.VersionInfo.DeviceFamily.Equals("Windows.Mobile", StringComparison.CurrentCultureIgnoreCase));
        }
    }

Conclusion

This is about everything you need to know when developing experiences to take advantage of Continuum for mobile. If you have any feedback or questions, feel free to reach out to me via the comments section of this page.

Additional resources for Continuum for phone

• Optimizing apps for Continuum for Phone
• Continuum Overview
• Continuum for Phone
• Show multiple views for an app
• Guidelines for multiple windows
• Guidelines for projection manager
• 16 shortcuts while using Continuum for Phone

1. Download and unzip the ZIP file attached to this blog post (contains the 7 Photoshop templates and an ATN file that contains that Photoshop Action definitions).
2. Import the actions file (Windows UWP v1.2 for Windows.atn OR Windows UWP v1.2 for Mac.atn) in to your Photoshop instance through the Actions pane’s settings menu.
3. Have your designer edit each of the Photoshop PSD template files. Each template file contains rulers representing all the boundaries which they should ideally adhere to (set forth by the W10 guidelines for tile and icon assets document).  In pretty much all cases, it’s recommended that you keep your logo confined to the middle 4 boxes. However, if your logo is horizontally oriented, you can leverage the 2 square areas to the left and right of the center 4. Or if your logo is vertically oriented, you can leverage the 2 square areas above and below the center 4. Not both directions. And ideally leave your logo layer as a vector based layer so that as your asset is being re-sized and exported there is no loss of quality from the re-seize. Note that these boxes created by the guide rulers are based on the tile and icons margin guidelines set by the W10 design team. Sticking to these boundaries will ensure your logo looks great everywhere within Windows. Unless you intend to have full bleed branding on your assets, which in that case you can ignore the rulers. Though I do recommend you carefully read the guidelines documentation for guidance on margins of your full bleed logos.
4. If you're using Photoshop on Windows, create a folder on your C: root drive called Images (i.e. C:\Images\).  This is the folder that the Photoshop Actions will output to.  If you're using Photoshop for Mac, files will be outputted to the /var/tmp/ folder. That folder isn't visible in Finder (the file explorer) as it's hidden by default. So to navigate to it, you'll want to use Cmd+Shift+G and manually type the path. NOTE: I know this isn't ideal, but when creating Photoshop Actions, for both Windows and PC, the Action recorder captures the full path to any folder you choose. So if I chose Desktop, for example, it'd include the logged in user's name into the path which would prevent the action from running on other machines since that user (and it's full path to that person's Desktop) would exist or be accessible. Hence why I had to use C:\images or /var/tmp/ as they can both be accessible by all users on any computer.
5. For each Photoshop template file, run the corresponding Photoshop Action (i.e. Run the Logo-TileLargeMedium.psd action on the Logo-TileLargeMedium.psd template file).
6. Copy the image files from the output folder to your Assets folder within your W10 application project.
7. Decide if you want un-plated or plated images for your logo on the taskbar and task switcher and start menu jump list. If you want un-plated, simply include all the asset images named "Square44x44Logo.targetsize-##_altform-unplated.png" in your solution and ensure your tile background color is set to transparent. If you want them to be plated, then include the "Square44x44Logo.targetsize-##.png" image files and specify a hex value for tile color in the app manifest which dictates the background color for the tiles and icons. No need to include both sets.
8. Ensure each file you want is included in your Visual Studio project and set as Content so that it can be deployed with the application.
9. Update the Visual Assets tab in the application manifest to point to the appropriate image assets set.  If you type in the name of the file without the “.scale-###.” part of the file name, it’ll automatically figure out each scaled image available in the project and show up in the manifest designer. For example, instead of selecting each image one by one for each scale size, just type in Square71x71Logo.png and it'll populate the 100, 125, 150, 200, and 400 scale images. See image:

System.Resources.MissingManifestResourceException was unhandled by user code
  HResult=-2146233038
  Message=Unable to load resources for resource file "Contoso.UI.GeneralStrings" in package "d1c46561-bf90-4e62-9e4f-e2c1f3fe0fd1".
  Source=mscorlib
  StackTrace:
       at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
       at Contoso.UI.GeneralStrings.get_ApplicationName()
       at Contoso.UI.MainPage..ctor()
       at Contoso.UI.Contoso_UI_XamlTypeInfo.XamlTypeInfoProvider.Activate_0_MainPage()
       at Contoso.UI.Contoso_UI_XamlTypeInfo.XamlUserType.ActivateInstance()

Turns out that you cannot take an existing RESX file and embed it inside your UWP 10 assembly.  It comes down to the way the assembly gets compiled and this is no different than how it behaved in the Windows 8.1 days.  If you have a need to use a RESX with your Windows 10 application, the workaround is to place your RESX files inside a Portable Class Library (PCL) and then have your UWP assemblies reference that PCL.  This will get you around this limitation and allow you to still continue to use RESX instead of having to be forced to move to RESW.

A piece of advice if you plan on building your own.  When it comes to performance, a common mistake I've seen when animating the left panel necessary for a hamburger menu is that devs will just animate on the width of the panel. The problem with this is that as the panel is being expanded or contracted, this will cause the pane to update its layout multiple times which is unnecessary.  What you ideally want to just move the pane in or out of view without resizing it and causing any unneeded layout updates.  The sample will show you how to do that using a CompositeTransform with the X value changing instead of the width of the pane.

If you have any questions on this control or building controls like this, feel free to post them in the comments section below.

Enjoy!

Microsoft.DX.HamburgerMenu.zip

 ---

We all know that Windows and Windows Phone support many different screen resolutions. This requires dev teams to create many image assets in their app packages and we all know that takes a LOT of time to produce. To make things easier, the Store team only requires us to provide a small handful of the assets in the app packages. This is great as it allows you to get your app completed with less pain but it comes at the expense of a lot of screens not showing the most optimal asset really needed for that screen. Kind of a problem. These assets represent your brand and application but it's very painful and monotonous for your design team to produce the required images.  This is where I've leveraged Photoshop to help us all out. 

What I've done here is looked at all the image assets needed in Windows Phone 8/8.1 SilverLight and Windows 8.1 Universal for Windows and Windows Phone and created an inventory of those needed assets. This inventory lists each asset for each platform, the type of image it is (SmallLogo, Logo, StoreLogo, WideLogo, SplashScreen, BadgeLogo), and each of the sizes/scales needed for each image type for each platform.  Then using the max sizes for each image type (and some to accommodate future larger screens), I created you a simple Photoshop PSD file representing each image type with a guide box within the template based on the design guidelines for the assets so you know exactly how large your logo/icons should be within that template.

Now this is where Photoshop really comes into play. If you're an experienced Photoshop user, you'll know that Photoshop has a feature called Actions (they are macros) and you can automate almost anything you want within Photoshop.  I created an action for each image template (PSD file) which resizes the template to the appropriate size/scale and exports it with the appropriate file name for each platform.  Once you run the actions on each template, the output folder will contain the Assets folder for each platform which you can then basically just drop into your solution.  Output will be:

• 22 image assets for UAP 8.1 Windows Phone
• 32 image assets for UAP 8.1 Windows
• 14 image assets for SilverLight Windows Phone

In a nutshell, you just give your designers the 8 PSD template files, have them design it however they like, run the associated actions, and voilà, you'll have all the image assets you need without the designers needing to know what dimensions/names/margins/guidelines/etc for each file!

To get set up, follow the instructions below:

1. Download and unzip the ZIP file attached to this blog post (the zip contains all the Photoshop templates, script to create the output folder, the exported Photoshop action scripts, readme file).
2. Import each of the Action (*.atn) files found in the "Photoshop Actions" folder to your Photoshop instance.
3. Run the CreateOutputDirectories.cmd script to automatically create the output folder for all the assets (C:\Images\[PlatformNameHere]\Assets\)
4. Have your designers edit each of the Photoshop PSD files replacing the white guide boxes with the design you want. FYI, the white boxes are just a guide per the modern design guidelines for image assets from MSDN for each asset size.  Also note that the layer name representing the white box indicates how many pixels that box is. But at the end of the day, you can do anything you want with you whole space and you don't have to follow the white boxes, but it is recommended that you do try to follow the image guidelines. Finally, if you need icons for your assets, see my previous post for a free collection of modern UI icons: http://blogs.msdn.com/b/madenwal/archive/2015/02/09/collection-of-modern-ui-icon-libraries-on-the-web-for-free.aspx
5. To generate all the images, run the action name corresponding to the name of the PSD file you want to export (i.e. run StoreLogo action on the StoreLogo.psd file). This will generate all the different scale sizes for that image for each platform.
6. Copy the Assets folder from respective platform folder within C:\Images\ to your solution.
7. Ensure each image file is included in your Visual Studio project and set as Content so that it can be deployed with the application.
8. Update the Visual Assets tab in the application manifest to point to the appropriate image assets set. If you type in the name of the file without the ".scale-NNN." part of the file name, it'll automatically figure out each scaled image available in the project. For example, instead of selecting each image one by one for each scale size, just type in Logo.png and it'll populate the 80 scale, 100 scale, 140 scale, and 180 scale images. See image:
   

This took me a few days to inventory, build, test, and package up. Was painful and mind numbing to produce but I now use this in all my apps and it takes me just a minute to export all the assets I need.  These templates are also ready for Windows 10, but I have not included the actions for those just yet as the platform has not been released yet.  I'll have updated Actions for Windows 10 when the time comes. In the meantime, if you have any questions or suggestions, please do reach out to me via the comments below!

Enjoy!

Photoshop-Image-Asset-Actions-For-Windows8.1.zip

As you start swiping left or right, after you land on the PivotItem with the browser control, the browser instance will essentially “take“ the swipes and not allow its parent (the PivotItem and the Pivot) to respond to them. This means that the user won't be able to swipe left/right if their swipe was in the pivot body. If they swipe within the header of the pivot control, then that'll work fine. This is because the web browser control instance sees those swipes and thinks you’re trying to pan the content within the browser to the left or right and doesn't know anything about it's parent container.  To fix this experience, you’ll need to tap into the element tree of the WebBrowser and watch for swipes yourself and then manually change the SelectedIndex of the Pivot control accordingly.  It sounds tricky but it isn’t too bad. And I’m also giving you a sample project which you can reference (it's attached to this blog post).

So to make this work, here’s the 3 things you need to do:

1)     After the browser’s Loaded event fires, get a handle to last Border element within the browser control.  LinqToVisualTree will do the grunt work for you, so just reference that in your project.

var border = _browser.Descendants<Border>().Last() as Border;

2)     After you get a handle to the border element, subscribe to its ManipulationDelta event. This event tells you when and how the user might have touched the element.

3)     Whenever the ManipulationDelta event fires, you’ll need to look at the DeltaManipulation.Translation event argument and examine the X and Y values to see which direction the user might have swiped within the control.  A positive X value means the user moved right, negative X value means they moved left. A positive Y value means they moved upwards, a negative Y value means they moved downwards. But you need to be careful here. Just because you see a change in the X value doesn’t mean the user swiped left or right.  They very well could have been swiping up/down to pan vertically in the web browser and but they didn’t move their finger in a perfecty straight vertical line.  No one will ever do that. So you need to be a little smart here with the logic and try to figure out if they absolutely are trying to swipe left or right to move to another pivot.  The way I did it is to compare the X to the Y values and then add in some buffer by checking to see if the X delta movement is at least 5 times greater than the Y delta. If it is, then its almost certain the user is trying to move pivots. If it’s less than that, well then perhaps they were actually trying to pan vertically but they were holding the phone in such a way that their swipes were diagonal across the screen.  You’ll need to determine what the right threshold is for your app but hopefully should be easy to do with this sample:

 var x = e.DeltaManipulation.Translation.X;
 var y = e.DeltaManipulation.Translation.Y; 
 // Make the deltas positive numbers for calculating the threshold
 var xAb = Math.Abs(x);
 var yAb = Math.Abs(y);
 
 // Ensure that the horizontal scroll is greater than the vertical scroll amount. 
 // In case the user swipes diagonally, ensure that the horizontal scroll is at least 5x bigger than the vertical
 // scroll to eliminate any accidental pivot changes.
 if (xAb > (5 * yAb))
 {
 if (x < y)
 {
 // Go right
 e.Handled = true;
 _pivot.SelectedIndex = Math.Min(_pivot.Items.Count - 1, _pivot.SelectedIndex + 1);
 }
 else if (x > y)
 {
 // Go left
 e.Handled = true;
 _pivot.SelectedIndex = Math.Max(0, _pivot.SelectedIndex - 1);
 }
 }
 

One thing to note is that this only really will work for you if the content you are displaying in the WebBrowser control doesn’t need to pan horizontally.  If you need to support that, well then you have a big design issue on your page that you need to address regarding multiple controls needing to support swiping horizontally.  And if you’re going to be reusing this logic across multiple Pivot control instances, see the sample project where I’ve taken the above and wrapped it into a helper class making reuse a little easier.

Good luck!

PivotWithWebBrowserSample.zip

• http://modernuiicons.com/
  By Austin Andrews designed for Windows and Windows Phone applications. He will
  also take requests and build custom icons for you. Probably the best collection
  of modern icons ready for immediate consumption.
• http://www.flaticon.com
  Hundreds of collections of icons by purpose for free. Also has a Photoshop plugin to allow you to find icons without even leaving Photoshop.
• http://www.syncfusion.com/downloads/metrostudio
  Syncfusion Metro Studio is a collection of over 4,000 Metro-style icon
  templates that can be easily customized to create thousands of unique Metro
  icons.
• http://www.geekchamp.com/icon-explorer/introduction
  Over 1500 free symbols/icons over 29 categories and can be used as PNG or via XAML/HTML
  code.

• Other sources but may or may not need some light tweaking to be a
  modern icon
  • http://sixrevisions.com/freebies/icons/free-icons-1000/
  • http://www.freepik.com/
  • http://materialdesignicons.com/
    Also created by Austin Andrews but for Google’s material design language. You
    can always tweak these to be modern UI icons.
  • https://github.com/google/material-design-icons/releases
    Library released by Google but could also be tweaked for your modern app if you
    like.

If you have any others you find, please do share and I'll append to this collection!

If your solution is a WinRT solution, you’ll need to follow this convention:

ms-appx:///{ASSEMBLY_NAME}/{RESOURCE_FILE_PATH}
i.e. ms-appx:///Contoso.Core/Resources/CoreStyles.xaml

For a SilverLight Windows Phone solution, you’ll need to follow this convention:

/{ASSEMBLY_NAME};component/{RESOURCE_FILE_PATH}
i.e. /Contoso.Core;component/Resources/CoreStyles.xaml

Full samples of the App.xaml file as follows:

WinRT

<Application
 x:Class="Contoso.UI.App"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
 
 <!--Application Resources-->
 <Application.Resources>
 <ResourceDictionary>
 <ResourceDictionary.MergedDictionaries>
 <ResourceDictionary Source="ms-appx:///Contoso.Core/Resources/CoreStyles.xaml" />
 <ResourceDictionary Source="ms-appx:///Contoso.UI.Core/Resources/UICoreStyles.xaml" />
 </ResourceDictionary.MergedDictionaries>
 
 <!-- Other style definitions can still go here -->
 <Style TargetType="Button">
 </Style>
 
 </ResourceDictionary>
 </Application.Resources>
 </Application>
 
 

SilverLight

<Application
 x:Class="Contoso.UI.App"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
 xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone">
 
 <!--Application Resources-->
 <Application.Resources>
 <ResourceDictionary>
 <ResourceDictionary.MergedDictionaries>
 <ResourceDictionary Source="/Contoso.Core;component/Resources/CoreStyles.xaml"/>
 <ResourceDictionary Source="/Contoso.UI.Core;component/Resources/UICoreStyles.xaml"/>
 </ResourceDictionary.MergedDictionaries>
 
 <!-- Other style definitions can still go here -->
 <Style TargetType="Button">
 </Style>
 
 </ResourceDictionary>
 </Application.Resources> 
 
 <Application.ApplicationLifetimeObjects>
 <!--Required object that handles lifetime events for the application-->
 <shell:PhoneApplicationService
 Launching="Application_Launching" Closing="Application_Closing"
 Activated="Application_Activated" Deactivated="Application_Deactivated"/>
 </Application.ApplicationLifetimeObjects>
 
 </Application>
 

What created this issue or failure is that I wanted the application's background to be pure white including the splash screen and tile background colors. But what I forgot to do is flip the Foreground text property within the Package.appxmanifest to Dark (default is Light).  As a result, when the WACK test was run, it's static analysis kicked in thinking I was trying to submit a white on white application and complained about contrast within the app. If you come across this error, just make sure you go into the manifest and double check the following property: