Roaming settings options FAQ in Microsoft documentation says:
The Desktop Bridge helps you bring your existing Windows desktop apps to the Universal Windows Platform. From here, minimal code changes will be required to take advantage of Azure AD app data roaming. The Desktop Bridge provides your apps with an app identity, which is needed to enable app data roaming for existing desktop apps.
But there's no mention of what the "minimal code changes" are.
Should the app make use of Windows.Storage.ApplicationData.Current.RoamingSettings API? I use C++ Win32. Do I need to load .NET framework to use the API? Or is there Win32 alternative?
Should the app make use of Windows.Storage.ApplicationData.Current.RoamingSettings API? I use C++ Win32. Do I need to load .NET framework to use the API? Or is there Win32 alternative?
First, I want to let you know that not all UWP APIs are available for the general desktop app. Please check the UWP APIs available to a packaged desktop app (Desktop Bridge) and UWP APIs callable from a classic desktop app
Then, please see Enhance your desktop application for Windows 10 for more details.
In addition:
Some Windows 10 experiences (For example: a touch-enabled UI page) must run inside of a modern app container . If you want to add these experiences, extend your desktop application with UWP projects and Windows Runtime Components.
Please also check Extend your desktop application with modern UWP components document for more reference.
Related
For building a native windows app which can launch multiple web applications in a webview , i have tried a poc using WinUI3 .Main usecase for this is usb peripheral integrations from the webapps loaded in webview and Single Sign On . Reading more on microsoft documentation , i see some features not supported and some slowness compared to UWP. Do i need to go with UWP for a new app or is the recommendation to go with WInUI3 for a new app development .
Supported Feature List Doc - https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/what-is-supported
Can see WebAuthenticationBroker also in not supported list .
Any guidance on what sdk to use . UWP or WinUI3
WinUI3 is the new technology for Windows Desktop. Although it is not perfect now, but it will be improved. Currently, not all the WinRT APIs are able to be used in WinUI3 apps, but you could use win32 APIs to achieve what you want. So I'd suggest you use WinUI if you are familiar with win32 API can you use win32 API to bypass the limitations.
Compared to WinUI3, UWP is more stable. UWP could use all the WinRT APIs. But some features on UWP are not up to date. For example, some features from WebView2 controls are missing on UWP but available on WinUI like print. Another thing is that UWP apps have limitations like system isolation for accessing local files and local network resources.
Given that UWP, by design, does not support any kind of common Inter Process Communication mechanisms (named pipes, shared memory, ...) what are my options when I want to let existing normal windows program communicate with my UWP app?
Only writing/reading to/from file left, but the UWP documentation is unclear on whether UWP app can access arbitrary files on device.
AppServices is the supported way for UWP and Win32 apps to communicate with each other. Here is the documentation.
There are a couple of samples here in the repo for Desktop Bridge. Desktop Bridge apps typically make use of this feature, but it can be used by regular Win32 apps as well for communicating with UWP apps (no need to do the Desktop Bridge conversion).
By the time I'm writing this, I'm working on a Xamarin cross-platform app (iOS,Android and Windows Phone), using Azure Mobile Services. There is interest of also developing Mac OS X version of this app.
Is there a way to use the Azure for the OS X app, because I can't find anything on the web? Please, be descriptive as possible :)
There is not currently Xamarin.Mac support in Mobile Services. If you look here (https://github.com/Azure/azure-mobile-apps-net-client/tree/master/sdk) you will see there is a Xam.iOS, Android, and Forms project.
You can add a feature request for Xam.Mac, or make an open PR that adds in a Xam.Mac project. I'd assume the main PCL component will work and its just a matter of adding the Mac specific wrappers where needed. I'm not sure how much dev work that would actually entail though to say if its feasible or not.
I've developed a hybrid phonegap application for wp7/iOS/Android. Now customer wants to support window 8(not the windows phone 8). Actually it is possible to create javascript windows store app, but I can't find any way to use C# plugins. Is it possible to create win 8 app without rewriting whole project?
Not sure about the plugin support for Win8 but there is a cordova project for Win8 that might be helpful, I'm guessing you would probably have to add to your plugins to support it, depending on what plugins your using.
https://github.com/apache/cordova-windows
WinRT makes its full API available to Windows 8 & Windows Server 2012 JavaScript apps.
Is it possible for a node.js app running on Windows Server 2012 to get access to this API?
I am asking because not all low level node modules support Windows (e.g. to query metrics) and with WinRT you could access the OS directly.
#Roger Rowland - I'm not sure your information is entirely correct.
MSDN says WinRT can be used in non Store Apps - see "Managed desktop apps and Windows Runtime"
As mentioned above - WinRT APIs could be called from regular desktop apps.
So you can write a native node.js addon which consumes WinRT apis to expose them to javascript.
The Javascript Apps in windows 8 uses a different javascript engine (Microsoft's Chakra) & host than node.js, thus you don't get the "built in" support that apps get.
If you are interested in calling WinRT APIs fron node.js -
We'eve just recently open sourced a new project called NodeRT, which automatically generates node.js native addons which exposes the WinRT APIs into node.js (in the method which is described above): https://github.com/NodeRT/NodeRT
Using this, you should be able to call WinRT APIs from inside node.js.