The examples I have found for using a LayoutTransformer with windows phone are all from before they split off the Windows Phone Toolkit from the Silverlight Toolkit.
The Windows Phone Toolkit does not have the LayoutTransformer.dll that was referenced.
So the question is, what do you use to do a LayoutTransform now?
Literally, just use the code from the Silverlight toolkit with minor changes.
Here's how to do it for Windows 8 (note: this is from my blog). You can reuse this completely, just change a few namespaces and at one place from 'protected' to 'public' and it builds and works.
Edit: I published a WP8 version on GitHub. Enjoy :)
Related
This C++/WinRT announcement states "What this also means is that you no longer need to wait for us to update GitHub following the release of a new Windows SDK. Indeed, we will no longer be publishing the updated headers on GitHub at all since you can get them directly from the Windows SDK."
However if one delves one click further one finds that the "Windows 10 Preview Build of the SDK [is] to be used in conjunction with Windows 10 Insider Preview (Build 17025 or greater)" and "Installation on an operating system that is not a Windows 10 Insider Preview build is not supported and may fail."
Right now must one install a Windows Insider Preview of Windows 10? This is either a scary and lengthy process or straight impossible depending on one's admin rights.
Or can one grab the SDK and use the C++/WinRT bits on a box with a standard Windows 10 build?
Is the easiest route for some aspects of the C++/WinRT toolchain still GitHub?
How about if one is developing on a non-Windows-10 box, e.g. Windows 7? Zillions of commercial developers are in this situation and aren't in control of that.
Will the situation change and if so when?
Going forward does one wait for periodic updates to SDK previews, and if so how does one consume them?
Preview versions of the Windows SDK will not install on a non-Insider build of Windows. This is a restriction of the Windows SDK and not specific to C++/WinRT. In the long run (once RS4 ships) this won’t be a problem since you’ll be able to install the final Windows SDK for RS4 without this restriction.
In the short term, you need an Insider build of Windows to install the SDK, but you can then use that to target previous versions of Windows. I’m not sure whether it would work on Windows 7, but I don’t think that any developer using C++/WinRT would care to use Windows 7 when the Windows Runtime isn’t even available on that version of Windows at all.
The cppwinrt.exe compiler also relies on Windows 10 APIs to function. While this isn’t a dependency of code built with C++/WinRT, it is a requirement for building C++/WinRT components. Of course, the resulting binaries can then be executed on older versions of Windows, provided you handle light-up in the usual ways, such as with delay-loading.
Namespace Microsoft.Phone.Tasks is not available in XAML page code behind file of my Windows Phone application. Please see the screenshot.
In the properties windows of the project I see:
Target: Windows Phone 8.1
Am I missing an assembly reference or something?
Windows Phone 8.1 XAML apps don't have Microsoft.Phone.Tasks namespace to make common UI framework with windows Runtime APIs. Still you can code up a few tasks by using Windows.ApplicationModel namespace. As you havent claried which task you want to use, so here's the link to the whole MSDN article. http://code.msdn.microsoft.com/windowsapps/WindowsPhone-Store-81-vs-25c80c2a
From your Screenshot. I see your project is Windows Phone 8.1, not Windows Phone Silverlight 8.1 . Please see your Solution Explorer, is it Windows Phone 8.1? If so, there are not Microsoft.Phone.Tasks namespace anymore. If you want to choose picture, you should use FileOpenPicker.
When sharing code between Windows Phone 8 and Windows 8, the two core options for developers are 1) Windows Runtime Components and 2) Portal Class Libraries.
Windows Runtime Components use WinRT and can be projected into all the supported languages. They require linked files in separate projects (binaries) when used on different platforms. They, however, share 90% of the available WinRT APIs.
Portable Class Libraries are a subset (sometimes a significant subset) of the BCL that has binary compatibility across platforms. They can be used on WinRT applications but also on other project types like Silverlight, Xbox, etc.
When a developer is choosing a "sharing strategy" which project type is the go-to technique to do the best job sharing code between Windows Phone 8 and Windows 8? Thanks.
It depends what form of sharing you need:
1) If you have a common C++ business logic layer you can use Windows Runtime (WinRT) components to expose this to both Windows Phone and Windows Store app (that's the only use-case for Windows Phone as you can't write a WP8 app using JavaScript or use .NET to author a WinRT component).
You'd have to build two separate WinRT components however, one for Phone and one for Windows Store. It should be possible to share the C++/CX code of your WinRT interop layer using preprocessor directives (#if) to mark the platform specific code.
2) You have business logic in C#/VB that only has dependencies on the .NET APIs which are available in a Portable Class Library. Then you can use Portable Class Library (PCL) to contain that logic. Basically if you can build your library into a PCL DLL then this should work. You can then reference this PCL in binary form in both Windows Phone and Windows Store app.
However as Martin has said you need to take care when using 3rd party libraries as these will also need to be built for PCL. Some 3rd party libraries are already available in PCL form (JSON.NET for example).
3) You want to share code for that has platform API dependencies (or 3rd party library dependencies) which are not supported by PCL. Then you'd need to create separate DLL libraries, one per platform. You can avoid code duplication using linked C#/VB source files and use a build flag (#if again) to allow small code changes between your target platforms.
If you want to share code between Windows Phone 8 and Windows 8, then you cannot use Windows Runtime Components, because there are different components used for Windows 8 and different for Windows Phone 8 and they are not interchangeable.
I would go for either Portable Class Libraries for some simple generic libraries, or for code sharing via links and #if WP8 compilation directives - this just works and is more powerful than Portable libs.
Keep also in mind that most external libraries like MVVM Light cannot be referenced in Portable Libs, so if you want to use them, you have to use the code sharing via file references.
For some guidance on how to effectively use Portable Class Libraries to share code between platforms, see this blog post: How to Make Portable Class Libraries Work for You
This question is no longer relevant with the introduction of Windows
Phone 8.1 Universal Apps in Visual Studio 2013 Update 2 which supports
Shared Projects.
Wait a moment, as for me even in Visual Studio 2013 Update 4 this question is still relevant because there are two types of projects there:
Class Library (Portable for Universal Apps) - PCL
and
Windows Runtime Component (Portable for Universal Apps) - WinMD
I can see only one big difference between them:
WinMD uses only WinRT and PCL could be used also with .Net and Silverlight. But I also want to know more about which one and when better to choose.
we have been use cocos2d for windows 8 build metro game . so we want use xaml control UI in cocos2d ?
is there have soluction or suggestion?
just try one night i have been fix this problem. you can click fllow link:
DirectX and XAML interop (Windows Store apps using C++ and DirectX) (Windows) http://msdn.microsoft.com/en-us/library/windows/apps/hh825871.aspx
With the release of Windows 8, you can use XAML and Direct X together in your Windows Store app. The combination of XAML and DirectX lets you build flexible user interface frameworks that interop with your DirectX-rendered content, and is particularly useful for graphics-intensive apps. We explain the structure of a XAML app that uses DirectX, and identify the important types to use when building your XAML app to work with DirectX.
soluction as fllow link:
http://www.cnblogs.com/chenkai/archive/2012/11/29/2794983.html
by chenkai
Here's a template project in my github:
https://github.com/chanyuenpang/cocos2dxaml
I originally assumed that Metro style apps were managed (.NET) assemblies whether they are written in C# or C++ and I thought C++ for Metro style apps would be similar in concept to C++/CLI.
However, I now heard on a DotNet Rocks podcast that Metro style apps written in C++ are native. Nevertheless I understand that Metro style apps run on all three CPU architectures Metro is available for. How is this accomplished? Do Metro style apps come with different binaries and only one is chosen/downloaded? Or is it like on Mac OS X where one binary can contain code for different CPUs?
Code that uses only system or OS services from WinRT can be used
within an app and distributed through the Windows Store for both WOA
and x86/64.
from this MSDN blog page
If you go watch this BUILD video things should start to clear up -- http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C (A .NET developer's view of Windows 8 app development)
Basically there is a CLR (.NET 4.5) running. I didn't say a full CLR. WinRT from a .NET perspective is just a .NET Profile (sort of a way that they can layout the API differently exposing or hiding things). The new WinRT APIs use a new version of [gulp] COM, but it is optimized for use with .NET. I'm not 100% sure on the C++ angle. I suspect with C++, you have a few options. Compile for each platform (arm and x86) or compile to IL. Not sure if this helps you at all (I hope so).