Building the Bing apps for Windows 8
Overview
For Windows 8, the Bing team built News, Weather, Finance, Sports, Travel and Maps apps. This technical overview provides insight on the architecture of these apps, key Windows 8 features and the contracts they use, common controls they employ, and world readiness more generally.
Several members of the Bing team formed an apps team approximately one year ago to deliver a set of apps powered by Bing for Windows 8. The focus of these apps is to keep users informed by delivering fast and fluid experiences, with content from multiple sources. All the apps are optimized for touch and tablet devices, but also work great with a keyboard and mouse. We have spent the last several months making these apps world-ready.
When developing the apps, we had two objectives: to build a set of great apps to make Windows 8 even more compelling and to serve as a model for app developers. With this post, we provide you with a technical overview of the apps and offer insight/resources you can use to develop your own apps. Through the process, we learned a lot – even a few things we’d do differently next time. Keep reading for the full story.
For Windows 8, the Bing team built News, Weather, Finance, Sports, Travel and Maps apps. This technical overview provides insight on the architecture of these apps, key Windows 8 features and the contracts they use, common controls they employ, and world readiness more generally.
Several members of the Bing team formed an apps team approximately one year ago to deliver a set of apps powered by Bing for Windows 8. The focus of these apps is to keep users informed by delivering fast and fluid experiences, with content from multiple sources. All the apps are optimized for touch and tablet devices, but also work great with a keyboard and mouse. We have spent the last several months making these apps world-ready.
When developing the apps, we had two objectives: to build a set of great apps to make Windows 8 even more compelling and to serve as a model for app developers. With this post, we provide you with a technical overview of the apps and offer insight/resources you can use to develop your own apps. Through the process, we learned a lot – even a few things we’d do differently next time. Keep reading for the full story.
Architecture overview Platform services
All our apps are written in HTML/Java Script, except the Maps app, which is built in XAML/C#. All the apps share a common client platform that provides several essential services, such as instrumentation, caching, query services, settings, roaming, profile management, market customizations, and speech fundamentals. We deliberately chose to have client side caching, to invest in prefetching and for the client to set the time to live of various pieces of data for a couple reasons.
Our apps are designed for all PC devices, many of which we expect to be tablet devices. Windows 8 tablets can be used to consume content as well as create content by consumers and businesses alike. In many situations, we know users go through various states of connectivity (fully connected on fast networks, weak connectivity over WiFi or cellular, flaky networks, and even no connectivity). Our goal was to build a rich client app that’s different from a webpage. We used IE concepts of caching all network data to the file system and re-using cached data while waiting for fresh data to arrive. We also designed experiences for when cached data wasn’t available and network requests failed. For these scenarios, we, provide graceful error messages, retry mechanisms and listen for network connectivity changes from the OS to automatically trigger a retry.
Query services Our apps use several services that are built on the Bing stack and/or in Windows Azure. The Bing services and data are served via dedicated application servers built on the Bing platform. For example, the Finance app heavily uses data and services from Azure, whereas data and services for the Maps app are provided via the Maps control, which is built by the Bing Maps team. Our apps also have other articles, images and videos that are hosted in our Content Management System. If you want to create apps that take advantage of the Bing web index or industry leading publisher data, check out the Windows Azure Marketplace, where you can access the Bing Search API and info from leading publishers like STATS Sports or agencies like the United Nations.
Our apps are designed for all PC devices, many of which we expect to be tablet devices. Windows 8 tablets can be used to consume content as well as create content by consumers and businesses alike. In many situations, we know users go through various states of connectivity (fully connected on fast networks, weak connectivity over WiFi or cellular, flaky networks, and even no connectivity). Our goal was to build a rich client app that’s different from a webpage. We used IE concepts of caching all network data to the file system and re-using cached data while waiting for fresh data to arrive. We also designed experiences for when cached data wasn’t available and network requests failed. For these scenarios, we, provide graceful error messages, retry mechanisms and listen for network connectivity changes from the OS to automatically trigger a retry.
Query services Our apps use several services that are built on the Bing stack and/or in Windows Azure. The Bing services and data are served via dedicated application servers built on the Bing platform. For example, the Finance app heavily uses data and services from Azure, whereas data and services for the Maps app are provided via the Maps control, which is built by the Bing Maps team. Our apps also have other articles, images and videos that are hosted in our Content Management System. If you want to create apps that take advantage of the Bing web index or industry leading publisher data, check out the Windows Azure Marketplace, where you can access the Bing Search API and info from leading publishers like STATS Sports or agencies like the United Nations.
Caching
Supporting hundreds of millions of users interacting with rich apps that are powered by lots of data and content requires a lot of server computing. To scale the hardware needs along with the number of users, we have invested heavily in caching at different tiers. Our content management system rendering server, services in Azure, as well as the local client platform itself cache data to reduce the server load. If you’re anticipating several thousand users, consider local caching as a means to limit server computing and to improve the user experience – you can find out more about app caching (AppCache) on the Dev Center.
Some of the ways our apps make use of caching on the client involve:
Some of the ways our apps make use of caching on the client involve:
- Managing low and high res versions of the same image – choosing what to display based on what’s in the cache or not.
- Client-side caching that override server-set content ages. Oftentimes the services we use aren’t owned by us and we can’t control those lifetimes, in which case our client decides on the caching.
- Being careful to at least display stale cached data instead of downloading new data that may be invalid.
Custom controls
Design is a fundamental differentiator for our apps and plays a key role in building visually organized and intuitive to use apps. To achieve a consistent look and feel and a visually immersive experience across our apps, we built custom controls on top of the compelling UI controls that Windows provides. If you want a consistent look and feel across your apps or want to deliver against a signature user interface, we encourage you to take advantage of the flexibility of Windows and build your own UX framework or custom controls on top of Windows 8. There are ample resources available on MSDN to help you create your own UX framework and custom controls.
Failsafe
If your app relies upon data from a 3rd party, plan on full outages as well as partial outages from your data providers from time to time. We strive to make our apps avoid single points of failure and we build in several failsafe mechanisms. We invested in various failsafe practices on both the server and client side primarily for the benefit of our users. Across all our apps, we have data and services from many parts of Microsoft as well as industry partners. All these external sources have varying degrees of uptime SLAs and TTM (time to mitigate) service level outages. Any given panorama on any application could rely on data and services from multiple sources. To provide a good end user experience, we use failsafe techniques both on the server and client side, including caching, backup providers, graceful degradation of features or falling back on acceptably stale data in some cases (for example, destination information). Think about these failsafe measures and take steps to create adaptive UI and error messaging when design and develop your app, not during or after a data failure.
Client framework – language choices
One question developers frequently ask is why we implement using client-side HTML, rather than server-based HTML5. The short answer is that apps on Windows 8 are not websites. Creating a great Windows Store app requires a deep level of integration with the platform that we simply cannot achieve with standard web code. If we had delivered features purely via the same HTML5 normally viewed in the browser, the pages would not have had access to the features of Windows 8 that really make the user experience great.
Building an app gave us several advantages, including:
By: Ray Yagubyan
Building an app gave us several advantages, including:
- Using the built-in controls of the Windows JavaScript Library (WinJS), which allowed us to leverage the power of Windows 8 and build on top of the experiences that the Windows team has built. We think we’ve delivered a great user experience (UX) provided by WinJS.
- Native app platform features not accessible via HTML5 in a browser:
- Device features such as access to the microphone, webcam, or network
- Shared file locations such as My Documents, Music, Pictures or Videos
- Participate in contracts, including those for searching, sharing, settings, contacts etc.
- In addition certain libraries are better in WinRT compared to HTML5. For example, the WinRT geolocation APIs are richer than those found in HTML5.
- Supplementing the JavaScript code with performant, statically-typed, code in C#. We used language constructs that don’t exist in JavaScript – for example, LINQ as well as the .Net4.5 Asynchronous framework. The latter is very important because it helps ensure correctness in asynchronous operations, which can get quite complex.
Be aware that if you write a WinMD to host business logic (whether in C# or C++), there’s a cost to marshaling lots of data between languages. It’s better to have one call that marshals a lot of data, rather than many calls that marshal little data. Additionally, C# and JavaScript have separate, independent garbage collectors. Because they’re not in sync, it’s possible that your memory usage will be larger than if you were to write an app wholly using JavaScript or C#.
When we developed our apps we decided that the benefits of a JavaScript and C# mixed language app were worth the extra costs of working around these complexities. We made sure that our apps still performed great. If you’re considering combining JavaScript and C# in your app, keep the extra cost and complexity in mind. This way you can choose the architecture that best fits the requirements of your app. - Building our Maps application on top of XAML to access the native DirectX Map control. This approach gave us even more control and greater performance of our rendering (critical with a map!).
By: Ray Yagubyan