The System.WindowsRuntimeSystemExtensions class provides several AsTask extension methods for converting one of these interfaces to a Task, as well as AsAsyncOperation and AsAsyncAction extension methods for converting in the opposite direction. These are two different abstractions for the same set of asynchronous patterns. The next line of code runs in parallel with ShowAsync's background workĪsynchronous methods in the Windows Runtime return one of several interfaces such as IAsyncOperation or IAsyncAction. IAsyncOperation operation = dialog.ShowAsync() For example, showing a MessageDialog (discussed in Chapter 14, “Other Controls”) requires a call to ShowAsync: MessageDialog dialog = new MessageDialog( "Title") You can easily identify such methods by their Async suffix. Whenever the Windows Runtime exposes a potentially-long-running operation, it does so with an asynchronous method that performs its work on a background thread. Windows Runtime APIs are designed to make it really hard to block a UI thread. ![]() ![]() The Windows Runtime also prevents UI threads from calling each other directly, as that would be prone to deadlock. This prevents a huge class of bugs that plague traditional desktop apps, and means that UI objects generally don’t need locking to protect themselves. On the other hand, arbitrary code is prevented from calling into the UI thread while it is doing work. In other words, if you make a call from a UI thread to another thread (or process), and that thread needs to call back to the UI thread, the Windows Runtime does a lot of work to track this and allow it. But they have an enhancement that COM’s STA threads do not: they are not reentrant, unless the incoming call is logically connected to the one in progress. ASTA stands for App Single-Threaded Apartment, which is a nod to COM’s notion of single-threaded apartments (STA).ĪSTA threads are similar to COM’s STA threads in that they provide an easy-to-program, single-threaded experience. In documentation and error messages, UI threads are sometimes referred to as ASTA threads. This makes them very natural to use in C# without worrying about threading or COM-style apartments. Outside of the XAML UI Framework, most Windows Runtime objects can be created and used on any thread, and you control their lifetime. This includes every class deriving from DependencyObject, which is most classes in the XAML UI Framework. UI objects must be created and called on a UI thread. Yet the app has two UI threads running in this scenario, so your code can always count on global state created by the main thread. For example, if an app is activated via a contract such as the File Picker contract (see Chapter 21, “Leveraging Contracts”), the app typically displays a special file-picking window and never displays its main window. There is always a main UI thread, even if the corresponding main window has not yet been shown. Windows manages all background threads for you. ![]() ![]() Instead, you schedule it via a static RunAsync method on the class. If you have a long-running computation to perform, which therefore isn’t appropriate for a UI thread, you don’t get to explicitly create a background thread for the task. Each window has its own UI thread, so an app with multiple windows (covered in the upcoming “Displaying Multiple Windows” section) has multiple UI threads. Typically, an app has a single UI thread, but that’s only because an app typically has a single window. Therefore, long-running work should always be scheduled on a background thread. (Other types of threads exist, but they are implementation details.) As much as possible, a UI thread should be kept free to process input and update UI elements. Universal apps have two types of threads that can run your code: UI threads and background threads. Learn More Buy Understanding the Threading Model for Universal Apps Universal Windows Apps with XAML and C# Unleashed
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |