When Microsoft announced Silverlight at the MIX conference in 2008, we quickly started to look at what this amazing new technology could do to enable .NET developers to build great web applications for ArcGIS Server. Since both Silverlight and WPF were based on .NET and XAML, we were able to quickly port our Silverlight implementation to the WPF platform. The SDK grew popular very quickly – we even won several awards. When the new Windows Phone platform was announced in 2010, we had a prototype running on a phone within the hour of launch. The parity between the platforms was amazing such that nearly 99% of the source code was shared across the three APIs. This provided a consistent experience for .NET developers building ArcGIS Server clients across all three platforms.
As time passed, we enhanced the WPF API by adding a local server. In essence it was a mini-ArcGIS Server embedded in your application, and using it was similar to using an online server. At the same time a new “ArcGIS core runtime” was built, which gave us a new hardware-accelerated, high performance rendering pipeline as an alternative to the managed display pipeline included with the WPF API since its inception. This is why the Map control in the WPF SDK has an option to use “accelerated display” mode today. We have found that many developers did not use this new mode, and it added some confusion to the SDK, since there were two rendering pipelines and they didn’t support the same things. But we didn’t want to break your existing code and stuck with it. As a result, the new core runtime was considered second class, and most of the API still revolved around being a client to ArcGIS Server (which also explains the namespace “ESRI.ArcGIS.Client”).
In the past year, we have been hard at work, bringing the ArcGIS Runtime to the new Windows Store platform. This platform provides a tight integration between native C++ and .NET libraries. It enabled us to take advantage of and prioritize the new core runtime-based architecture as well as use new C# language features for doing asynchronous code. It gave us a faster and cleaner API to code against. In addition, lessons learned from other SDKs enabled us to improve the developer experience. We heard your feedback that building MVVM style apps was difficult, and improved it. We heard you wanted to render datasets with a large number of features, and we can now make this possible. And support for native code in Windows Phone 8 also means that this API can be shared between Windows Store and Windows Phone apps. We were now building a brand new SDK. It wasn’t just a “client” to ArcGIS Server, and while it looked similar to the Silverlight and WPF SDKs, it was notably different.
This year at the Developer Summit we announced the addition of offline capabilities in all the ArcGIS Runtime SDKs, including WPF. This meant we had to rely more on the core runtime itself, by adding capabilities to work with local data into what was essentially a server API, and it began to feel less natural. The new Windows Store and Windows Phone APIs were already proving there was a better way to do this. So a radical idea started to form: What if we made the new API for Windows Store and Phone available for Desktop developers as well?
The benefits were clear. We would have three identical APIs, meaning you only need to learn one to build apps for the Store, Phone, or Desktop. It also means we could prioritize the integration and use of the core runtime as a first class citizen, giving you a high performance, natural, and refined API to code against. You will even be able to share your code between platforms, so you can build new apps across platforms more quickly.
However there were some drawbacks. It would mean the current version of the WPF SDK would have major breaking changes. Your code would not just work on the latest version, and it would require some effort to migrate existing apps to this new architecture. Our desire to deliver a backwards compatible SDK would not be possible.
We also knew there was much more functionality we wanted to add in the future, and with the significant enhancements to core runtime for using data offline, it looked like a significant change in the API was inevitable. Basically, we would have to break the current API. So we had to make a decision: Do our best to keep the WPF SDK as it is today and make breaking changes over time –or- make a clean break and create a single unified SDK across multiple .NET platforms optimized for using both core runtime and services. In the end, we decided it would be best to introduce a refined, consistent, high-performance API earlier rather than later. And the new enhancements to core runtime, such as offline map use which many people have been waiting for, will be introduced in the new SDK. Personally, knowing the repercussions, this has been one of the hardest decisions we’ve made. At the same time, I’m extremely excited for what we will release soon, and I’m confident you will love it as well.
So what does this really mean?
We will soon be releasing a new SDK, the “ArcGIS Runtime SDK for the Microsoft .NET Framework”. You can use this SDK to build ArcGIS Runtime apps on Windows Desktop, Store and Phone. While it is really three SDKs – one for each platform – we view them as one product for doing .NET development with the ArcGIS Runtime. The platforms themselves are different, thus some of your markup and code will be different, but you will be able to reuse a significant amount of code across platforms. In fact that’s how we’ve built it – the vast majority of the source code is shared across all three platforms.
What does this mean for the WPF SDK?
We will continue to support the existing WPF SDK for some time. We will still release updates, but they will not include any major enhancements.
What does this mean for my existing code?
While your code will not compile as is with the new SDK, in many cases, the majority of the work can be migrated easily. Instead of an event-based API, we use Task with async/await, which will change your code flow and make it easier to read and maintain. I encourage you to use accelerated display in the current WPF SDK, and become familiar with the Task approach for asynchronous programming, which will be available in the next WPF SDK. This will ease your migration from the WPF SDK to the Desktop API in the .NET SDK. Since we will be releasing both SDKs side-by-side you will also have some time to move to the new SDK and eventually take advantage of the new features, such as support for taking maps and data offline and 3D.
When will the ArcGIS Runtime SDK for .NET be available?
It will be released later this year with other ArcGIS Runtime SDKs as version 10.2.1. We also plan to provide a beta at the end of the summer to gather feedback on the new SDK.
Morten Nielsen
Lead Developer, ArcGIS Runtime SDK for the Microsoft .NET Framework
