Windows Runtime core application and window objects (Windows Runtime apps using DirectX with C++)
[ This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation ]
Purpose
The Windows Runtime provides a core app object, defined as a singleton (and sometimes referred to as the "app singleton"), which represents your app as managed by the Windows Runtime.
Each Windows Store app has an instance of the app object that defines the interoperation between the app and Windows. This object works as an intermediary between your code and the Windows system-level functions, and exposes specific features to your app , such as process lifetime management and system settings, plus window views and events. This app object is defined as the type CoreApplication in the Windows.ApplicationModel.Core namespace.
As a developer of a Windows Store app, you don't directly create an instance of CoreApplication. Rather, the Windows Runtime creates it for your app when the app launches. It is a static type, and the running instance is a singleton object. It has one overloaded method that lets you configure and customize the window view and window event behaviors: CoreApplication.Run.
Note There are two types of app launches: cold starts and warm starts. In a cold start, there is no current instance of the app, and one is created for you. In a warm start, an instance of the app is already running. So the Windows Runtime finds the current process for the running app, and gets a pointer to its instance of CoreApplication instead of creating a new instance.
Let's look at a simple and typical way you can access the CoreApplication singleton.
int main(Platform::Array<Platform::String^>^)
{
// EventsViewSource implements IFrameworkViewSource.
auto frameworkViewSource = ref new EventsViewSource();
Windows::ApplicationModel::Core::CoreApplication::Run(frameworkViewSource);
return 0;
}
The two overloads for CoreApplication.Run take either an activation factory callback, which you implement using IGetActivationFactory, or a specific view framework source, which you implement using IFrameworkViewSource. In the case of this snippet, we assume that you defined your own type that implements IFrameworkViewSource, and specifically the CreateView method on it. You commonly use this overload of CoreApplication.Run to obtain access to DirectX resources and attach them to a the app object's associated CoreWindow.
You use the overload for CoreApplication.Run that takes an IGetActivationFactory type for activating out-of-process servers.
For more info on the how the app object works with DirectX or out-of-process servers, see the following topics:
In this section
Topic | Description |
---|---|
Windows Store apps with DirectX (mostly games) don't use many of the new Windows UI user interface elements and objects. Rather, because they run at a lower level in the Windows Runtime stack, they must interoperate with the user interface framework in a more fundamental way: by accessing and interoperating with the app object directly. Learn when and how this interoperation occurs, and how you, as a DirectX developer, can effectively use this model in the development of your Windows Store apps. |
|
You activate out-of-process server types from your Windows Store app by implementing the IGetActivationFactory interface, which is accessed by the app object. Here we explain how out-of-process servers work with the Windows Runtime and the app object. |
|
With the release of Windows 8, you can use Extensible Application Markup Language (XAML) and Microsoft DirectX together in your Windows Store app. |
|
The app object that defines the run-time representation of your Windows Store app uses a threading model called Application Single-Threaded Apartment (ASTA) to host your app’s UI views. In this topic, we discuss how the threading model for UI views works and how to develop your Windows Store app using DirectX with C++ to use this threading model effectively. |
Developer audience
We assume that you are a Windows C++ developer and you're familiar with the Component Extensions (CX) for Windows C++.