Now as Build 2015 ended it's time for some thoughts. Android and iPhone Apps running on Windows? What does this mean?
Microsoft is building bridges - bridges to bring all developers on board to offer apps for Windows 10, for using Microsoft Azure and Microsoft Office.
Let's get into more details. Of course an important announcement was to build Windows 10 apps using
- Android Runtime
- iOS
- Classic Windows apps (.NET/Win32)
- Web apps
This should bring a lot more apps to the Windows ecosystem. However, what are the restrictions, what can be done? With all these technologies it's possible to take advantage of many features of the Windows Runtime, such as live tiles, active notifications, and in-app purchases. Let's have a look at the different bridges.
Android Runtime - Project Astoria
Just a few code changes are needed to run Android apps on Windows 10. A subsystem isused to map the app to Windows. With this, the Android IDE can still be used. This IDE will be extended with interop capabilities and a Windows phone emulator. The Android app canbe packaged as a Windows apps and added to the store. From the subsystem, Android platform capabilities are redirected to Windows platform capabilities. Accessing the file system, contacts, sensors, camera, networking, application lifecycle and more will directly map. Windows features such as live tiles are available as well. For this, the app needs to be extended. Of course not everything of the Android API's will be supported. The Android platform is already very fragmented, and this shouldn't add a lot of additional hurdle for Android developers and win on another platform.
iOS - Project Islandwood
With iOS the bridge is very different. Existing Xcode projects can be imported into Visual Studio. Visual Studio includes intellisense for Objective-C and compiles this code. Some iOS APIs can be used - the most used APIs arei implemented first. Notifications are backed by Windows Notifications and appear in the Action Center, StoreKit is bridged to Windows In-App purchases, and the FileSystem is mapped. , Objective-C code can be imported within Visual Studio, and this code can make use advantage of the Windows Runtime.
Classic Windows apps - Project Centennial
.NET and Win32 apps can be packaged for the Windows Store and can take advantage of the Windows Runtime APIs. The statement was that anything a Universal Windows app can do can be done from a classic Windows app as well. I need to try this out if the ideas I have are really paossible. Since Windows Vista, native apps that run without admin privileges are not allowed to write to the program files folder and any place in the registry. With this technology, also redirection takes place. There's a differentiation between an app namespace (where app-data and registry information is written to), and the system namespace (e.g. for documents). This is the best way for reusing all the rich client code we have.
Web apps - Project Westminster
Web applications can be packed for the Windows store. This way not all the HTML, CSS and JavaScript code gets copied into the package, but the app makes a request to the URL of the Website. With this it is also possible to get advantage of features of the Windows Runtime. Of course, the Web app needs to verify if it is running as a Windows app or running in the browser. Microsoft already has a long history in Web applications taking advantage of Windows features such as integrating Web apps within the Windows 7 taskbar and offering dynamic content: http://weblogs.thinktecture.com/cnagel/2011/09/taking-advantage-of-windows-7-with-web-pages.html However, this feature goes a lot further.
When is this possible? All the bridges will be made available in summer 2015. More information Universal Windows Platform Bridges.
With all the bridges in place, is there a reason to use XAML and C#? Of course, there is! Resizing through all the different screen sizes is a lot easier with SplitView, adaptive triggers, RelativePanel… Other than new controls with XAML, there's also a lot of of new functionality and performance increasement such as compiled bindings. Compiled binding is not only faster, but also gives better compile-time errors.
Microsoft's Office is using XAML as well. Because of its old code base with C++, Office uses C++ and XAML. The Windows Runtime is very open for this - since Windows 8 it's possible to use C++ with XAML. Most of my apps will be done with C# and XAML.
Using these bridges is only a first step to bring apps to the Windows platform. The next step is to convert them gradually to get all the features.
Visual Studio Code
Microsoft even built more bridges to other platforms and technologies. Visual Studio Code is a free tool running on Windows, Mac OS X, and Linux that is not only a code editor, but also offers Git integration and debugging. It's best used for ASP.NET 5 and Node.js. https://www.visualstudio.com/products/code-vs
The bigger brother Visual Studio of course has a lot more features is now available as release candidate.
Of course there has been a lot more at build, such as the Windows Store for business, turning apps into holograms for HoloLens, lots of new Microsoft Azure features…
Exciting times ahead!
Christian
More information in my Windows Universal Platform workshops!
Comments