#Building the "right" type of Hosted Web App We're encouraged with the popularity of project Westminster (also called Hosted Web Apps) amongst developer for building Windows 10 app. it's also no surprise that some of the top "quality" apps in our store are built as Hosted Web Apps. Apps like Pandora, Shazam and even Microsoft's own Office Sway are hosted web apps that take full advantage of the windows 10 platform and are amazing apps that customers adore.
##What is a Hosted Web App
Let's take a look at what makes an "app" a "Hosted Web App". In its essence, a Hosted Web App is a container app, where the content of the app (or the majority of the content) is still "hosted" on a web server. To a user, a Hosted Web App looks and feels like any other store app, but for the developer, the code presides on their web server where it is easy to update, or reuse for the web or even other platforms. When the container app is launched, the code is then loaded inside the app from the web server (just like in a browser) at runtime. As a windows 10 app, it has access to not only the standard web APIs like in a browser, but also the entire surface of WinRT APIs just like any other Windows 10 app.
Many developers ask me what it takes to create a "great" hosted web app, so let’s look at some of the features and characteristics that might back the difference between "just a web app" and an Amazing Windows 10 app. Let's take a look at a few of those "keys to success" when building Hosted Web Apps.
##Starting with "the right kind of web app"
As a Hosted Web App, it's important to remember that your context is inside of an app, not inside of the browser. So some of the features you may rely on from the browser (like bookmarks, back button or the URL bar) will not exist inside the app. These differences, as well as new characteristics from devices that might be running your app, may alter or augment the way you build your web app.
First, not all web apps need to be Single Page Applications (SPA). In general, SPAs tend to have more on the navigation controls encompassed in the body of the app, and rely less on the browser back button and URL bar for user navigation. Whether your app is a SPA or a traditional "page flow" application it's important to consider how a user will navigate between sections of your web app. A user should easily be able to go back to the previous content they were viewing, or start at the beginning of the app at any time.
If your app relies on browser controls to help users with this high level navigation, they you may want to utilize the Windows APIs for the app bar or task bar back buttons. All of these APIs are accessible in JavaScript, and we'll talk a little bit later about how to make sure your page has access to the right sets of Windows APIs and show an example of back button code in JavaScript.
###Planning for page Loads
Additionally, your web app should think about how it indicates the status of the app. Do you have indicators for when data is loading? While in the browser, users tend to tolerate delayed responses in apps (I click a link and wait for a page to load), in an app context you may need to consider showing a loading indicator while pages load, or content is being loaded to populate a page.
Touch is another consideration for hosted web apps. Many modern web apps already consider touch devices (especially in the mobile space) and are well suited to be presented as a store app, where the likely hood of being loaded on a touch screen device increases. However, there are still a number of sites, especially in the desktop space, that relay on "hover" to access menus and site content. it's also common to see websites that have click targets that are designed for mouse, and are too small for use on touch screen device. If your web app falls under this category, you'll want to make some changes before moving into the hosted web app. Microsoft recommends that you consider all devices and platforms when you build your navigation, that may mean supporting both the W3C pointer event APIs as well as touch events.
You'll also want to test your interactive controls to make sure they work with touch as well. Objects like maps, JavaScript scrolling menus and image carrousels should cater to touch. Maps should support multi-touch and allow you to zoom in and out with touch. Carrousels and scrolling windows should all support natural touch interactions.
Responsive design and progressive enhancements patterns have been around the web for quite some time. When moving out of the browser and into the app space, those same principals apply, and can even be more essential in the app space. Even when only considering the family of Windows 10 devices, your app will need to cater to screens as small as a phone, to as large as an XBox screen. Windows 10 devices come in all shapes and sizes, and being "Windows", your app will likely be used inside of a window on the desktop, or sharing the screen with other apps at the same time. The value of these principals will be realized on other platforms as well, as many Android and now some iOS devices introducing "windowing" to users. There are a number of great frameworks out there like BootStrap and ### that aid you in customizing your web app for different screen sizes. You can also build custom solutions using CSS media queries. Be sure your app can be easily read and navigated no matter what the screen size and shape.
Some site owners, for legacy or business reason still maintain a different mobile site AND a Desktop site. In this case the question often comes up as to which of these sites should be used for a Hosted Web App. The answer depends on your app. Keep in mind the above recommendations. If your desktop app doesn't scale down to a smaller screen, or isn't touch friendly, then you'll not want to move it into the app. To use your mobile app across screen sizes, it would need to respond to the screen size, and take advantage of screen space on larger devices.
There are a number of offline technologies today that help your web app work offline, HTML5 App cache, indexedDB and the upcoming service workers spec provide mechanisms for making your app work offline, and many of these technologies will work inside the Windows 10 Hosted Web App (service workers is on the roadmap). However, the majority of web apps don't take advantage of any of these technologies to work offline. However, this becomes an issue when you move out of the browser context, and into the app context. A 404 is generally understood from within the browser, but a 404 from within the app would be quite confusing. Windows 10 provides you with an easy solution. By including an additional file within the appx package named "msapp-error.html", then wills will show this page any time a page request fails. Evan a simple page:
code for error page
Of course, more complex offline content can be included as well to provide a richer offline experience.
There are two ways to build your Hosted Web App in Windows 10, the first via the command line with an open source tool called Manifoldjs. it's a node.js client app that can be installed via npm:
> npm install manifoldjs
Manifoldjs allows you to build your app from the W3C Manifest for Web Apps or simply your web URL. Manifoldjs doesn't just build for Windows 10, it includes many other platforms like iOS and Android. A traditional W3C Manifest my look something like this:
{
"name":"My Awesome Web App for 2016",
"short_name": "My Awesome Web App",
"scope":"https://www.mysite.com",
"start_url":"https://www.mysite.com/my-start/",
"icons": [
{
"src": "images/windows-splashscreen-620-300.png",
"sizes": "620x300"
},
{
"src": "images/windows-squarelogo-150-150.png",
"sizes": "150x150"
},
{
"src": "images/windows-storelogo-50-50.png",
"sizes": "50x50"
},
{
"src": "images/windowsphone-appicon-44-44.png",
"sizes": "44x44"
},
{
"src": "images/android-launchericon-512-512.png",
"sizes": "512x512"
}
],
"theme_color":"white"
}
Manifoldjs will automatically build some basic offline content for you within your application. It runs on a PC, mac or Linux machine.
You can also build Hosted Web Apps right inside of Visual Studio 2015. Simply start a new JavaScript app, and point the start URL of your app to point to your website. You'll then need to make sure the scope is enabled by adding a few Content URI rules to the manifest. This can be done directly inside of the package.appmanifest file:
With Visual studio, you'll have extra files in the package that you will not need as a hosted web app (css, js local default.html and WinJS library) so you will probably want to delete those files from the project. Also, you'll need to manually generate an msapp-error.html page as explained above.
Hosted Web Apps in Windows 10 have every privilege of any other windows app, that means you can take advantage of platform specific APIs such as live tiles, back button, secondary pinning and support for contana interactions. Generally, users will expect the store app to provide them with some additional functionality they can't get in the browser, so it's highly recommended you augment your web app with some of these features when moving outside the browser and into the Hosted Web App. You don't need to fork your code to do this. Like any API, windows 10 APIs can be feature detected. Above we talked adding a back button to your web app. That can be done simply:
if(window.Windows){
...
}
First, we will want to feature detect to make sure we only execute the calls for Windows 10 APIs when we are actually inside a windows 10 App. The next step will be where we show the back button, and then add an event listener to handle the behavior of the button.
//this is the windows apis for the back button as well as an event handleere for it
var systemNavigationManager = Windows.UI.Core.SystemNavigationManager.getForCurrentView();
systemNavigationManager.addEventListener("backrequested", handleSystemNavigationEvent.bind(this));
var systemNavigation = Windows.UI.Core.SystemNavigationManager.getForCurrentView();
// function to handle the system Navigation Event
function handleSystemNavigationEvent(args) {
args.handled = true; //cancels the default behavior of the system back button
history.back()
}
//if it on the home page we don't want to show the back button
var homeURL = 'https://www.mysite.com/my-home/';
var curURL = window.location.href;
//set up event to show if it should be shown
window.addEventListener('load', function(){
if (curURL !== homeURL) {
systemNavigation.appViewBackButtonVisibility = Windows.UI.Core.AppViewBackButtonVisibility.visible;
}
else{
systemNavigation.appViewBackButtonVisibility = Windows.UI.Core.AppViewBackButtonVisibility.collapsed;
}
});
There is only one last thing we'll want to do in order for our above code to work. We'll want to use the Content URI rules we showed above to make sure API access is available from the appropriate pages. If you build your app using Manifoldjs, you'll want to add an additional line to your manifest:
{
...
"mjs_api_access": [{ "match": "*://www.mysite.com/*", "access": "all", "platform": "windows10" }]
}
If you are using Visual Studio, you'll want to update to Content URI rules by setting the "WinRT Access" value to "all":
###Conclusion Before you make the leap out of the browser and into a Hosted Web App, you'll want to make sure that your web app is ready to be a store app. Follow the preceding instructions to make sure your app has all the necessary features to provide a great experience for your users. Hosted Web Apps are a great way to build apps for Windows 10 (and other platforms) while maintaining your web workflow, and continuing to use the code, libraries and editors you've grown to love!