What are the various options to distribute a Windows 10 application? The application will be built using the Metro UI. Are there advantages or restrictions involved with the various options? I'm new to Windows development and haven't been able to find a definitive answer to this question.
Our application may end up being a Universal Windows Platform application. Does that decision imply things with regard to distribution?
I've read some things that imply distribution through the Windows Store means you are limited to a smaller set of APIs.
Our client has Microsoft SCCM set up. How is SCCM different from the Windows Store?
In order to run Windows apps you only have the option of publishing them on the Store or enable developer mode on all machines you install it on and sideload the app.
The usable API and its limitations are in both cases the same.
See also: Sideload your app package
Related
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.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
Is "app" just a term that refers to a family of tiny, light-weight mobile-device-centric applications -- a trend that started with the Apple i-generation of devices and later found its way to Android and Windows 8?
If the same program were available both as an app and as an application for the same platform, what difference does it make to the system running it? For instance, Angry Birds for Windows is available as :
Angry Birds app for Windows 8/RT and Angry Birds app for Windows 7 (runs on Pokki)
versus
Angry Birds for PC
From a developer's perspective, are the above two just the same code compiled differently to produce binaries suitable to the target?
Also, now that platforms like Mac(iOS/OSX) and Windows 8 are common to mobile computers as well as desktops, is the line distinguising apps from native applications being blurred?
UPDATE:
I'm not questioning the choice of the word usage as in Appropriate use of “app” vs “application”. This question has more to do with how apps differ from native applications in terms of memory footprint, resource utilization, dependence of execution subject to presence of runtime environments on the client machine etc.
UPDATE 2:
Microsoft is encouraging Windows developers to build apps for Windows 8. Apart from additionally having to adhere to Windows Store app guidelines, how is what they build different from what they've been building all along?
App is just short for application. On some platforms the abbreviated name seems to have stuck... There is no technical meaning other than "application for this platform".
On windows 8 the new style programs are built differently from "desktop" applications. (They really have to sort out the names, metro apps at least gave you a name for it...). It's not just the same program rebuild for a different platform as the methods of interfacing with the system is a bit different. There is a new runtime library and a much more restricted runtime environment.
Windows 8 is different than Windows 7 and previous OSs because it has some additional features that developers can use to make their apps more alluring for the users, features like:
1. charms - settings, search, share
2. snap view
3. concept of store apps
4. new design language for store apps
5. Live tiles etc.
Windows 8.1 is different than Windows 8 because it essentially provides an update to the W8 features, for example:
1. roaming settings
2. Hero search
3. snap view - split the screen into any size
4. concept of universal app development
Windows 10 is different than windows 8.1 in a more stronger sense so to speak because a lot has changed, such as:
1. Concept of app targeting to single UAP
2. new XAML controls
3. cortana
4. action center
5. inking
Hope this helps.
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. 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. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
If BREW MP has JVM ( java - car ) , If it supports all Java ( J2ME Applications),
There is no need to develop applications through BREW , TBT etc....is it true?
In slide 10 of this "BrewMP Overview" Uplinq 2010 presentation, you can see that there are several frameworks available with BrewMP, including Java.
The biggest benefit of Java is its wide-ranging compatibility, but to actually achieve this compatibility also restricts you to the most common denominator of features across the platforms, as well as the "Java sandbox" that gives you very limited access to the phone. For many applications this is a good tradeoff to make and that's why Java apps are widely found.
BrewMP apps, with correct permissions, can interact with most components of the phone - connectivity, hardware sensors, contact / messaging databases, etc. which allows you to have very deep integration with the device. When a developer wants the experience to be seamless, it usually means choosing a particular platform that is used on the device, and working with it.
HTC Smart and HTC Freestyle are already equipped with Java VM (J2ME) while shipping.
HTC Freestyle:
http://www.mobileheart.com/cell-phone-reviews/htc-25/htc-Freestyle-2578.aspx