DevExpress Universal v16.1: Breaking Changes

It must be a truism by now, almost certainly proclaimed by Arthur C Clarke, that Any sufficiently advanced software has breaking changes in a major release. Ours, regrettably perhaps, is no exception. 

In this post, I’d like to emphasize the protocols we have for breaking changes and releases. I am embarrassed to say that we have, to put it mildly, not been very diligent at following them of late, for which I apologize on behalf of DevExpress. Rest assured that over the past few months we have been putting into place some stronger policies with our dev teams about how we expose breaking changes, how we try to avoid them, and how we publicize them.

Fixing software...In essence: breaking changes will be limited to major versions only, as much as we are able. That’s point one. We are essentially saying: here’s a new release with some great new features but in order to provide them we had to refactor the infrastructure (our data classes are a strong example of what I mean), change the API, or modify the behavior somewhere. Changes due to some API being modified or retired or refactored will trigger “deprecated” warnings in your code for at least one major release, preferably two. So, as an example, if the FooBar control’s ShowMe property is being deprecated for a new Show() method in v16.1, then the property should be marked as obsolete in v16.1 and v16.2 (and still work as before) and will disappear in v17.1. We recognize that some customers do not automatically upgrade to a major version straightaway (probably due to breaking changes, sigh), but need some time to evaluate and test whether the upgrade is worth applying or not. I personally do not recommend skipping more than one major version. (In brief: Turn on warnings! Test, test, and test again!)

As part of this effort, we are revamping how we report breaking changes. Prior to this, I’m afraid we could be a little too terse with the descriptions in our breaking changes list. This was bad in a couple of ways: first, it sometimes wasn’t at all obvious how to fix your code, and second, it increased the workload on our support team as the inevitable questions came in. So, from now on, you should see more complete details in our entries for the breaking changes page.

I’ll expand on this by stating that we should formally publicize the changes somehow, rather than just sweeping them under the metaphorical carpet in a page that is hard to find. This could either be by email (although I would guess that the majority of recipients would not read it or even complain about spam) or as a blog post like this. Personally speaking, I would rather a blog post: it’s stays up and can be found in the future, it can be updated to expose more details if needed, it’s more conversational.

Point two is that we recognize that bug fixes we provide in minor releases may also break code. A bug fix is, in and of itself, a breaking change, albeit a revision to repair unwanted behavior. However, we shall do our utmost in those situations to (a) minimize the impact and breadth of these required changes, and (b) to publicize them to our customers. Our overall aim is to make updating to the next minor release as uneventful as possible; after all, the biggest reason to update is to fix bugs that you may (or may not yet) have encountered.

Point three is that undocumented classes, interfaces, methods, and properties are fair game. Please try not to use undocumented identifiers in your code. Assume they will change at a moment’s notice. If the support team supply a workaround that uses undocumented identifiers, we shall be putting a strong warning in the post that the workaround may break when the official fix is provided.

Without further ado, here is the full list of breaking changes for Universal v16.1. You will see some that are API changes and that will possibly break your code, and some that are behavioral in nature (for example, the iOS theme in ASP.NET has changed) and should please your users. Note that this list is still being updated as far as details go – although we’ve released the beta, the release is still a week or so away – but you should not see any new changes being reported.

I and my fellow members of the management team are interested in hearing your views on breaking changes. If you have feedback or comments, please comment here (we shall all see it) or email me at julianb@devexpress.com and I will circulate the responses among the team. As always, thank you for choosing DevExpress.

DevExpress Universal v16.1: Webinar schedule

Given the recent blogging on these community pages, you may naturally have already come to the conclusion that Universal v16.1 is getting close to release. You are not far wrong: the finishing touches are being applied, the latest tests are being run, the final documentation is being written. The code is ready to beta if you are a Universal customer. Time then for some webinars to show you what’s new, how it looks, and how it works.

If you visit our webinars page (it’s easy to remember: devexpress.com/webinars), you’ll see that we have set up four:

6-Jun-2016, 10am Pacific. v16.1: What’s New for Windows Developers. Join Paul Usher and me to learn about the new products and features shipping inside our updated WinForms and WPF Subscriptions.

7-Jun-2016, 10am Pacific. v16.1: What’s New for ASP.NET Developers. Join Mehul Harry and Don Wibier and learn about the new products and features shipping inside our updated ASP.NET Subscription.

8-Jun-2016, 10am Pacific. v16.1: What's New for Reporting and Dashboards. Paul and I again, demonstrating all the new features DevExpress will introduce across the Reporting and Dashboard platforms.

9-Jun-2016, 10am Pacific. v16.1: What's New for HTML5 and Mobile. Mehul and Don review the newest products and features shipping inside DevExtreme v16.1.

There’s plenty of time to register, but remember it’s first come, first served. Spaces are limited so my advice is to register early to make sure of your seat. See you online in June!

DevExpress VCL Subscription supports RAD Studio 10.1 Berlin

We recently released v15.2.5 of the DevExpress VCL Subscription to our subscribers. There were a couple of hidden new features in there, and I wonder how many people spotted them before reading this official announcement.

The first new feature was support for RAD Studio 10.1 Berlin, which was released a day or so ago. So if you have already installed RAD Studio Berlin (or are about to), you can immediately download v15.2.5, install it, and be productive in moments.

The second new feature is a new control, the Tile Bar Control. We were so pleased with the way this control turned out that we decided to publish it as part of a minor version so you could use it immediately in your applications, rather than having you wait for v16.1. So, what is a Tile Bar Control? Basically, the Tile Bar implements a tile-based menu. It consists of equal-sized tiles arranged in a single row.

DevExpress VCL Tile Bar Control

Furthermore any tile can have a dropdown associated with it. In this case, the tile displays a dropdown button on the side. In the image above the Products and Customers have this dropdown. Here’s the result of clicking the button:

DevExpress VCL Tile Bar Control: dropdown

As can be deduced from looking at the images, the Tile Bar control is fully touch-capable.

To show how to use this new Tile Bar, we’ve added a new demo application: the Touch-enabled Hybrid sample application.

Please download v15.2.5, install into RAD Studio 10.1 Berlin, and take a look at this new control. Let us know what you think.

DevExpress Scheduler controls: big changes are coming in v15.2

One of the more popular controls we have in our platforms suites is the scheduler control. Not every app needs a scheduler, but when you’re having to worry about scheduling resources and appointments, it’s invaluable.

Although everyone is pretty happy with the scheduler user interface, for a while now we’ve been getting feedback related to performance. Consequently over the past few months we’ve put in a lot of effort into speeding up the scheduler, especially with regard to rendering the layout and data (in this version) and laying down some infrastructural improvements ready for speeding up data retrieval (in a future version). Fairly early on with this exercise we determined that some of our data structures were not optimal and so had to redesign and refactor them.

First the good news: we have managed to achieve a significant performance improvement by adjusting the way the layout is calculated. For day-view-based views (that is, Day View, Work Week View, and Full Week View) scrolling the views and switching between them is a snap because response times have been significantly decreased. Appointments now scroll smoothly. We’ve tested with as many as 5000 appointments in a view and performance is smooth and fluid. To minimize the occasional “freezing” that can affect the scheduler in your app, calculations are now executed in multiple threads. This advanced asynchronous mode can be switched off if desired; however, even in synchronous mode the layout calculations are faster than before.

Unfortunately – and here comes the bad news – these changes to the scheduler’s performance envelope have had to be percolated up into the public Scheduler API. And that in turn means some breaking changes, although we have tried to minimize the number and extent of these.

The biggest change is that several classes have been abstracted out as interfaces, and we’ve introduced several others as well. For example. the most frequently used classes, such as Appointment, Resource, AppointmentDependency are now interfaces; and we’ve added the ISchedulerStorage, IAppointmentStorage, IResourceStorage, IAppointmentLabel, IAppointmentStatus interfaces. This dual approach enables us to leave any legacy code intact (pretty much) while implementing new cross-platform features. For example, different AppointmentLabel and AppointmentStatus classes (which expose IAppointmentLabel and IAppointmentStatus interfaces) exist for each platform. However, the AppointmentViewInfo.Status property now returns an IAppointmentStatus object because the AppointmentViewInfo class instances are used for all platforms and in Scheduler Reports.

Having laid the foundations for why we have breaking changes in v15.2, I do have to mention that overall the logic used in the Scheduler API has not changed, nor have most of the method and property names and their signatures. It is all very similar, such that the number and nature of the changes you will have to make in upgrading your app are small and easily made:

  • Appointment: no longer has a constructor since it’s now an interface. To construct an Appointment object use SchedulerStorage.CreateAppointment() instead .
  • Resource: no longer has a constructor since it’s now an interface. To create a Resource object, use the SchedulerStorage.CreateResource method. The static property Empty has been removed, and you should use ResourceEmpty.Resource or ResourceEmpty.Id instead, depending on the context.
  • AppointmentDependency: no longer has a constructor since it’s now an interface. You now use the SchedulerStorage.CreateAppointmentDependency method to create an appointment dependency object.
  • The AppointmentViewInfo.Status property now returns an object that implements the IAppointmentStatus interface instead of an instance of the AppointmentStatusBase class.
  • The Appointment.RecurrenceInfo property now returns an object that implements the IRecurrenceInfo interface.
  • Several properties and methods has been marked as obsolete and will be removed in a future major version. You should be aware that this is going to happen at some point and make plans to rewrite your code to avoid them. You can defer these changes until after the v15.2 major release though.
  • Until v15.2 the Appointment.StatusId and Appointment.LabelId properties were declared to be Int32s, since they were in essence an index value into the label and status collections. From the developer point of view, this choice made it really difficult to bind such labels and statuses to fields in an external database. From v15.2 onwards, the new AppointmentStatus and AppointmentLabel objects have their own Id object property which is no longer related to an index of a collection. These objects are returned by the Appointment.StatusKey and Appointment.LabelKey properties (and, obviously, can now be represented as rows in a table in a database). This should help developers who had to devise various workarounds to deal with the original problem.

Now for the new features!

1. A new feature is a Brush property for the status that enables the developer to define the brush used to visualize and display the appointment status. In fact the label color and status brush properties are platform-specific in order to utilize native brushes and colors for each platform.

2. We have implemented a new default appointment form used by your users to create an edit appointment details. This has been designed to mimic the Microsoft Outlook appointment dialog.

The new scheduler appointment form

3. The Scheduler control now can indicate the current time by drawing a line in the view. In the Day, Work-Week, and Full Week views the horizontal line can go across the entire view, or it can be restricted to the current date.

The new time indicator for the current time

In the Timeline view however, the time indicator is a vertical line drawn down the view.

The new time indicator for the current time

WinRT Live Tile Manager: it’s being deprecated

Two years or so ago, we introduced a component that enabled you to start up and communicate with live tiles in Windows 8 from a WinForms application. So, you know, a non-Windows-RT application talking to a tile on the Start Screen. It was the WinRTLiveTileManager control.

Let’s put it like this. It’s never been that popular. We can tell how well-used one of our controls is by just looking at tickets in the support center. The more people that use a given control, the more tickets we get about how to use it (our documentation needs improving, in other words), the more tickets we get about issues (our code needs fixing, in other words), and the more tickets we get about new features (our imagination needs a jolt, in other words ;) ). Much as we or any other control vendor would like to pretend, we don’t get things right first time. So in general “popular, widely-used control” means more support tickets. The Live Tile Manager has virtually none; the terms “popular” and “widely-used” don’t really apply.

The issue for us is that Windows 8 has been replaced by Windows 10 and the Start Screen has gone away (and if I may make a personal comment here: Yessssss!). The desktop rules again and the weird dichotomy between desktop and Start Screen has gone. Ditto, the need for such a control has also pretty much gone. Corresponding to all this evolution in OS capabilities and UI, the “Live Tiles API”, if I may call it that, has drastically changed.

The upshot of all this is that we have a little-used component, the need for it has pretty much disappeared, and the API has changed. Hence the decision is to not update it for Windows 10 at all and to deprecate it in v15.2. Although it will still be shipped with the install (at least to begin with), it will no longer be installed by default in the toolbox in Visual Studio. It will, in fact, only work with Windows 8:

WinRTLiveTileManager Is For Windows 8 Only

Of course, as with any announcements we make about features in our products, feedback is most welcome. Let us know what you think.

More Posts