MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

• WinRT APIs sometimes return Int64 types (alone or in structs) for which there is no equivalent
in JavaScript. The 64-bit type is preserved in JavaScript, however, so you can pass it back to
WinRT in other calls. However, if you modify the variable holding that value, even with
something as simple as a ++ operator, it will be converted into a JavaScript Number. Such a value
will not be accepted by methods expecting an Int64.
• If a component method provides multiple output parameters, these show up in JavaScript as an
object with those different values. There is no clear standard for this in JavaScript; it’s best to
avoid in component design altogether.
The bottom line is that the projection layer tries to make WinRT components written in any other
language look and feel like they belong in JavaScript, without introducing too much overhead.
Scenarios for WinRT Components
Earlier in the “Choosing a Mixed Language Approach” section I briefly outlined a number of scenarios
where WinRT components might be very helpful in the implementation of your app. In this section we’ll
think about these scenarios a little more deeply, and I’ll point you to demonstrations of these scenarios
in the samples, where such are available.
Higher Performance
Increasing the performance of a Windows Store app written in HTML, CSS, and JavaScript is one of the
primary scenarios for offloading some work to a WinRT component.
When evaluating the performance of your app, keep an eye open for specific areas that are
computationally intensive or involve moving a lot of data around. For example, if you found it necessary
to implement an extended splash screen for those exact reasons, perhaps you can reduce the time the
user has to wait (especially on first launch) before the app is active. Any other situation where the user
might have to wait—while they might have anything better to do than watch a progress indicator!—is a
great place to use a high performance component if possible. Clearly there are scenarios where the
performance of the app isn’t so much the issue as is network latency, but once you get data back from a
service you might be able to pre-process it faster in a component than in JavaScript.
Another great place to insert a high-performance component is in an app’s startup sequence,
especially if it has extra work to do on first run. For example, an app package might include large
amounts of compressed data to minimize the size of its download from the Store, but it needs to
decompress that data on first run. A WinRT component might significantly shorten that initialization
time. If the component uses WinRT APIs to write to your app data folders, all that data will also be
accessible from JavaScript through those same APIs.
748