W poprzednim poście dokonałem ogólnego podsumowania możliwości aplikacji Metro w Windows 8. Dziś poświęcę uwagę samemu interfejsowi użytkownika.
Oprócz żywego obcowania z przykładowymi aplikacjami i systemem, pojęcia na temat rozwiązań stylistycznych nabrać można oglądając sesje z konferencji BUILD. Screenshoty UI podzieliłem na 25 kategorii. Są dostępne tutaj.
Na początek mała ciekawostka - tak wygląda Windows 8 build 8180, mający już napis “Windows 8 Beta”, ale jeszcze betą nie będący. To ostatni build przed rozpoczęciem fazy Beta Ecrow. Podczas instalacji można zauważyć kilka zmian w stosunku do wersji z konferencji BUILD. Domyślnym kolor tła jest teraz niebiesko-szary (można oczywiście ustawić sobie inne tło). Niestety, mimo kilkukrotnych instalacji Visual Studio 11 Preview i elementów SDK dla Metro nie udało mi się póki co otrzymać instalacji Visual Studio pozwalającej na budowanie aplikacji Metro. Trudności nie dziwią zważywszy na fakt, że narzędzia dla Metro były dystrybuowane w czasach BUILD-a na specjalnej developerskiej odmianie x64 i bezwzględnie takiej wersji wymagały (choć podobno był nieoficjalny sposób by to częściowo obejść). Dobrze że zachowałem sobie obok poprzednią wersję Windows Preview z narzędziami, zresztą oficjalna beta coraz bliżej.
Ale w sumie ten post miał być nie o tym –:) Postanowiłem zebrać tu i uporządkować całą masę informacji, jakie można było otrzymać po obejrzeniu sesji z BUILD i zapoznaniu się z dokumentacją MSDN, jak i dokumentami ją uzupełniającymi –:) Aby nie stracić na czytelności i nie zakopać się w szczegółach technicznych, ograniczam się głównie to zagadnień i funkcjonalności, nie wyszczególniając jak można je realizować (czasami są alternatywne podejścia między HTML5 a .NET/C++).
Uważam że najbardziej ciekawe są: idea WinRT, funkcjonalności w UI, taski w tle, multimedia, kontrakty, proximity, roaming, obsługa urządzeń, aplikacje dla urządzeń i dla operatorów internetowych.
Aplikacje Metro: dodatkowe informacje o sensorach, dodatkowe informacje nt. funkcjonalności PlayTo (parowanie urządzeń, rodzaje odbiorców, tips & tricks), dostęp do zawartości serwerów multimedialnych, aplikacja Metro jako odbiorca PlayTo (godne uwagi - nie ma tego jeszcze w dokumentacji MSDN), testowanie aplikacji za pomocą Windows App Certification Kit, Windows Store (nowe, dość szczegółowe informacje w dokumentacji MSDN po zaprezentowaniu sklepu opinii publicznej).
Overview of motion and device orientation for Windows Developer Preview
Accelerometer
X = 0, Y = 0, Z = -1
Inclinometr
Play To and media sharing for Metro style apps
Media sharing in the next version of Windows can be summarized by the following three scenarios.
Play To media streaming
Play To supports streaming of local media files, files from DLNA media servers and also streaming media from the internet.
On private networks Windows automatically discovers and pairs certified Play To devices when users select Enable sharing and connect to devices while provisioning the network.
On a public network, and when users do not want sharing enabled by default, devices will need to be manually paired using the Control Panel.
Only the below list of Play To receivers are supported in the Developer Preview. For scenario testing/validation from apps the easiest solution is to use Windows Media Player on another PC on the same Private Network. Other available devices are:
Tips & tricks
The ‘src’ attribute of an element can be changed after it has been connected to a Play To Receiver to stream media playlists and image slideshows.
<img id="player" src="image1.jpg" />
<script type="text/javascript">
setTimeout(function(){
document.getElementById("player").src = "image2.jpg";
}, 10000);
</script>
Application can generate and stream images on the fly by drawing on the <canvas> element and taking a snapshot of its content using its msToBlob() method.
<canvas id="renderer" />
<img id="player" />
<script type="text/javascript">
var blob = document.getElementById("renderer").msToBlob();
document.getElementById("player").src = URL.createObjectURL(blob);
</script>
Applications can easily query the friendly name of the device that the media is being streamed to.
<script type="text/javascript">
var ptm = Windows.Media.PlayTo.PlayToManager.getForCurrentView();
ptm.addEventListener("sourceselected", function(e) {
log(e.friendlyName);
});
</script>
To improve the application memory footprint the next version of Windows introduces non-reusable blob URLs. You can enable this feature by passing false as the second parameter of URL. createObjectURL(). This is currently not compatible with Play To.
You may want to access media files from other DLNA media servers connected to the home network. In order to do so, an application needs to integrate the new file picker APIs. These APIs are used to trigger the Metro style UI that gives users the option to find files locally, in removable storage, or in media servers connected to the network.
You can apply a filter to the FileOpenPicker() function to access specific paths in the hierarchy. For example, the path that shows media servers is either Files/Desktop/Computer/Media Servers or Files/Computer/Media Servers.
Any DLNA media server exposes content using its own hierarchy of containers. Each container can include other containers or media items. The first layer typically includes containers called Music, Videos, and Pictures. The second layer under Music sometimes includes a container called All Music. The file picker integrates the Windows hierarchy and the media server hierarchy into a single tree. For example, a user can navigate from the root to All Music using:
Files -> Computer -> Media Servers -> MyServerDevice -> Music -> All Music
You can use the URL.createObjectURL() function to obtain the URL for the selected file object. The URL is then inserted programmatically into a video element. The content referenced by the video element can be played by default in the App, or it can be pushed to any Play To receiver in the network.
The new Play To Receiver API in the next version of Windows makes it possible for any Metro style app to become a Play To target for audio, video, and images.
The following steps provide a walkthrough for getting started with the Play To Receiver developer sample. You can download the sample from the samples gallery.
Windows Media Player (Stream –> Turn on media streaming…)
Using the Windows App Certification Kit
Starting with Windows Developer Preview, we are introducing the Windows ACK to replace the WSLK.
Windows ACK will be available as part of the Windows Software Development Kit for Metro style Apps. The toolkit is already pre-deployed on the Windows Developer Preview image, and at present it cannot be obtained through any other mechanism.
Validating apps
After the validation process concludes, Windows ACK will generate a report.
Windows Store
With successful apps on Windows you'll make more money than the industry standard, earning 80% of every customer dollar after an app makes more than 25,000 USD in sales. For the first 25,000 USD of an app's sales, you get the industry-standard 70%.
The price tier sets the price of your app. You can offer your app for free or, when the Windows Store supports sales, pick a price tier for it. Price tiers will be available from 1.49 USD on up, in increments of 0.50 USD to 4.99 USD, with higher price tiers also available.
The cost to register for a Windows Store developer account in the United States is 49 USD for an individual and 99 USD for a company.
Poland: 140 PLN / 280 PLN paid to bank or PayPal
Apps can also show ads to your customers. You can show ads from apps that also sell in-app purchases and from apps that have a trial period.
Third-party transactions
Apps can also make money in ways other than those the Windows Store provides. You can use a third-party transaction provider or benefit from ties to other lines of business as long as the transactions comply with the App Developer Agreement. For example, if you have a transaction platform that integrates into a CRM system, you can use that in your app to keep track of your subscribers.
On or before the date on which Windows 8 Release Candidate is released, Microsoft may (but is not obligated to) remove any or all apps and content from the pre-release Windows Store, as well as from any devices onto which they may previously have been downloaded or installed.
Roaming is a Windows 8 feature that enables users to use your app on up to 5 Windows 8 enabled devices at any one time, unless you identify your app as eligible for distribution by only named OEMs, or on only an ARM or X86 processor. Only the most recently distributed version of your app will be roamed to consumers.
All apps submitted through the pre-release version of the Windows Store must be for no charge. Microsoft will not process any payments related to apps during the beta period, including payments for in-app purchases.
Some certificate requirements:
Enterprise deployment. An option for developers who create apps for use within an organization is enterprise deployment. Enterprise deployment enables your apps to be distributed to users within the enterprise without going through the Windows Store.
Aplikacje Metro: migracja z aplikacji web i z Windows Phone 7, tworzenie komponentów Windows Runtime. Interesujące informacje z Windows Developer Preview Windows 8 guide na temat systemu operacyjnego. Szczególnie polecam temat tasków w tle w aplikacjach Metro (z dodatkowego dokumentu Introduction to background tasks. Guidelines for developers, tych bardzo istotnych informacji nie ma jeszcze w dokumentacji MSDN).
Migrating a web app
The process that hosts and executes a Metro style app using JavaScript is called WWAHost.exe. This process provides a superset of functionality greater than that provided by the Microsoft Internet Explorer browser.
Libraries:
The WWAHost.exe provides an Internet Explorer-based rendering platform.
WWAHost.exe cannot host Adobe Flash Player, Microsoft Silverlight, Java objects most ActiveX controls and other embedded components. The following ActiveX controls are supported:
Migrating a Windows Phone 7 app
Resolutions, input (WP7 touch oriented), phone-specific functionality in WP7, XNA to DirectX C++.
Note that the following Silverlight XAML namespaces do not have a direct analog in the Windows Runtime:
Differences between Silverlight and Metro style apps using XAML:
Creating Windows Runtime Components
With the .NET Framework 4.5 Developer Preview, you can use managed code to create your own Windows Runtime types, packaged in a Windows Runtime Component. Visual Studio makes it easy to add a C# or Visual Basic class library to your app, and to create Windows Runtime types that you can call from JavaScript. Internally, your Windows Runtime types can use any .NET Framework functionality that's allowed in a Metro style app. Externally, the members of your type can expose only Windows Runtime types for their parameters and return values. When you build your solution, Visual Studio builds your .NET Framework class library project and then executes a build step that creates a Windows Metadata (WinMD) file. This is your Windows Runtime Component, which Visual Studio includes in your app.
Visual Studio first compiles the class library, and then executes an MSBUILD task that runs the WinMdExp.exe utility to create the WinMD file, turning your class library into a Windows Runtime Component. The WinMD file contains both the managed code and the WinMD definitions that are used by JavaScript and the Windows Runtime. WinMdExp.exe generates build errors when you write code that's invalid in WinMD. Visual Studio adds your component to the package file (.appx) for your Metro style app, and generates the appropriate manifest.
The rules for managed WinMD and JavaScript
The .NET Framework contains many types that are not part of the Windows Runtime. You can use these types in the implementation of your Windows Runtime types, but they cannot be part of the public API surface. The following list describes the restrictions that are required by the Windows Runtime, and an additional restriction required by JavaScript.
The following are known issues with managed Windows Runtime Components in Windows Developer Preview:
In Visual Studio 11 Express for Windows Developer Preview, you can't debug JavaScript and managed code at the same time.
In the .NET Framework, primitive types like the Int32 structure have many useful properties and methods, such as the Int32.TryParse method. By contrast, primitive types and structures in the Windows Runtime only have fields. When you pass these types to managed code, they appear to be .NET Framework types, and you can use the properties and methods of the .NET Framework types as you normally would.
You can tell when a Windows Runtime type appears as a .NET Framework type, because the IntelliSense in Visual Studio hides the Windows Runtime type when you're writing managed code, and presents the equivalent .NET Framework type.
Windows Developer Preview Windows 8 guide
Windows 8 has two touch keyboards for ultimate mobility and flexibility. An improved, full-sized touch
keyboard with larger buttons and a unique thumb keyboard make it easy to use your computer on the
go. Whether you’re walking around or sitting down, it’s more comfortable and natural to type using your
thumbs when the keyboard is split.
When you sign in with your connected Microsoft account to another PC running Windows 8, your Metro
style apps and settings go with you, so it’s just like you’re using your own PC. You’ll also be signed in to all
of the websites you were signed in to. Your connected account is like a portable, personal PC that appears
on any Windows 8-based PC you’re using.
Metro style apps run and stay up to date even when the PC is on standby. When you’re connected to the
Internet, you’ll receive information updates, email, VoIP calls, instant messages, and be able to stream
music or other content in the background. When Windows comes out of standby, your apps don’t need
time to catch up.
You can install your purchased apps on up to five Windows 8 PCs.
On x86 and x64 PCs, Windows 8 supports Windows 7 desktop applications and devices so you don’t have to
compromise or give up what you’re used to. On these PCs, your existing Windows 7-based applications just work.
Push-button reset
Windows 8 comes with a number of options to restore your PC to its original state. You can do a basic reset, which gives you an easy option to restart fresh while retaining all of your documents, accounts, personal settings, and even the apps you’ve downloaded from the Windows Store.
Windows 8 also provides some new, advanced options. You can do a complete reset, which restores the PC to
the state it was in when originally purchased. And you can also create a reset disk, which is great for power
users who have invested time to personalize and configure their PC. Restore from USB Key restores your PC
from a thumb drive, saving space and giving you a convenient backup tool.
Windows Update
If you turn on Windows Update during setup and your computer needs an update,
Windows can install it when you’re not using your computer or at a time you’ve specified. When an
update requires a reboot, there’s a grace period, allowing you to pick a time that’s convenient for you. As
a result, you see far fewer prompts about maintenance, updates, or reboots.
Windows Runtime
WinRT features are represented by the Application Binary Interface (ABI), which makes Windows APIs
accessible from other programming languages. The ABI is exposed in metadata assemblies (.winmd files),
allowing static languages (like C#) and dynamic languages (like JavaScript) to understand the structure of
the WinRT API.
Developing for IE 10
With the release of IE10, developers get even more support for HTML5, enabling them to create rich
visual effects and animations with hardware accelerated CSS transitions, animations, 3D transformations,
along with CSS3 text shadow, gradients, and SVG filter effects. Building increasingly sophisticated page
layouts is possible with support for CSS3 grid, flexible box layout, multi-column, figures, CSS3 regions, and
hyphenation, as well as HTML5 Forms and Input Controls.
The IE10 platform also includes support for local storage including IndexedDB, Application Cache, Async
scripts, Web Workers, ES5 Strict mode support, Web Sockets, HTML5 file APIs, drag-drop, history, and
sandboxing. These features give developers an increasingly sophisticated, standards-based, programming
model that is ideal for creating modern web experiences.
System requirements
Windows 8 works great on the same hardware that powers Windows Vista and Windows 7:
Of course, taking advantage of touch input requires a screen that supports multi-touch.
In addition to running on x86 and x64 devices, Windows 8 delivers even greater flexibility by running on
ARM devices. Depending on the technology you use, write your Metro style apps once and they can run on
any supported architecture.
Introduction to Background Tasks
Windows Developer Preview provides a number of features to make an app look alive with content even when the app is suspended:
Push notifications and the background transfer API are optimized for system performance and longer device battery life, so it’s best to use these features whenever possible. If a suspended app must run its own code to do other kinds of work, Windows Developer Preview provides apps with the ability to create background tasks.
Allowing apps to run code in the background when they are suspended is a powerful feature and is designed primarily for the real-time class of apps such as mail, VOIP, and chat apps. The background task execution environment is a restricted resource-managed environment and background tasks only receive a limited amount of CPU time. Background tasks should be used for small work items that have no interaction with the user and only provide limited service. Long running or expensive workloads in the background will deplete the user’s battery and are not an appropriate use for background tasks.
Scenarios that are appropriate for background tasks include downloading mail in the background, or showing a toast notification for an incoming VOIP call or a chat message, or reacting to a change in system condition (for example, UserAway) and updating the server with this information. Scenarios that are not appropriate for background tasks are indexing mail, transcoding photos, running SETI type workloads, or anything that requires user interaction through displaying UI or audio.
Real-time apps and the lock screen
To prevent abuse of system resources or excessive workloads that might drain the device battery, only apps that are on the lock screen are allowed to use background tasks. If an app that is not on the lock screen tries to access the time trigger or the real-time communication trigger, its background task will not be triggered.
If the user notices an app is running often and taking up too many resources in the Task Manager, the user can remove the app from the lock screen to prevent it from performing its background task activity. An app can register to be notified when it is added or removed from the lock screen by registering a background task with the LockScreenApplicationAdded or LockScreenApplicationRemoved triggers provided in the SystemTrigger class.
Terms and definitions
A Metro style app registers its background tasks with the background task infrastructure by using the BackgroundTaskBuilder class. The background task is implemented as a class that implements the IBackgroundTask interface. This class name is specified in the TaskEntryPoint property of the BackgroundTaskBuilder class. The background task class is hosted in an in-proc server DLL which can be loaded in an app executable, as part of the app package, or in the system-provided backgroundTaskHost.exe.The background task can also be implemented as a JavaScript worker. The JavaScript worker is included in the app as a JavaScript file and the name of the JavaScript file is specified in the TaskEntryPoint property of the BackgroundTaskBuilder class. The JavaScript worker runs in the system-provided WWA host process similar to a web worker.
A background task must have exactly one trigger that describes the trigger event to launch the background task. The trigger is specified with the SetTrigger method of the BackgroundTaskBuilder class.
Background task trigger events
A background task can optionally have one or more conditions that must be true for the task to launch. Background conditions are used by an app to describe the set of conditions required to perform meaningful work. For example, if the background task requires the Internet but there is not currently an Internet connection, an InternetAvailable condition can be used to tell the system to wait for the Internet connection to be restored before launching the background task. Background conditions are specified with the AddCondition method of the BackgroundTaskBuilder class.
Background task conditions
Background task infrastructure
When the trigger is fired, the background task infrastructure launches the class associated with the trigger regardless of the state of the app. The activation of the background task does not involve any UI and it does not bring the Metro style app to the foreground. The triggers provided in the system are timer, system event and real-time communication.
When the trigger is fired, the system infrastructure activates the class within the app container.
Background tasks and the Metro style app lifecycle
When a background task is launched, an app can be in any of the following states: Running, Terminated or Suspended. If an app is in the Running state, it is the only app in the foreground. If an app is not running, it is in either the Suspended or Terminated state. A suspended app is resident in memory, but its work is not being scheduled by the system. A terminated app is not in memory, either because it was never launched or because it was in the Suspended state and was terminated by the system.
The background task executes in either the system-provided backgroundTaskHost.exe or the app process. The app specifies the execution host in its manifest.
If a background task executes in the system-provided backgroundTaskHost.exe, it is launched independently of the state of the app; it is not necessary for the system to change the app’s state. This option is preferable because launching the task within backgroundTaskHost.exe is faster and provides better performance than launching the background task within the app. BackgroundTaskHost.exe is launched within the same app container as the app and it terminates after the background tasks finish.
If a background task executes within the app process, the background task infrastructure might need to change the state of the app:
Background task implementation concepts
All background task registrations are persistent; that is, the app doesn’t have to be running for the background task to be triggered. For example, if a background task should run 6 hours from now to download RSS feeds, the app registers the background task using TimeTrigger with the appropriate value. When the time arrives, the background task is launched regardless of whether the app is running or the machine has been restarted since the task was registered.
Condition latching behavior
When a trigger is fired, the background task infrastructure checks whether all the conditions are satisfied. If not, the infrastructure waits until all the conditions are satisfied before executing the background task. This behavior is called latching, because the background task infrastructure latches the trigger to a fired state.
If a condition changes value while a trigger is latched, the background task infrastructure re-checks to see if the conditions are satisfied for the background task. If so, it launches the task.
Background task progress reporting
The background task can use the progress handler to report progress to the app when the app is running in the foreground. The progress reported from the background task can be used to display UI or a progress bar in the foreground app.
The IBackgroundTaskInstance that is passed to the Run method is used to communicate progress to the foreground app. The interface has a Progress property which can be updated by the background task. The app must register a progress handler to receive progress updates from the background task when the app is in the foreground. The progress handler in the app does not receive the updates from the background task if the app is Suspended or Terminated.
Background task completion notification
The foreground app can also register a completion handler to be notified when the background task completes. The completion status or any exception thrown in the Run method of the background task is passed to the completion handler in the foreground app as part of the BackgroundTaskCompletedEventArgs input parameter. If the app is in the Suspended or Terminated state, it does not receive the completion notification. If the background task needs to preserve the information that it ran successfully, it must persist the information using State Manager or another means such as a file that the app can read when it comes back to the Running state.
Background task cancellation
Background tasks can be cancelled by the system in certain conditions. To receive cancellation notifications, the app’s background tasks should register a cancellation using the IBackgroundTaskInstance. When the system cancels a background task, it provides a reason in the BackgroundTaskCancellationReason parameter of the BackgroundTaskCanceledEventHandler.
If the background task does not respond to the cancellation notification and return from its background task within five (5) seconds, the app is terminated. To ensure a graceful exit and the guarantee that state is saved, apps are encouraged to register a cancellation handler and save state and exit the background task in response to a cancellation request.
Background task enumeration and re-associating handlers
When a Metro style app is launched from the Terminated state, it can enumerate all background tasks it has registered with the system using the BackgroundTaskRegistration.AllTasks method. Because the app has just been launched, it must re-associate its progress and completion handlers with the background tasks. Even if the app has previously registered those associations, they are no longer valid because the app was terminated and removed from memory. Only the progress and completion handlers must be re-associated. The background task registrations themselves are persistent.
The progress and completion handlers are event delegates or functions and are not defined in the manifest as are the class names (EntryPoint), which is why they need to be associated after the app has been launched.
If the app was resumed from the Suspended state then it does not have to re-associate its progress and completion handlers for its background tasks. They remain valid, because a suspended app remains in memory.
foreach (var task in BackgroundTaskRegistration.AllTasks)
{
task.Value.Progress += new BackgroundTaskProgressEventHandler(OnProgress);
task.Value.Completed += new BackgroundTaskCompletedEventHandler(OnCompleted);
}
var iter = Windows.ApplicationModel.Background.BackgroundTaskRegistration.allTasks.first();
var hascur = iter.hasCurrent;
while (hascur)
{
var cur = iter.current.value
cur.addEventListener("progress", onProgress);
cur.addEventListener("completed", onCompleted);
hascur = iter.moveNext();
}
App updates or servicing
Background task registrations persist across app updates. If an app is updated, its registrations continue to be valid and will be triggered. The app developer must ensure that the background task EntryPoint still exists in the updated version of the class, otherwise the background task will error out during activation. To delete a previous background task registration upon update, an app can register a background task for a ServicingComplete trigger to be notified when the app is updated, and unregister background tasks that are no longer valid.
Sample background task
private void RegisterBackgroundTasks()
{
BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
builder.Name = "BackgroundTestClass"; // Friendly string name identifying the background task
builder.TaskEntryPoint = "BackgroundTaskLibrary.TestClass"; // Class name
IBackgroundTrigger trigger = new TimeTrigger(15, true);
builder.SetTrigger(trigger);
IBackgroundCondition condition = new SystemCondition(SystemConditionType.InternetAvailable);
builder.AddCondition(condition);
IBackgroundTaskRegistration task = builder.Register();
task.Progress += new BackgroundTaskProgressEventHandler(task_Progress);
task.Completed += new BackgroundTaskCompletedEventHandler(task_Completed);
}
function RegisterSampleBackgroundTaskWithCondition()
{
var builder = new Windows.ApplicationModel.Background.BackgroundTaskBuilder();
builder.name = "BackgroundTestWorker";
builder.taskEntryPoint = "BackgroundTestWorker.js";
var myTrigger = new Windows.ApplicationModel.Background.TimeTrigger(15, true);
builder.setTrigger(myTrigger);
var condition = new Windows.ApplicationModel.Background.SystemCondition(Windows.ApplicationModel.Background.SystemConditionType.internetAvailable);
builder.addCondition(condition);
var task = myTaskBuilder.register();
task.addEventListener("progress", task_Progress);
task.addEventListener("completed", task_Completed);
}
Background task class
C#
BackgroundTaskLibrary.TestClass implements the IBackgroundTask interface that has a Run method. The Run method is where the actual background task code exists. The class implementing IBackgroundTask interface must be sealed. The Run method receives IBackgroundTaskInstance as an input parameter which contains information about the task (trigger and conditions).
namespace BackgroundTaskLibrary
{
public sealed class TestClass:IBackgroundTask
{
private int globalcount;
void IBackgroundTask.Run(IBackgroundTaskInstance taskInstance)
{
globalcount = 0;
for (int i = 0; i < 100000; ++i)
{
Interlocked.Increment(ref globalcount);
taskInstance.Progress = (uint)globalcount;
}
}
}
}
JavaScript
BackgroundTestWorker.js is a JavaScript file included with the app. The script in this file runs when the background task is triggered. The script can access IBackgroundTaskInstance through the WebUIApplication object as a static property. A JavaScript background task must call close after it has completed its work so that the task can be shut down.
(function()
{
"use strict";
var globalCount= 0,
backgroundTask = Windows.UI.WebUI.WebUIApplication.backgroundTask;
for (int i = 0; i < 10; i++)
{
globalCount += 10;
backgroundTask.taskInstance.progress = globalCount;
}
backgroundTask.success = true;
close();
})();
Adding a background task to a solution
To add a C# class library implementing the IBackgroundTask interface to your project, follow these steps:
To add a JavaScript background worker to your project, add a new dedicated worker file.
Background task sample manifest
Metro style apps must be manifested to use background task extension contracts. Every Metro style app has an associated manifest that is used by the app to indicate it is using the background task extension contract. An app’s manifest can contain multiple background task extensions with different class names (EntryPoint) or JavaScript files, executable, or task types within the same app.
<Package>
<Applications>
<Application Id="App" Executable="application2.exe" EntryPoint="Application2.App">
<VisualElements DisplayName="Application2" Logo="Images\Logo.png" SmallLogo="Images\SmallLogo.png" Description="Application2" ForegroundText="light" BackgroundColor="#222222" InitialRotationPreference="portrait">
<SplashScreen Image="Images\SplashScreen.png" />
</VisualElements>
<Extensions>
<Extension Category="windows.backgroundTasks" Executable="backgroundTaskHost.exe" EntryPoint="BackgroundTaskLibrary.TestClass">
<BackgroundTasks>
<Task Type="timer" />
<Task Type="systemEvent" />
</BackgroundTasks>
</Extension>
</Extensions>
</Application>
</Applications>
<Capabilities>
<Capability Name="internetClient" />
</Capabilities>
</Package>
If the manifest does not specify an executable, then the executable is the same as the app executable.
<Package>
<Applications>
<Application Id="App" StartPage="default.html ">
<VisualElements DisplayName="Application2" Logo="Images\Logo.png" SmallLogo="Images\SmallLogo.png" Description="Application2" ForegroundText="light" BackgroundColor="#222222" InitialRotationPreference="portrait">
<SplashScreen Image="Images\SplashScreen.png" />
</VisualElements>
<Extensions>
<Extension Category="windows.backgroundTasks" StartPage="BackgroundTestWorker.js">
<BackgroundTasks>
<Task Type="timer" />
<Task Type="systemEvent" />
</BackgroundTasks>
</Extension>
</Extensions>
</Application>
</Applications>
<Capabilities>
<Capability Name="internetClient" />
</Capabilities>
</Package>
The extension must specify the triggers used by the class or JavaScript file. If the trigger type is not specified correctly, the Register operation fails.
Background task resource management
Background tasks are meant to be short-lived tasks that do not consume a lot of resources. If an app is running and the user is interacting with the app in the foreground, then no CPU quota or resource management policies are applied to the app’s background tasks.
An app on the lock screen receives a certain amount of CPU time at regular intervals for its background tasks. If the app uses all of its available CPU time, its background tasks are suspended until the app’s CPU quota is replenished at the next generation for CPU quota updates.
Each app on the lock screen receives two seconds of CPU time every 15 minutes which can be utilized by all of the background tasks of the app. At the end of 15 minutes, each app on the lock screen receives another two seconds of CPU time for use by its background tasks. Any unused CPU time in the 15-minute interval is lost and not accumulated by the app. If a background task is suspended because it has used its two seconds of CPU time, the message ‘Background work item for package “” with entry point “” was throttled by sandboxing policy’ is logged in the event viewer.
CPU usage time refers to the amount of actual CPU used by the app and not the wall clock time of the background task. For example, if the background task is waiting in its code for the remote server to respond and not actually using the CPU, then the wait time is not counted against the CPU quota because the background task is not using the CPU. CPU usage information is available in Task Manager or more sophisticated tools like xperf, which is available in the Windows Performance Tools (WPT) Kit.
The reason for using CPU usage as a unit of resource management instead of total running time or wall clock time is because that is a more fair metric for measuring actual energy usage of an app. If an app is not using the CPU and might be waiting for input, the CPU could go to a low power state, conserving battery life.
Threading model for background tasks hosted in the app
If background tasks authored in C# or C++ are hosted within the app instead of the recommended backgroundTaskHost.exe, there are some threading model complexities to keep in mind.
Decoupling the background task from the app
For non-JavaScript apps, the background tasks are hosted in an in-proc DLL which is loaded in a multi-threaded apartment (MTA) within the app. For JavaScript apps, background tasks are launched in a new single-threaded apartment (STA) within the WWA host process. The actual background task class can be STA or MTA. Because background tasks can run when an app is in a Suspended or Terminated state, they need to be decoupled from the foreground app. Loading the background task DLL in a separate apartment enforces separation of the background task from the app while allowing the background task to be controlled independently of the app.When an app is suspended, the UI STA thread is blocked in the Windows kernel. This thread is released only when the app transitions back to a Running state in response to user interaction. When the app is in the background and a background task is triggered, all threads in the app except the UI STA thread are unfrozen and the background task is activated in an MTA thread. The UI STA thread remains blocked. If the background task tries to access an object that is owned by the blocked UI STA thread, then it will deadlock. To prevent this deadlock, the background task should not share data between the app and the background task.
Sharing state between the background task and the foreground app
Another aspect to keep in mind if the background task is loaded within the app instead of the recommended backgroundTaskHost.exe is that it cannot rely on accessing memory of the foreground app. Background tasks run regardless of the current state of the app, so background tasks cannot rely on having the app around when they run. The only reliable way for the background task to share state with the app is to use persistent storage such as State Manager or files.
Background task best practices
When using background tasks in your app, follow these best practices:
Avoid the following:
c.d.n
Posty
Komentarze
