Our most recent release included something we’ve been asked about for quite a long time…With v17.2, you can now incorporate our custom file dialogs within your WinForms desktop apps.

You may be asking what’s the big deal and if they are any better than standard dialogs. The reason we implemented them, much like the reason we have implemented many smaller controls like buttons or group boxes, is not necessarily to add functionality, but first of all to make sure your applications look consistent, whatever the theme or skin the application's end-users choose.

As an example, if you were to use a standard Shell dialog in an application with a dark theme enabled, you'd see something like shown in the following image:

With v17.2, you can replace the standard dialog with the DevExpress version thus providing a visually consistent UI:

In addition to the Save File and Open File, we also ship the Folder Browser dialog shown below:

And as you might expect, the API is very easy to use as it closely resembles that of standard dialogs. Refer to WinForms and WPF documentation articles to learn more about these, as well as other DevExpress counterparts for standard UI elements that make up your applications.

I got some questions last week about where to find the webinar video "Object-Relational Mapping for .NET Core with DevExpress XPO" I did as kick-off on our v17.2 release webinar series. Well, the reason it took some time is because we prepared it to be hosted on the Microsoft Channel 9 site.

To show how cross-platform XPO and .NET Core 2 are, I decided to use a Linux Mint environment in the first part, Windows 10 in the second part and Mac OS in the third (Xamarin) part.

I didn't even mention in the webinar that I was running my MS-SQL Server instance in a Docker container on my Asustor NAS Device (which is Linux based), so it was cross-platform all the way!

Webinar outline

After the general introduction on Object Relational Mapping, the coding part took of. I started with a small console application to show the absolute basics of XPO.

Connecting to the datastore

The first step is to connect to a datastore which is done throught the DataLayer. XPO has several difference DataLayer implementations for different kinds of applications.
In the console application, we can use the simple DataLayer and initialize it like this:

   XpoDefault.DataLayer = XpoDefault.GetDataLayer(
      SQLiteConnectionProvider.GetConnectionString("console.db"),
      AutoCreateOption.DatabaseAndSchema);

In the Web API example, there was some more code involved for initializing the DataLayer. Because we're dealing with a multi-threaded web application, we want to initialize a singleton instance of a ThreadSafeDatalayer. Besides that, we also want to setup a database connection pool to make the app as performant as possible:

   string pooledConnectionString = XpoDefault.GetConnectionPoolString(connectionString);
      var dataStore = XpoDefault.GetConnectionProvider(pooledConnectionString,
                            AutoCreateOption.SchemaAlreadyExists);
      var dataLayer = new ThreadSafeDataLayer(dictionary, dataStore); ;
      return dataLayer;

With some extension methods, I'm using the .NET Core dependency injection to create that singleton instance, and I inject a UnitOfWork into any Web API Controller which has a constructor with a parameter of type UnitOfWork:

   public static class CustomXpoExtensions {
      public static IServiceCollection AddXpoPooledDataLayer(this IServiceCollection serviceCollection, string connectionString) {
         return serviceCollection.AddSingleton(XpoHelper.CreatePooledDataLayer(connectionString));
      }
      public static IServiceCollection AddXpoDefaultUnitOfWork(this IServiceCollection serviceCollection) {
         return serviceCollection.AddScoped((sp) => new UnitOfWork());
      }
      public static IServiceCollection AddXpoUnitOfWork(this IServiceCollection serviceCollection) {
         return serviceCollection.AddScoped((sp) => new UnitOfWork(sp.GetService()));
      }
      public static IApplicationBuilder UseXpoDemoData(this IApplicationBuilder app) {
         using(var scope = app.ApplicationServices.GetService().CreateScope()) {
            XpoHelper.CreateDemoData(() => scope.ServiceProvider.GetService());
         }
         return app;
      }
   }

We can use these extension methods in the Startup.cs like this:

   public void ConfigureServices(IServiceCollection services)
   {
      services
         .AddXpoPooledDataLayer(MSSqlConnectionProvider.GetConnectionString("sql-server-ip", "user", "test123", "WebAppDemo"))
         .AddXpoUnitOfWork()
         .AddMvc()
         .AddJsonOptions(options =>
         {
             // use the custom resolver (above)
             options.SerializerSettings.ContractResolver = new XpoContractResolver();
             // don't kill yourself over loop properties (probably not really needed now, I
             // inserted this originally to work around the This property on the XPO types)
             options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
          });
   }

The AddJsonOptions in the above code adds a custom Json serializer to the App to make sure certain fields of our XPO entities are not being serialized to Json. This fields are part of the infrastructure or XPO.

For the Xamarin example, I used again a ThreadSafe Datalayer because a Xamarin app will be multi-threaded as well.

Defining entities

In the examples, I used an Order type together with the OrderItem type. This gave me the opportunity to show how to setup a Master-Detail relation ship as well.

The first thing you see is that I derived my entities from the XPO based type XPObject.

   public class Order : XPObject
   {
      public Order(Session session) : base(session) { }

      //... code omitted
   }
  

The reason for using this base type is that several nice features of XPO will be made available then like "Change Notifications". This behaviour comes in quite handy when doing some caching to get the most out of your application.

Please note that the XPObject requires you to supply a Session (or UnitOfWork) to its constructor. This is necessary to let the infrastructure of XPO dot its thing with the object being instantiated.

In case you have an existing class hierarchy that you want to persist to a database and you don't want to use constructor and Sessions etc. in there, you can also work with plain simple objects (POCO) which is similar as with Entity Framework.

An example of this is the Xamarin demo which works with the POCO objects created by the project template.

    public class Item
    {
        public string Id { get; set; }
        public string Text { get; set; }
        public string Description { get; set; }
    }

    using (var uow = XpoHelper.CreateUnitOfWork())
    {
       item.Id = Guid.NewGuid().ToString();
       // I'm using the Save(..) method which receives the POCO we want to persist
       uow.Save(item);
       uow.CommitChanges();
    }

Another interesting thing is the implementation of properties:

   public class Order : XPObject
   {
      //... code omitted

      public Order(Session session) : base(session) { }
      private DateTime _OrderDate;
      public DateTime OrderDate
      {
         get { return _OrderDate; }
         set { SetPropertyValue("OrderDate", ref _OrderDate, value); }
      }
   }

This SetPropertyValue(..) method is one of the methods made available through the XPObject and deals with the Change Notifications.

Defining relationships between entities is pretty straight forward. In a master-detail relationship, the master entity (Order) has a collection of detail entities (OrderItem), while the detail entity holds a single reference to its master entity like shown below:

   public class Order : XPObject
   {
      public Order(Session session) : base(session) { }

      //... code omitted

      [Association("Order-OrderItems"), Aggregated]
      public XPCollection<OrderItem> OrderItems
      {
         get { return GetCollection<OrderItem>("OrderItems"); }
      }
   }

   public class OrderItem : XPObject
   {
      public OrderItem(Session session) : base(session) { }

      //... code omitted

      private Order _Order;
      [Association("Order-OrderItems")]
      public Order Order
      {
         get { return _Order; }
         set { SetPropertyValue("Order", ref _Order, value); }
      }
   }

Also note the Association and Aggregated attributes. They tell XPO what kind of relation we are trying to setup.

Another powerful feature that comes with XPO is the use of the PersistentAlias attribute. With this you can specify that certain (readonly) fields need to be determined/evaluated by the database system being used.

I used 2 examples in the project, one which calculated the total price per order item, which is Qty * UnitPrice:

    public class OrderItem : XPObject
    {
        //... code omitted

        public int Qty {
           //... code omitted
        }
        public decimal UnitPrice{
           //... code omitted
        }

        [PersistentAlias("Qty * UnitPrice")]
        public decimal Price
        {
            get { return Convert.ToDecimal(EvaluateAlias("Price")); }
        }
    }

The second one is doing an aggregated calculation as part of the Order entity which sums the Alias from the detail set OrderItems:

    public class Order : XPObject
    {

        //... code omitted

        [Association("Order-OrderItems"), Aggregated]
        public XPCollection OrderItems
        {
            get { return GetCollection("OrderItems"); }
        }
        [PersistentAlias("OrderItems.Sum(Price)")]
        public decimal TotalAmount
        {
            get { return Convert.ToDecimal(EvaluateAlias("TotalAmount")); }
        }
    }

Please not that the syntax being used is part of our database agnostic criteria language. More about it can be found here.

Querying the datastore

There are several ways of querying the datastore. In the examples I've used the Linq querying mechanism. This query is initiated through the Session.Query<T>() method:

   using (var uow = new UnitOfWork())
   {
      var orders = from o in uow.Query<Order>()
            where o.OrderDate < DateTime.Now.AddDays(-10)
            orderby o.OrderDate
            select o;

      foreach (var o in orders) {
         Console.WriteLine($"Order #{o.OrderNo} / {o.OrderDate}, client {o.Client}, Total Amount { o.TotalAmount }");
         foreach(var i in o.OrderItems) {
            Console.WriteLine($"   {i.Qty} x {i.Description} ({i.UnitPrice}) = {i.Price}");
         }
      }
   }

XPO also supports another query mechanism by using the CriteriaOperator classes. This are super-powerful and they also allow you to select programmatically. This tends to be a problematic with Linq.
XPO CriteriaOperators allow you to create a very complex filtering clause which will be transformed to the SQL WHERE clause when executed.
I could rewrite the above code fragement like this:

   using (var uow = new UnitOfWork())
   {
      XPCollection<Order> orders = new XPCollection<Order>(uow,
            new BinaryOperator("OrderDate", DateTime.Now.AddDays(-10), BinaryOperatorType.Less),
            new SortProperty("OrderDate", SortingDirection.Ascending));
   }

Or by using the CriteriaOperator.Parse(...) construct:
I could rewrite the above code fragement like this:

   using (var uow = new UnitOfWork())
   {
      XPCollection<Order> orders = new XPCollection<Order>(uow,
            CriteriaOperator.Parse("OrderDate < ?", DateTime.Now.AddDays(-10)),
            new SortProperty("OrderDate", SortingDirection.Ascending));
   }

Do note the '?' which is used as a parameter indicator in the query language.

More on the XPO Criteria Language can be found here.

This Webinar was only short introduction since XPO involves much more. What to think about inheritance, interface support, a whole set of Attributes to decorate your classes and properties with, support for Views and StoredProcedures.

I even didn't mention our Visual Designer which comes with VisualStudio as well as our XPO Profiler tool to analyze which SQL is being fired against the database:

If you want to play around with the samples I did in the webinar, check out my Github repo at: https://github.com/donwibier/DXXPOCore.

Do note that if you clone the repo, you will need to have your personal DevExpress NuGet feed configured like instructed here.

Let me know if you want to know more!

Thanks to great feedback from our users, we've extended the capabilities of Logify so it can better meet the 24/7 application monitoring needs of customers.

If you've not had the opportunity to review its capabilities or evaluate it within your organization, please visit Logify.DevExpress.com and register for your 15-day trial.

New - Removing Sensitive Data from Your Logify Crash Reports

Logify allows you to remove sensitive data stored within your reports. If you've used Logify, you'll know that all request data (form fields, headers, cookies and server variables) are included within the report sent to Logify Alert when a web application crashes. At your discretion, you can remove sensitive HTTP request data from reports whenever necessary.

New - Collect Breadcrumbs

Logify now includes a Breadcrumb feature and is able to collect information on the actions that preceded an app crash event (text input, clicks, network requests and an application state changes).

New - Collect Method Arguments

When analyzing an exception’s call stack, it's often useful to review method arguments that were being executed when an exception occurred. Logify Alert provides two new methods to support this capability: TrackArguments and ResetTrack Arguments

New - Related Issues Support

You can now associate external links to issues/tickets/cards/messages stored within an issue tracker or external app. This will help you link known issues to crash events displayed within a Logify report. 

Additional new features include remote client configuration support, "favorite" report fields, ability to merge reports, and advanced search options.  

As always, we are here to help - if you have any questions about Logify, email us at info@devexpress.com.

It's 2018 and we're delivering another ASP.NET AJAX Control Toolkit release for you that brings several useful bug fixes.

Update Your Version

Please upgrade your ASP.NET AJAX Control Toolkit version to the latest release. You can download our useful installer here:

Or use the Nuget libraries:

ASP.NET AJAX Control Toolkit Nuget packages

Then give us your feedback on GitHub.

Bug Fixes in v18.1.0

All controls

• Item 369 - Error when installing the toolkit v17.1.1 to Visual Studio 2013

Accordion

• Item 360 - Accordion does not fire an ItemCommand event on postback

AjaxFileUpload

• Item 351 - Filename is not encoded on uploading a file with AjaxFileUpload
• Item 364 - Unsupported characters in AjaxFileUpload Error Message
• Item 377 - “XML Parsing error: no root element found” in the Firefox browser’s console after uploading a file using AjaxFileUpload

AutoCompleteExtender

• Item 349 - AutoComplete extender completion list is hidden when CompletionInterval = 0
• Item 385 - AutoCompleteExtender - The “change” event is raised twice in Chrome and FireFox

CalendarExtender

• Item 331 - Calendar widget doesn’t work if invalid value typed into associated text field.

CascadingDropDown

• Item 374 - Child cascading dropdowns do not reset to prompt on parent value change.

ComboBox

• Item 400 - A dropdown ComboBox list is displayed incorrectly when a textbox has the "position: absolute" style

HtmlEditorExtender

• Item 344 - Invalid argument error in HtmlEditorExtender

Rating

• Item 339 - Sys.Extended.Deprecated is undefined in Rating control
• Item 379 - Rating_Changed event fires twice

Try DevExpress ASP.NET

We’d like to thank you for installing the DevExpress Edition of the AJAX Control Toolkit and look forward to your feedback as you begin using it.

When we took over the fabulous ASP.NET AJAX Control Toolkit, our goal was to reach those web developers who want to use great web user interface controls for their web projects and DevExpress ASP.NET provides that and much more.

Try the free DevExpress 30 day trial.

Email: mharry@devexpress.com

Twitter: @mehulharry

2018 is kicking off in Europe with the NDC London conference. DevExpress is proud to be a partner of it.

As always, NDC has a top notch line-up with speakers like Scott Guthrie, Steve Sanderson, Scott Hanselman and about 90 more!

John and I will be available at our booth to show you all the awesome features in our v17.2 release and we'll be handing out some cool goodies.
Make sure to come by and say hi!

See you at NDC!

Another 30 days, another CodeRush release. Download the latest version from the Visual Studio Marketplace. This update contains the following enhancements:

Code Style

• You can now change the default visibility modifier CodeRush uses for generated members.
  
  
  This setting is used by Declaration Providers, Templates and other features that generate new members from scratch.
  
• There's a new Code Style option that lets you set preferences for adding clarifying (but optional) parentheses to your code.
  
  
  
  You can apply these Code Styles with the Code Cleanup feature.
  
  
  

Templates

• Now you can create new templates based on existing templates. Just right-click the template you want to duplicate (in the Templates options page), and select "Create Duplicate". Enter a new template name, and change the expansion or context as needed.
  
  
  
• Now you can easily insert template aliases into your existing templates (allowing templates to insert the contents of the aliased templates into the editor when they expand). Inside the Template Editor, just right-click and choose "Insert Alias...", then specify the name of the template to include. This is useful for sharing the same code expansion between two or more templates.
  
  |
  
• You can now easily include any type in the CodeRush templates system as a Template Name Variable. Just right-click the type anywhere it appears in the Visual Studio editor and choose “Use Type in Templates...”.
  
  
  
  After selecting Use Type in Templates..., CodeRush asks for the shortcut mnemonic to use for the type.
  
  
  
  After adding the new type, it will instantly become available in all type-aware templates, including declaration verbs like "m" (for methods), "p" (for properties), "q" for constants, "t" (for types) and "v" (for variables).
  
• We have improved support for new language features in templates and other context-aware features by adding the [InInterpolatedString] context and adding the language version parameter to the [InVisualBasic(version)] and [InCSharp(version)] contexts.

Try It Today!

Download CodeRush from the Visual Studio Marketplace and let us know what you think. Updates every 30 days. The latest What’s New is always here.

The first Release Candidate (RC) of the DevExtreme React Grid is now available! Many thanks to all users who provided feedback during the beta phase – your help is very much appreciated!

The following paragraphs summarize the changes we made during the beta.

API stabilization and improvements

Improving and stabilizing the APIs was our primary focus during the beta phase. Our goal was to provide a powerful API, consistent throughout the Grid plugins, that would also be easy and intuitive to understand, and convenient to use. We revised all types and identifiers, and we developed rules to ensure naming stability and ease of maintenance for the future.

Improved customization experience

A second goal we had was to improve the Grid customization experience, since we had received lots of feedback and questions on this topic before the beta started. After much detailed investigation and experimentation we finally found a suitable solution. We now provide access to default components used by the Grid plugins, which enormously simplifies customization of invididual components, as well as the implementation of custom behaviors, for example the handling of row or cell click events.

ColumnChooser, reworked

Our initial implementation of the Column Chooser as a separate component seemed too different from the general plugin approach used in the Grid. We came back to this feature and decided to reimplement it, adhering to our plugin architecture. Starting with the RC, the ColumnChooser is not separate anymore from the Grid component – just add it like any other Grid plugin and that’s it!

The visual appearance of the ColumnChooser was also changed. It is now displayed as a drop-down menu in the Grid header.

The Future

We had great success with the feedback we received from our users, which made it possible for us to understand priorities, and to build the most convenient developer experience for the React Grid. Of course we will continue to work in the same way, so: if you feel that something still isn’t as easy as it should be, we are all ears! Please contact us via our GitHub page.

We at DevExpress offer two major libraries that support Microsoft's ASP.NET MVC framework:

1. DevExpress ASP.NET MVC Controls
2. DevExtreme MVC Controls

In this blog post, we'll dive into the two seemingly similar libraries that both offer controls for ASP.NET MVC. We'll look at the differences, similarities, pros, cons, and consequences.

Let's start by looking at server-side versus client-side web development because this choice will be critical in which library will work for you.

Architectural Choices & Consequences

One of the most important concerns for the choice of a web development platform is an architectural one: traditional server-side or client-side UI rendering. It is important because it has many consequences. I recommend reading this section but for those who don't have time, here's a short tldr:

tldr; The choice of server- vs client-rendered UI influences the overall architecture of a software system to such an extent that it is advisable to analyze this concern before making decisions about specific component libraries.

Server-Side

If you use server-rendered UI, this implies you need a server powerful enough to render pages dynamically (per request). Typically this works using template files on the server that describe the pages, with an extension model to insert the dynamic content. Both frameworks use this approach with ASP.NET WebForms using ASPX pages and ASP.NET MVC using Razor files as templates.

While the component models are different between WebForms and MVC, they are both rendered on the server-side .NET environment. This means that the .NET-based data access methods can be used, business logic written in C#, and state kept on the server-side. Even dynamic browser- or user-specific rendering may be performed on the server, perhaps depending on the user locale or permissions queried from a security system.

This model empowers programmers who feel at home in the server environment. However, it can be expensive with ASP.NET WebForms because of the numerous server round trips required for rendering purposes. It also makes it almost impossible to deploy the resulting web application in environments where a server might not be available, such as Electron-based desktop apps or Cordova-based mobile apps. Great care is required to prevent scalability issues because server resources are precious. Also, it's not always easy to add infrastructure, for instance, when the server-side state management has not been structured properly.

There is also a gap to be bridged with this model: for instance it might be required to write certain pieces of code twice, in C# and JavaScript, like those required to perform data validation tasks both for immediate user feedback on the client side and for server-side business logic purposes.

However, if you're building a public facing web-site, server-side rendering is great for SEO (Search Engine Optimization). Because the HTML content is generated on the server, search engines like Google can crawl, index, and cache it. Client-side rendering cannot easily do this without additional work.

Client-Side

With client-rendered UI, a server is not strictly necessary. HTML and JavaScript content finds its way onto the client somehow -- it can be downloaded as static content from a server, but it can also be deployed as an installation package for desktop or mobile targets.

Because the HTML and rendering of those UI elements will now be handled by the client browser, your client-side app mostly needs the data from the server. Typically, you'll need to create web services to provide this data. ASP.NET MVC WebApi may be used to implement such services, which again gives the developer the chance to use .NET-based data access mechanisms, but additional protocols are required, for instance, to query data dynamically from services, and to transfer it back to the client.

Components used by the client to render complex UI are written in JavaScript (or a language that compiles to JavaScript, like TypeScript), and developers usually choose application-level frameworks like Angular or React that help them structure the client-side application, but also require integration with component libraries. This model is reminiscent of simple client/server applications, only using web standard protocols for service communication and data access. It is possible to create full-stack JavaScript-based application systems if the services are written in JavaScript (probably for Node.js), and due to the inherent stateless nature of the services it is usually easy to scale servers as required. Generally, the server-side infrastructure requirements are less complex with this architecture, so that cloud deployments are easy and enable automatic scaling setups.

Client-rendered UI is the architectural model of choice for most modern web/mobile applications and a growing number of desktop ones, including Office 365, Skype, and Microsoft Visual Studio Code. The best recommendation to make this decision is to weigh the pros and cons carefully as they apply to your plans, the expertise of developers on your team, your customer base, and other factors.

This brings us to the major difference between our two MVC set of controls. While both are server-side ASP.NET MVC controls, the DevExtreme MVC Controls will render client-side UI because of they wrap client-side DevExtreme JavaScript controls in ASP.NET MVC controls. On the other hand, the DevExpress ASP.NET MVC controls will render server-side HTML and then deliver this to the client.

Let's now take a look at how these two libraries got started to understand our motivations for creating them.

History

1. DevExpress ASP.NET MVC Controls

In April 2009, Microsoft released ASP.NET MVC and many developers quickly became interested in this interesting new web framework. Many of our customers requested that we provide UI controls for ASP.NET MVC.

At the time, our ASP.NET WebForms library provided solid, stable, and feature-rich controls. So we made the decision to take the API, features, and rendering of our ASP.NET WebForms controls and provide them as native MVC controls. This approach had the benefit of saving time and delivering you a solid set of controls with plenty of features.

In 2010, we introduced the DevExpress ASP.NET MVC Controls as a beta with only five controls. Then, for the next seven years, with each release we continued to grow the controls, features, and performance. Today, the DevExpress MVC set of controls is solid and has over 65+ controls.

Around the same time, JavaScript was also gaining popularity with web developers...

2. DevExtreme MVC Controls

Since the late 2000s, JavaScript's popularity has continued to rise. And serveral years ago, web development shifted decidedly towards client-side JavaScript-based technologies like jQuery, Node.js, Angular, Backbone, React, etc. With good reason because the client-side development model provides benefits. Many of our existing web customers asked us to provide JavaScript controls that rendered exclusively on the client-side.

So in 2011, we tasked an independent group of our developers to build a fully client-side set of JavaScript controls that are similar in features to our server-side controls. After a year of development, the DevExtreme library was born in 2012. We've continued to develop this client-side library since then to provide more controls, features, stability, and support for other client-side frameworks. Then, around 2014, some of our web customers expressed a need for a set of MVC controls that used the client-rendering approach. So we decided to wrap the client-side DevExtreme JavaScript controls as native server-side MVC controls.

In June 2016, the DevExtreme MVC Controls were then introduced as a Community Technology Preview (CTP). Now, after several releases where the team has worked hard to improve the DevExtreme MVC Controls, they provide over 65+ controls, features, and great integration with ASP.NET MVC (and ASP.NET Core).

What's right for you?

While the architectural considerations should help push most projects in their preferred direction, it is also possible to compare our libraries on the basis of specific technical merits. The following overview may not be exhaustive - please feel free to ask about topics you feel are missing and we will extend the post.

Recently, we've gotten questions from developers asking:

• What do you recommend for my scenario?
• What are the main differences between the two products?

To help you decide, please read the following four sections that compare both of these libraries strengths and weakness:

1. What's Included & Missing

On first glance, it would appear that both libraries have about 65+ set of MVC controls and they provide the key controls like Data Grid, Charts, Editors, Navigation, etc. However, not all controls are available in both libraries and this can be a key deciding factor. For example, if you need Spreadsheet, Ribbon, or RichEdit controls then those will only be available in the DevExpress ASP.NET MVC Controls Suite.

Here's a breakdown of which controls are available in each library:

	DevExpress ASP.NET MVC Controls (Server-Side)	DevExtreme MVC Controls (Client-Side)
Grid
PivotGrid
TreeList, TreeView
Scheduler
Navigation Controls
Editor Controls
Charts & Gauges
Forms
Reporting Suite
RichEdit
Spreadsheet
HTML Editor
Ribbon
FileManager
CardView
Vertical Grid
Docking Suite
Spell Checker
ActionSheet, ScrollView, SlideOut
Bar, Circular, Linear Gauge
Map, TreeMap, VectorMap
RangeSelector
Bullet
Sparkline
FilterBuilder	Integrated into other controls
Box, ResponsiveBox
Toast

2. Rendering Pros/Cons

The DevExpress ASP.NET MVC Controls provide server-side rendering.

• Pros: Solid with (many more) years of releases. More powerful controls available.
• Cons: Windows IIS servers hosting. Callbacks, however, data is submitted via native forms, MVC Forms, or MVC Ajax Forms and can be accessed on a controller's action.

The DevExtreme MVC Controls provide client-side rendering.

• Pros: They emit semantic markup that is rendered by the client browser. User interaction is faster. Tighter integration with ASP.NET MVC framework.
• Cons: For interactivity and run-time customization, you'll have to deal with the core JavaScript widgets.

A. Performance

The DevExtreme MVC controls have some minor advantages in terms of performance due to their client-side rendering. Mainly, the user interaction will feel more responsive.

For example, when grouping rows in the DevExtreme MVC Data Grid, you'll find that it will only retrieve the data for the rows that it needs to update to show the grouped layout. In the browser tools image below, we can see that DevExtreme MVC Grid is only getting JSON for the data rows from the server and the Grid will render and update the UI accordingly:

However, the DevExpress ASP.NET MVC GridView will do a partial page update. Meaning that it will retrieve the HTML for the new grouping layout from the server and then deliver those to the client and render them in place. A partial page update looks like the following when sent across the request/response chain:

Callbacks require additional server effort to re-rendering these HTML snippets for (potentially) large numbers of clients and therefore increase the data volume. However, on a fast connection, you'll likely not notice a major difference in speed.

B. Semantic HTML Render

As mentioned, the DevExtreme MVC controls provide semantic markup when rendered (click image for larger version):

The larger DevExpress ASP.NET MVC controls like the Grid uses a Table based layout for rendering. However, the navigation controls (pager, menu, navbar, etc) have semantic rendering that are based on lists, divs, etc.:

Both of these rendering approaches are compliant with HTML5 standards.

3. Data Binding

The DevExpress ASP.NET MVC Extensions are server-side controls and therefore, they can easily bind to any server-side .NET data layer. However, client-side binding is not supported in these server-side controls.

The DevExtreme MVC Controls provide various ways of binding data-aware controls on the client side. These controls also provide a server-side data layer that allows you to bind on server-side as well. This mechanism doesn't change the architectural considerations about data binding, it merely provides web services for data access automatically, based on existing server-side data sources.

4. .NET Core support

Both libraries support the .NET Framework 4+ and the same set of browsers.

However, the DevExtreme MVC Controls also support ASP.NET Core 1.0.1 and later (including 1.1, 2.0+), while the DevExpress ASP.NET MVC controls do not.

While not part of this comparison, the new DevExpress ASP.NET Bootstrap Core controls exclusively support the ASP.NET Core framework.

Use Together

Keep in mind that if you choose classic full framework ASP.NET MVC (not ASP.NET Core) then you could use both of our MVC controls together to complement each other. For example, you can use the DevExpress ASP.NET MVC Spreadsheet and DevExtreme MVC Grid in the same ASP.NET MVC project.

Both of these MVC libraries are also offered in the DevExpress ASP.NET Subscription too!

The Choice is Yours

To recap, both of MVC control suites offer you many great UI controls and they can also be used together.

However, if you need to choose between them then I'll offer my observations as a the Web Program Manager who's interacted with many developers:

• Devs who prefer client-side rendering typically choose the DevExtreme MVC Controls
• Fans of C# and server-side rendering typically choose the DevExpress ASP.NET MVC Controls

Hopefully, the information above will help you choose. If not, then please leave a comment below on how I can help.

Email: mharry@devexpress.com

Twitter: @mehulharry

DevExtreme provides an easy way to localize UI widgets. It uses the localization module to load translations of specific captions/messages such as 'Back', 'Cancel', 'Select', 'Loading', 'Search', and others to the corresponding languages. The DevExtreme locale extensions are provided by separate ready-to-use predefined dictionaries with our installation. These dictionaries include all the captions, titles, and messages that are used in DevExtreme UI widgets.

With the v17.2.5 minor release, DevExtreme now provides you the first community localizations for Spanish (es) and Brazilian Portuguese (pt-BR). This now make six languages that DevExtreme Localization provides messages for:

1. English (en)
2. German (de)
3. Japanese (ja)
4. Russian (ru)
5. Spanish (es)
6. Brazilian Portugues (pt-BR)

To localize dates, numbers, and currencies, you can use third-party libraries - Intl or Globalize. In addition DevExtreme allows you use Globalize library to localize messages. Learn more about Localization by reading this helpful blog post.

GitHub Contribution

In April 2017, we moved the DevExtreme library to GitHub which provides many benefits like access to pre-releases and sprints. However, it also means that our code is available to view and contribute to!

In fact, these two new translations were provided by one GitHub community member. I'd like to thank GitHub user: @pedrofurtado for these contributions. I'd also like to thank users perrich, Laupe, and jdvjdv82 for their contributions too. Their contributions of French and Czech localizations are under review now and we'd like your help with these too.

Help Us Translate

We need your help to translate more languages.

Specifically, we have two incomplete translations: French and Czech.

Here's how to help:

1. Read our Contribution Guide (https://github.com/DevExpress/DevExtreme/blob/17_2/CONTRIBUTING.md) and Section 5 of the License Agreement (https://github.com/DevExpress/DevExtreme/blob/17_2/LICENSE.md#5-submission-of-contributions)
2. Fork the DevExtreme repository.
3. Commit your translation to /js/localization/messages/ folder in your fork. We recommend you use the latest development branch (currently 18.1).
4. Create a pull request - Our engineers will check it, merge it and cherry-pick to previous versions.

We'll include these two new localizations in a future minor DevExtreme release (v17.1.10) too.

Are you using DevExtreme with a different localization?

Drop me a line below. Or better yet, post a screenshot link of your DevExtreme enabled website. Thanks!

Email: mharry@devexpress.com

Twitter: @mehulharry

It’s literally taken us years to do it, but Bootstrap 4 has finally arrived! - Bootstrap Blog

Last week, the Bootstrap team officially released Bootstrap 4 and I'm happy to say that the excellent DevExpress Bootstrap controls for ASP.NET WebForms and ASP.NET Core support this latest Bootstrap release.

I recommend reading the blog post to see what's new and test the new examples. There's also a helpful migrating to v4 guide.

Download Latest Version

The v17.2.5 minor release is now available and it features updated the project templates for our Bootstrap Controls. Download and update your installations.

DevExtreme Support

The DevExtreme team is currently working on updating the DevExtreme themes and the ThemeBuilder tool to support Bootstrap 4. Therefore, you'll see official DevExtreme support for Bootstrap 4 in the upcoming v18.1 major release.

The DevExtreme Reactive controls will have support for Bootstrap 4 in the coming weeks. You can track this pull request for full updates.

Classic ASP.NET/MVC

The classic DevExpress ASP.NET controls that support ASP.NET WebForms and MVC can be used with Bootstrap (up to version 3). And the team is looking into supporting Bootstrap v4 in a future release. However, as I've written before, when using the Bootstrap framework, it's better to use the DevExpress Bootstrap Controls which were specifically written for the Bootstrap framework.

Email: mharry@devexpress.com

Twitter: @mehulharry

Check out these great videos that will help you get started using the DevExtreme MVC Controls:

DevExtreme ASP.NET MVC Tutorials - YouTube Playlist

The videos are all about five minutes or less so that you can get started quickly using DevExtreme, DevExtreme MVC Grid, and the DevExtreme MVC Charts:

Subscribe

Be sure to also subscribe to the DevExpress YouTube Channel where we post lots of great technical content:

Email: mharry@devexpress.com

Twitter: @mehulharry

In this article, I’m sharing two HTML email templates that I recently overhauled. I’ll break them down into snippets that show how to construct various types of layouts, correctly add images, and format text, lists, code or calls-to-action. I’ll also share some generic advice on HTML email code along the way.

Feel free to download these email templates and reuse them as required.

Transactional Template	Newsletter Template
View Online / Download Code	View Online / Download Code

Table of Contents

• How I Created This Guide
• A Few Words on Responsive Layout
• Top-Level Layout: Limited-Width Centered Content
• Content Layout: Paragraphs or Tables
  • Control Text and Image Layout with Paragraphs
  • Add Backgrounds and Borders Using Tables
  • No-Graphics Buttons
• Side-by-side Layouts
  • Side-by-side Images
  • Side-by-side Text and Image
  • Side-by-side Content Blocks: Building a Multi-column Layout
• White Space Between Elements
• Text
  • Character and Paragraph Formatting
  • Lists
  • Source Code and Application Logs
  • Line Breaks in Responsive Layouts
  • Removing Automatically Added Links
  • Horizontal Lines
• Images
  • Basics: Using One Double-sized Image
  • Responsive Full-width Images
  • Hyperlinked Images
• Styles: Inline or CSS Classes
• Preheader: Message Preview Text
• Final Words

How I Created This Guide (Disclaimers)

Coding HTML email is not my full-time job, but I need to deal with it from time to time. I have enough experience to know that HTML email will never render correctly on my first try, and I can rarely anticipate all possible problems. Something will appear broken in an Outlook viewer, or won’t adapt in mobile apps, or won’t be styled correctly in an online client. This is when I search the web for help.

I know that I am not alone. StackOverflow is filled with Q&A on how to transform regular HTML snippets into email-friendly code. There are many great in-depth articles on the subject. The solutions they give are life-savers: I grab the snippets and paste them into my code, realizing it would otherwise take me hours or even days to figure it out.

When you construct HTML this way - and I don't see any other option - the code tends to get out of hand. The fixes seem somewhat illogical to me, so I don't scrutinize and test every little thing when embedding into my code. The HTML may grow with unnecessary tags and attributes, added just in case, as insurance. And when the time came to overhaul the email, the code seemed unmanageable: I didn’t know which parts to discard and which parts to keep.

What does this code do? Did I put it here to fix a specific part, or did I simply copy it from somewhere else? Do I need the entire snippet or only a part of it? Is it possible that online clients that initially caused the problem have been updated and no longer require the code?

With those questions in mind, I knew I had to re-test everything. For every structural element I compared the way it was implemented with the way it could be implemented on a regular web page, and then stripped down various attributes or tags to achieve the minimum code sufficient to render well on all clients. In the end, I'm satisfied with the results, but also feel like I need to add a few disclaimers:

• The snippets and practices in this article should help you get started building emails similar to those displayed above. This limits the scope of this guide. I'm sure that after reading this you'll be well-equipped to continue researching on your own.
• Some examples will seem obvious. I'm showing them, because there are other, probably equally obvious options that DO NOT work.
• I've made reasonable effort to try and find compact code that produces the most responsive results. Once I find a version that's clean and works well across email clients, I will stop trying.
• I'm using Litmus.com to test email, in addition to sending test messages to myself and reviewing the output in Outlook, Gmail and iOS Mail.

A Few Words on Responsive Layout

When you're constantly dealing with email clients that have limited support for code you normally use for web pages, there's no way around contemplating the basics. How do you write code that is rendered well by any client on any device? What unites all HTML rendering platforms? What is the "ultimate responsive code"?

The Ultimate Responsive Code

Consider a tag like <p>. If your web page or email is but a few paragraphs of text, then any browser or email app will render it correctly on any device. The words will flow one after another and wrap to a new line when necessary. The same principle holds true for higher level content: any layout that naturally flows by itself will provide the most consistent results regardless of the end-user's software or hardware.

Of course, another reason your paragraphs will work is that <p> is a very basic tag: code that simple will render well anywhere. To support the claim that simpler code is better code, let me give you a few examples from my experience.

Example #1 - Failed Tricks with Images

You write code that conditionally loads an image of a certain size depending the screen resolution. You can also load vector images, if supported, or raster otherwise. You will discover, however, that tricks like this result in double images in forwarded emails. The code that seems to work best across all clients requires only one image tag and no conditional loading.

Example #2 - Failed Tricks with Visibility

My testing shows that you can't fully rely on media queries to work on any mobile client. So what should you do to remove unnecessary content on small screens? My advice is to accept that sometimes content cannot be conditionally hidden, and avoid relying on dynamic visibility. Instead, come up with a layout that looks good enough at any resolution with all elements displayed. You can keep the media queries as well and let them work where they work. Should they fail, your customers will still see decent looking email.

The Bottom Line

These are the rules to live by when dealing with HTML email:

• Before you start, or as soon as you encounter problems, consider ways to alter the design so that it naturally flows on screens of any size.
• Keep the code simple.
• Add fancy formatting as options, but always assume that they will not take effect in certain clients.

Top-Level Layout: Limited-Width Centered Content

In most cases, you'll want limited-width content on a desktop. On mobile devices, the layout should adapt to the small screen size.

The code below is all you need for a responsive layout. It might seem a bit complicated with the conditional table in the middle, but it's actually only two containers - one for full-width background and another for centered, limited-width content. Note that the code uses plain HTML tags and avoids media queries, which have limited support across email clients.

<!-- enable window-wide background filling --><!-- and add padding on mobile screens --><table cellspacing="0"
      style="background-color: #ff7200; width: 100%;"><tr><td align="center" style="padding: 0 20px 0 20px;"><!-- required in Outlook, since it doesn't support 'max-width' --><!--[if (gte mso 9)|(IE)]><table cellspacing="0" style="width:600px;"><tr><td><![endif]--><!-- limit width to 600px on desktop and center --><!-- set width to 100% for mobile screens --><table cellspacing="0"
              style="width: 100%; max-width: 600px; margin: 0 auto 0 auto;"><tr><td><!-- add content and close out all tags --></td></tr></table><!--[if (gte mso 9)|(IE)]></td></tr></table><![endif]--></td></tr></table>

The code above can wrap a single section in an email or the entire content, depending on email design.

• Our Transactional email (on the left) requires full-width colored stripes in header and footer sections. You'll need to repeat the nested tables for each stripe, so that a different background color can be applied.
• Our Newsletter email (on the right) uses the same white background beyond the centered content. For these templates, you'll only need to use nested tables once to wrap the entire email content.

Content Layout: Paragraphs or Tables

I assume that you're done with the top-level layout described in the preceding section and are now populating your email with content blocks. Since I'm aiming for a natural flow/responsive layout, I have two basic strategies at my disposal:

• Stack blocks vertically and assume they will resize with the container.
• Place blocks side by side and assume that they will wrap when needed.

This section deals with vertically stacked content blocks. A discussion of side-by-side layout follows.

Control Text and Image Layout with Paragraphs

Many articles on HTML email code suggest tables for bulletproof layout because Outlook has poor support for padding and margin attributes in other tags. I used to take this advice a bit too far. At one time, my email templates had a table row for each paragraph and for each white space between paragraphs. But once I started to question that, I discovered that all clients will respect margin and alignment settings in a paragraph tag. Ultimately, this is what many designs boil down to - text and images, vertically spaced and horizontally aligned.

Here's the snippet from our Transactional email header. In addition to margin, note how line-height can help with layout management.

<p style="margin: 20px 0 35px 0; text-align: right;"><a href="https://www.devexpress.com/" ...><img src="Logo.png" ... /></a></p><p style="margin: 0 0 0 0; font-size: 40px; line-height: 50px; ...">
    Maintenance Update</p><p style="margin: 0 0 35px 0; font-size: 36px; line-height: 40px; ...">
    v17.2.5 is Now Available</p>

To ensure that line-height behaves predictably in Outlook, you'll need to set the following attribute.

p {
    mso-line-height-rule: exactly;
}

Add Backgrounds and Borders Using Tables

As you'll see in our Newsletter template below, there are a variety elements - such as a header section, sidebar, a button, or a text block you need to highlight - that require custom background color, padding, and borders. All these blocks need to be rendered using a <table>, because padding doesn't seem to work with anything else in Outlook.

Here's the basic code for the header with a logo. It's boilerplate code, with the only unexpected thing being the min-width attribute. Without it, the block doesn't stretch all the way on Android 5.1 and Android 6.0 clients.

<table cellspacing="0"
    style="width: 100%; min-width: 100%; background-color: #4a4a4a;"><tr><td style="padding: 8px 0 10px 20px;"><!-- add an image here --></td></tr></table>

Remember, the <table> is only required to style the block and enable paddings for the content. Within the table cell, you can build your layout using <p> tags with margins, as described in the preceding section.

No-Graphics Buttons

I avoid using graphics for my "call to action" elements, i.e. buttons, because an image might not be rendered by an email client unless the recipient explicitly selects "Download Pictures". So I end up emulating the button, constructing it from text with custom background color, padding and, possibly a border. This all fits into what I just described in the previous section, so once again I use a <table>. In fact, in my Newsletter template, I add a second row to emulate a shadow. Here's how it looks:

<div style="text-align: center; margin: 0 0 45px 0; padding: 0;"><table cellpadding="0" cellspacing="0" style="margin: 0 auto 0 auto;"><tr><td style="text-align: center; background-color: #F78119;
            padding: 5px 20px 7px 20px;"><a href="https://www.devexpress.com/..."
                style="color: white; text-decoration: none;
                font-size: 24px; line-height: 36px;">
                    Register for the Beta</a></td></tr><!-- a row that emulates shadow --><tr><td style="padding: 0; height: 4px; line-height: 4px;
            font-size: 4px; background-color: #d5d5d5;">&nbsp;</td></tr></table></div>

You can use CSS3 attributes to apply rounded corners, shadows and other effects. As I mention in the introduction, email clients provide sporadic support for this, so you need to keep in mind that certain users will see a stripped down version: a simple colored rectangle with text. Here are my findings:

• Thunderbird, email clients on Mac, and most mobile clients will display both rounded corners and shadows.
• Most online email clients display rounded corners only.
• Outlook on a desktop will ignore both attributes.

<div style="text-align: center; margin: 0 0 45px 0; padding: 0;"><table cellpadding="0" cellspacing="0" style="margin: 0 auto 0 auto; "><tr><td style="background-color: #F78119; border-radius: 4px;
                box-shadow: 0px 0px 10px gray;
                padding: 10px 30px 10px 30px; text-align: center;"><a href="https://www.devexpress.com/..."
                   style="text-decoration: none; font-weight: bold;
                   color: white; font-size: 16px; line-height: 24px; ">
                    REGISTER FOR THE BETA</a></td></tr></table></div>

Side-by-side Layouts

When you think about putting two elements on the same level horizontally, especially in an email, you can automatically assume that table columns are your best bet. I, however, am aiming to build a responsive layout, so a <table> tag is off the table. Once again, I want blocks to "flow", so I simply place elements one after another, so that they appear next to each other if space permits, or wrap and stack vertically on smaller screens. This basic rule applies to all element types discussed below: images, images with text, and larger content blocks.

Side-by-side Images

In this section, I'll show you the code for the footer section that displays platform icons.

In a sense, the code below goes against what I've been saying so far: I'm using a <div> instead of a <table> to format this block with a custom background color and padding. I'll explain why it works right after the snippet.

<div
style="text-align: center; padding: 0 20px 0 20px; background-color: #4a4a4a;"><a href="#" style="text-decoration: none;"><img src="win.png" width="57" height="47"
            alt="WinForms" style="border: none;" /></a><a href="#" ...><img src="asp.png" width="55" height="47" ... /></a><a href="#" ...><img src="mvc.png" width="58" height="47" ... /></a><span style="white-space: nowrap;"><a href="#" ...><img src="wpf.png" width="60" height="47" ... /></a><a href="#" ...><img src="win10.png" width="45" height="47" ... /></a><a href="#" ...><img src="html.png" width="40" height="47" ... /></a><a href="#" ...><img src="vcl.png" width="51" height="47" ... /></a></span></div>

Here's the explanation:

• The <div> works because: (a) the background-color attribute is supported everywhere, (b) PNG images have transparent backgrounds that add padding vertically and between images, and (c) side padding is only needed on mobile, where <div> is fully supported.
• The code is formatted to avoid white space between tags. This seems to be the simplest way to get rid of spaces between images.
• The <span> that surrounds the last four images prevents a single image from wrapping to the second line. (Truth be told, I'm also using media queries to hide this entire block on mobile, but, as discussed above, this sometimes does not work and I need a decent-looking fallback version.)
• border: none; and text-decoration: none; fight the side effects of putting an image into a link.

Side-by-side Text and Image

Our Transactional email's call to action is designed as follows:

I'm showing this example to once again stress the point that these layouts don't require any extraordinary code. Putting text next to an image in a paragraph makes it work across clients. A table is required only if the text is lengthy enough to wrap on smaller screens.

<p style="margin: 0 0 20px 0; text-align: right; vertical-align: middle;
    font-weight: bold; font-size: 14px;"><a href="#" style="color: #1099f9;">Download Manager</a><a href="#" style="text-decoration: none;"><img src="arrow.png" width="44" height="44" alt="Learn More"
                style="border: none; vertical-align: middle;" /></a></p>

Side-by-side Content Blocks: Building a Multi-column Layout

In this section, I show the code for our newsletter's sidebar, which is displayed to the right of the content on a desktop, or on top of it when viewed on a mobile device.

Following the main theme of this section, I'm simply putting elements one after another, letting them flow and wrap as necessary. In this case, the elements are <table> tags with nested content. I also wrap the tables into a container in order to keep them together and prevent their interaction with preceding and subsequent content.

<table cellspacing="0" style="width: 100%;"><tr><td><table cellspacing="0" align="right" class="column"
            style="background-color: #f2f2f2; width: 220px; margin: 20px 0 0 0;"><tr><td style="padding: 20px;"><p style="...">
                            UPCOMING WEBINARS</p><!-- more content --></td></tr></table><table cellspacing="0" align="left" class="column"
            style="width: 360px; margin: 20px 0 0 0;"><tr><td><p style="...">
                            iOS and Android Charts</p><!-- more content --></td></tr></table></td></tr></table>

A few things to note:

• Inner tables explicitly specify width and align attributes. This is key to making the layout flow.
• The sidebar table goes first within the code, and that's why it renders on the top (before) on small screens. But since it sets align="right", it's rendered to the right (after) on a desktop.
• The class="column" part references a media query style that sets the table width to 100% on small screens. See the CSS below.

@media screen and (max-width: 640px) {
    .column {
        width: 100% !important;
    }
}

You can easily extend this example to achieve a multi-column content layout. I tried a three-column layout where all tables set align="left".

White Space Between Elements

Previous sections describe how you can choose the tags that let you build various layout configurations. This part lists the best practices of adding white space between those elements.

Everything I want to talk about can be illustrated using a single example from the Newsletter template - the part with the logo and the two-column layout under it:

First of all, each individual "column" should have white space added on top. That white space will separate content blocks from each other when they stack vertically on mobile screens. This technique allows you to build a responsive email while avoiding dynamic layout changes implemented using media queries or other means.

Now consider the left column. It contains text on white background, so I can apply margin-top to my first <p>. I simply pad column content without actually adding space between the tables, but the white background lets me get away with it.

<table ... ><tr><td><p style="margin: 20px 0 0 0; ... ">
                iOS and Android Charts</p>

The right column has custom background color, so the same trick will not work. In this case, I create separation by adding an extra table cell with white background.

<table ... ><tr><td style="font-size: 20px; line-height: 20px;"> </td></tr>

You can simplify that code and apply margin directly to a <table>, thus eliminating the need for an extra table cell. Note though, that depending on table content, this may not work in Outlook 2010 and earlier versions.

Text

Text and Paragraph Formatting

As I explained above, I usually put text into <p> tags with margin attributes that control vertical spacing. An exception to the rule is when a table cell contains a single block of text, in which case I put the text directly into a <td>. Regardless of which tag contains the text - <p> or <td> - the same tag defines text formatting attributes, which include the following. (I make a case for inline versus centralized styles later in the article.)

• font-family
• font-size
• line-height
• color

Here's an example from the Newsletter template:

<p
style="color: #4a4a4a; font-size: 32px; line-height: 36px; margin: 0;">
    iOS and Android Charts</p><p
style="color: #F56914; font-size: 24px; line-height: 30px; margin: 0 0 20px 0; ">
    Beta Version Available Now</p><p
style="font-size: 14px; line-height: 21px; margin: 0 0 10px 0;">
    Hello {{FirstName}}</p><p
style="font-size: 14px; line-height: 21px; margin: 0 0 10px 0;">
    Last week, ...</p>

I considered <h1>...<h6> tags for the headers, which will probably work, but decided on a neutral <p> to minimize the possibility that an online email client introduces conflicting styles.

And once again, I need to mention a required fix for line-height. Without it, Outlook will treat your values as "at least this much", giving itself the freedom to increase the height you specified.

p {
    mso-line-height-rule: exactly;
}

Lists

Lists built with <ul> / <li> tags render a bit inconsistently across different clients. The difference is mainly in list margins and the indent between bullets and text. To minimize the discrepancies, I use the following CSS trick I found online.

<!--[if gte mso 9]><style>
    li {
        text-indent: -1em; /* Normalise space between bullets and text */
    }</style><![endif]-->

I also want to enforce is strict vertical spacing between items, which is why I explicitly apply margin and line-height in the code below.

<ul style="margin: 0 0 0 30px; padding: 0; font-size: 14px; color: #404040;"><li style="margin: 0; line-height: 21px;" >
        VCL Subscription</li><li style="margin: 0; line-height: 21px; ">
        ExpressGridPack</li><li style="margin: 0; line-height: 21px; ">
        ExpressQuantumPack</li><li style="margin: 0; line-height: 21px; ">
        ExpressNavigationPack</li></ul>

This may seem a bit much for a simple bullet list. And if your list contains short single-line items such as in the above code, you may want to consider a simple paragraph with line breaks inside.

<p
style="margin: 0 0 20px 0; color: #404040; font-size: 14px; line-height: 21px;">
    - VCL Subscription <br />
    - ExpressGridPack <br />
    - ExpressQuantumPack <br />
    - ExpressNavigationPack</p>

Source Code and Application Logs

For source code and application logs, it might actually be important to keep line breaks in their initial positions. Technically speaking, you may want to wrap that content into a <pre>, which goes against the responsive model, in which text freely flows to the next line. Worse yet, code or application logs can be auto-generated, which is the case in our Logify product. In this scenario there is no option to manually place the required line breaks and test in all possible clients - from the smallest phone to a desktop. I needed to find a way to let the code take care of itself.

In the end, I came up with the following look. I let the code wrap and use horizontal and vertical offsets so that readers can tell where line breaks were originally intended. (It may not look exactly like this on all clients. You'll see minor discrepancies, but the layout is never broken.)

There's essentially no away around wrapping each line into a paragraph to achieve this look.

...<p class="logs">System.Windows.Forms.Control.CreateControl()</p><p class="logs">System.Windows.Forms.Control.WmShowWindow(Message& m)</p><p class="logs">System.Windows.Forms.Control.WndProc(Message& m)</p><p class="logs">System.Windows.Forms.ScrollableControl.WndProc(Message& m)</p>
...

And here's the referenced CSS class:

.logs {
    white-space: pre-wrap;
    word-break: break-all;
    text-indent: -10px;
    margin: 0 0 6px 10px;
    padding: 0;
    font-family: Courier New, Courier, monospace;
    font-size: 12px;
    line-height: 15px;
}

Our R&D team asked if I could find a way to wrap the entire code in a single tag. That's certainly doable, but with the following restrictions:

• In some email clients, mostly online, code does not wrap, and instead overflows the container. This does not break the rest of your email.
• In other clients, code wraps. Automatically added and intended line breaks look exactly the same.

Here's that single-tag HTML wrapper for code or logs:

<pre style="word-break: break-all; font-size: 12px; line-height: 15px;">
...
DevExpress.DashboardWin.DashboardDesigner.OnLoad(EventArgs e)
System.Windows.Forms.UserControl.OnCreateControl()
System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
System.Windows.Forms.Control.CreateControl()
...</pre>

Line Breaks in Responsive Layouts

You usually want to keep headings and call-to-action links on a single line. If they do wrap, you never want the last word to be on the second line. The following image shows you two versions: the ugly and the fixed.

You might be tempted to address these issues with a <br> - a manual line break. That line break will appear in your desktop version as well and you don't want that. My usual trick is similar to what I showed for images earlier in the article. I force the last few elements - words - to stick together, only this time I don't use a <span>. Instead, I glue words to each other with non-breaking spaces ( ) or non-breaking hyphens (‑), so if anything wraps to a new line, it's never a single word.

<p style="...">
    Aug 15, 2017 <br/><a href="#" style="color: #1c5fb2;"><!-- adding &nbsp; to keep last two words together -->
        Get Started with DevExtreme React Grid - Part&nbsp;1</a></p>

Removing Automatically Added Links

Email clients now automatically recognize locations, URLs, phone numbers, or dates and make that information actionable: you can lookup directions, start a call, visit a webpage or schedule an event. You can get rid of these links by using a zero-width non-joining space, a ‌‌ entity. I use it, for example, to stop the words "ASP.NET" or "VB.NET "from being hyperlinked to websites.

<p style="..."><!-- using &zwnj; to avoid automatic links -->
    ... for those favoring C# and VB.&zwnj;NET.</p>

Horizontal Lines

I ended up using an empty <p> with a top or bottom border applied. Here's a sample from our Transactional template:

<p
style="border-top: #d9d9d9 solid 1px; margin: 0 0 40px 0; height: 1px; line-height: 1px;">&nbsp;</p>

I did try the <hr> tag in order to keep things semantically correct. Although you can normally use border settings to change the separator's appearance, certain email clients ignore these adjustments on an <hr>, which forced me to switch to a <p> tag instead.

Images

Provide One Double-sized Image

Whenever possible, I use "double-sized" images in my email. If I need a 100x100 logo, I'd actually upload a 200x200 version to the server, but set width and height to 100 in code. (It's important to use width and height attributes directly, not style="width; height;", as certain Outlook versions are picky about that.)

<img src="Facebook-HR.png" width="28" height="24" alt="Facebook" />

Double-sized images are needed for Hi-DPI screens such as iPhone's Retina screen, which already may amount to half of your audience. On those displays, multiple physical pixels take part in rendering a single logical pixel. As a result, fonts appear to be sharp, but your image may look somewhat blurry next to text, unless you provide a high-resolution copy that can actually make use of all underlying physical pixels.

A couple of warnings against two strategies that do not work well:

• Vector images are not universally supported across email clients.
• It's possible to conditionally provide two image versions - vector and raster, or hi-res and low-res - depending on the target device. Your initial tests might pass, but you'll see double images in forwarded emails.

The only conceivable reason why you might contemplate the strategies above is that with double-sized images you rely on email clients to automatically downscale the hi-res images when rendering on regular screens. In my experience, however, they do a pretty good job with that.

Responsive Full-width Images

In our Newsletter template, each large content section has a full-width illustration, which needs to scale down on smaller screens. There are two keys to making this work:

• Set max-width: 100%; so that the image is resized with the container.
• Leave the image's height attributes unset, so it is automatically calculated proportionally to the current width.

Hyperlinked Images

It so happens that all images in my emails serve as links. Even the large illustrations duplicate the call to action link in their respective sections.

When I wrap an <a> around an <img>, I add the following style attributes:

• border: none; in the image tag. You can skip this if you don't care about Outlook 2003 and earlier or IBM/Lotus Notes clients.
• text-decoration: none; in the link tag. Otherwise you might see underlines on white space around the image.

<a href="https://www.devexpress.com" style="text-decoration: none;"><img src="logo.png" width="156" height="30" alt="DevExpress"
         style="border: none;" /></a>

Styles: Inline or CSS Classes

Throughout this article I apply style settings inline, using the style attribute. If you download the entire source code you'll see that this is how I actually do things, with only a few things defined in <HEAD> CSS classes. There's a reason to this separation.

In part, this echoes the days when even Gmail had problems applying a font-family defined with a CSS class. They seem to have outgrown this, but a few online email clients will still only honor CSS settings defined inline. Since I want my emails to look good everywhere, I came up with the following compromise:

• All layout-related settings are inline (the layout is never broken).
• Styles that only have a cosmetic effect, such as font-family, are defined in external CSS classes.

There weren't many settings I considered "cosmetic", however. The following code pretty much sums it up. Frankly speaking, if font-family had been more compact, I'd consider leaving it inline.

<style type="text/css">
    td, p, li, a, span {
        font-family: 'Segoe UI', Helvetica, Verdana, sans-serif;
        mso-line-height-rule: exactly;
    }
    a {
        text-decoration: underline;
    }</style><!--[if gte mso 9]><style>
    li {
        text-indent: -1em; /* Normalise space between bullets and text */
    }</style><![endif]-->

The CSS issue boils down to finding your personal comfort zone. I assume a lot of people wouldn't be as cautious as I am, and will move more styles up to the <HEAD> section, since it promotes effective code reuse and easier maintenance. Also, the majority of clients do support external styles now.

Preheader: Message Preview Text

In all of our email templates you'll see the following sections, which go above all other content.

<!-- preheader text --><p
style="font-size:1px; line-height:1px; color:#ff7200; display:none!important;">
    As part of our commitment to continuous improvement, we've released ...</p><!-- end of preheader text -->

As you can see, all applied styles are just different ways of saying "hide me". I start with a display: none; attribute, and if that doesn't work, the text is colored to match the background. font-size and line-height are both set to 1px to ensure minimum influence on the layout.

Although my message's audience will not see that text, email clients will fetch it to display in the Message Preview section, which is a great way for me to sum up the content thus motivating the recipient to read more.

If the first sentence in the content already sums up the gist of your email pretty well, then you don't need to add this "preheader". This, however, is often not the case. As shown in our Newsletter template, your email might start with text that urges readers to add your email to the address book, or other technical information. In those cases, use this hidden text trick to substitute the preview text with a more relevant message.

Final Words

As I mentioned in the introduction, I consciously chose to use the most common, widely-supported HTML entities. I hope you can leverage my examples or entire templates to quickly build professional-looking emails with clean code. If required, you can find lots of additional tricks online - those that enable background images under your content, or even animations in certain clients, and so on. Those can easily be integrated with the code shown in this article. I didn't want to include them here, in an already lengthy article, so that I could stay focused on the basics.

Should you have any comments or questions, let me know in the comments below.

Version 1.0.0 of the DevExtreme React Grid is now available!

The path from the first alpha to this first public release has been long. We have received lots of positive feedback from our early adopters and we can’t wait to see what you will create with the React Grid. The DevExtreme Reactive team is inspired by you. We are also proud to say that we have several external contributors, and we are happy to help you make the product even better.

Versioning

We will strictly follow the Semantic Versioning 2 specification.

A main goal of our first stable release is to provide a future-proof basis for new features. This implies API stability, and we guarantee there will be no breaking changes in the 1.x version branch.

We are going to release bug fixes frequently, as patch versions for the latest minor release (e.g. 1.2.x).

Supported Rendering

At this time, the DevExtreme React Grid supports two rendering engines out of the box: Bootstrap and Material UI.

Material UI

React Grid for Material UI is built against material-ui@1, which is currently in beta. It is a required peer dependency. The lower-level React Grid API on the other hand has no external dependencies, so we can guarantee that new versions of the material-ui library will not break our code. However, we will need to update our code base for new releases of material-ui and we will treat any resulting breaking changes as bug fixes.

Bootstrap

React Grid for Bootstrap started as an integration with bootstrap@3. During our pre-release phase, bootstrap@4 has been officially released and we have started working on its support. We are going to publish bootstrap@4 support in minor releases soon.

Plans

We have implemented many features, and there are more to come! We listen to community requests and plan to implement the most frequently requested features, such as TypeScript definitions and Column Pinning support. We will also work hard on performance improvements and we will continue to provide a minimal bundle size footprint.

We are planning to announce more exciting stuff in the near future. Stay tuned!

On January 18th, 2018, two moderate security vulnerabilities in jQuery were discovered (CVE-2016-10707, CVE-2015-9251):

These vulnerabilities are specific for jQuery versions older than v3.x and we consider them to be relatively low in severity because:

• CVE-2016-10707 - does not affect jQuery v1.x/2.x nor jQuery v3.x. It’s a transient issue which existed in a specific pre-release build

• CVE-2015-9251 - While this vulnerability could “expose your site to XSS attacks”, the pre-conditions to this are not common. The app must connect to 3rd party hosts and those hosts need to be hacked/misconfigured

However, if you've not upgraded to jQuery v3.x yet, we encourage you to for two main reasons:

1. jQuery v1.x and v2.x are officially at end-of-life
2. To patch your website of these recent vulnerabilities

In this post, I'll discuss which DevExpress controls use jQuery, how to update them, and our future plans.

DevExpress Plans

The DevExpress ASP.NET (WebForms, MVC, and Bootstrap) controls use jQuery v1.1.x. (We embed jQuery libraries delivered in our assemblies only if Embedding Third-Party Libraries is enabled).

Prior to v17.2, jQuery was obligatory for DevExtreme projects. Since v17.2, it's optional but still widely used by lots of DevExtreme users.

We plan to update to jQuery v3.x for past minor releases and upcoming major releases. Switching to a different jQuery version could lead to a breaking change so we are performing serveral tests before we update to jQuery v3.x.

The DevExtreme MVC controls will be upgraded to use jQuery v3.x in the following releases: v17.1.10, v17.2.6 (coming soon), and the next major release v18.1.

The DevExpress ASP.NET MVC controls' project templates will be upgraded to jQuery v3.x in the upcoming v17.1.10 and v17.2.6 minor releases. Then, in the v18.1 major release, we'll update all ASP.NET controls (WebForms, MVC, and Bootstrap) to use/reference jQuery v3.x.

However, we recognize that many developers use jQuery independently from our controls and to you, I would recommend upgrading jQuery too (with proper testing).

Upgrade jQuery

The v17.2.6 minor release will be available in a couple of weeks and I recommend that you install that for the easiest way to upgrade to jQuery v3.x.

You can upgrade your website that uses the DevExpress ASP.NET controls, DevExtreme MVC Controls, or DevExtreme client-side controls today because they both support jQuery v3.x.

The jQuery team has provided an excellent upgrade guide:

https://jquery.com/upgrade-guide/3.0/

Because there have been major changes in jQuery from v1.9/2.0 to 3.x, they've created a helpful jQuery Migrate Plugin:

For my own sites and blogs, I’ve used jQuery Migrate to identify problem areas (and they were few and far between, generally to do with methods that had been deprecated). jQuery Migrate does two things: it logs problems to the console (so you can see what needs changing), and it also adds back the deprecated stuff. In other words, the JS on one’s site still works and you get an indication of what to change in order to upgrade. - Julian Bucknall, DevExpress CTO

Note: For the client-side DevExtreme controls, you can also upgrade to jQuery v3.x or you can change the underlying client-side framework. However, this is a costly suggestion and one that you're not likely to do unless you're starting a new project. In which case, consider using Angular or React (which do not rely on jQuery).

If you run in to any issues then please contact our support team and they can help you.

Thanks!

Email: mharry@devexpress.com

Twitter: @mehulharry

Another 30 day sprint, another CodeRush release for Visual Studio. And this release includes a powerful new feature we’ve been working on that we think you’ll love. Let’s get right into it:

Smart Duplicate Selection

CodeRush’s Smart Duplicate Line (SDL) gets even smarter and morphs into Smart Duplicate Selection. This feature makes creating structurally-similar code significantly easier, and orders of magnitude faster.

This feature can be used in any language you can work on in Visual Studio, however its intelligence and abilities vary depending on the content you’re building, so let’s go through a few samples to get an idea of what it can do.

First, let’s start with some C# test code that creates a new instance of a Ninja, like this:

Now I might want to create more Ninjas for the unit test. Normally I would select the block of Ninja-building code, copy it to the clipboard, move the caret to the end of the block, paste the copied code, then navigate into the new code, change a part needed to create my second Ninja, and then repeat these last two steps until the new ninja code is done.

Phew! That’s a lot of work just to create a second Ninja.

Smart Duplicate Selection (SDS) starts the same way - select the code you want to duplicate. But instead of copying anything to the clipboard, just press Shift+Enter to duplicate the selection.

SDS duplicates the selection, placing text fields around the code - parts likely to change in the duplication. Don’t worry if you see a lot of text fields when you first try this. If I’m on a text field and I don’t want to change it, I press Enter to move on to the next text field. I’ll show you how to clean this up in a moment. For now, let’s focus on the changes we want to make to this duplicated block.

For example, I might change the variable name to “ninja2”, the Name to “Leonardo”, ServedInOniwaban to true, and the birth year to 1985. pressing Enter after each edit.

It’s fast and efficient.

But this feature gets even smarter when you try to duplicate again. Let’s create a third Ninja based on the changes we just made.

Now, you could select the second Ninja-building block we just edited, and press Shift+Enter again. And while that would work, it would be an excessive number of key presses just to repeat the last duplication.

Fortunately SDS gives you a super-fast way to repeat the last duplication - just press Shift+Enter again when you reach the end of the duplicated selection (or when the caret is inside any text field of the duplication).

Pressing Shift+Enter (in our ninja-building example) to repeat the last duplication, we now get something more closely reflecting what we want to modify:

Now we have only four fields, surrounding the duplicated code we changed in the ninja2 declaration. SDS also auto-increments the variable’s name (and other numeric primitives and enums) based on the changes made to the code.

With only four fields we just change or accept what we need, pressing Enter between changes four times.

It’s pretty amazing stuff. You can create structurally similar blocks of code or script or markup or any text at all, changing only the parts you need, and create multiples of that with what some might consider the fewest keystrokes possible.

Once SDS learns what we want to change, we can repeat it by continuing to press Shift+Enter when we reach the end of the duplicated selection (or when we’re inside any TextField of the duplication).

It’s the most efficient path to creating similar repeating blocks of code/script/markup/text.

You might also be wondering, “well, what if I already know what fields I want to modify?”

This question is best answered in a second example. Let’s switch over to XAML, where we might be creating an interface that (so far) looks like this:

This UI shows download progress, but we want to add similar status controls to show progress for installation, configuration, and registration (all of which happen during our install).

The XAML for the “Download: 0%” part of the UI looks like this:

We’ve got a horizontal StackPanel containing two TextBlocks, one for the label and the other, named, for the value. So, we need to duplicate this StackPanel and its children three more times. And in each duplication, we want to change only the Text of the label TextBlock and the Name of the value TextBlock.

Since we already know what fields we want to change, we can mark those using CodeRush’s multi-select feature. It’s easy. Just select the sections of code you want to modify and press Ctrl+Alt+Enter. Like this:

Notice I’ve only multi-selected one instance of “Download”, even though I want to also modify the name of the second occurrence in “tbDownload”.

That’s okay, because SDS will automatically find all camelcase matches to anything we multi-select and linkthose together in the duplication.

Now select the block we want to duplicate (tip - for even faster selections, use Selection Increase)…

Press Shift+Enter…

And now enter the new text for the label: “Installation”.

Done.

Ready to create another StackPanel/TextBlock set of controls for the “Registration” part of the spec? We’re already inside a text field, so we can press Shift+Enter to repeat the last duplication:

Enter the label text: “Registration” and press Shift+Enter again, then enter “Configuration” and press Enter because we’re done.

Our interface now looks like this:

And it includes four properly-named TextBlocks (tbDownload, tbInstallation, tbRegistration, and tbConfiguration) that we can easily access from code-behind.

You can also use SDS to duplicate CSS styles, HTML controls, parameters in method declarations, binary expressions, arguments, string constants and entire method blocks.

SDS will also remember changes you make in each file and suggest those same changes in similar duplications you perform in the same file.

You can also now dismiss all text fields by pressing the Esc key. This is especially useful for Smart Duplicate Selection because it may generate many text fields on the first duplication, and you can press Escape before or after you’ve modified the fields you need to change.

That’s the killer feature in this release, and we hope you find it as useful as we do. Let us know what you think and how we can make it even better.

Code Formatting

Earlier versions of the code wrap option would move the entire expression to the next line if any part of it exceeded the margin. The new Simple Wrap formatting option allows you to wrap only those parts of the expression that exceed the margin, performing a non-greedy wrapping and in some cases reducing the number of lines needed to see the code.

Unit Testing

• You can now run unit tests under SciTech Software’s .NET Memory Profiler. If this third-party product is installed, you can use the Run Under Memory Profiler option to run tests designed to identify memory leaks and other memory usage issues. Note: support for the CodeRush Test Runner is included with the .NET Memory Profiler versions 5.6 and up.
  
• CodeRush Test Runner now supports running tests created for the F# language.

Code Analysis

CodeRush Analyzers now appear in the Code Issues Catalog. You can use this options page for the following tasks:

• Enable/disable specific Code Issues.
• Add/remove Code Issues to/from Visual Studio’s background analysis.
• Specify the severity of each Code Issue.

Region Creation

CodeRush Classic’s Region Creation feature is now available in CodeRush. Use the Ctrl+3 shortcut to create a region around the current member or selection instantly.

C# 7 Syntax Support

We are supporting С# 7 syntax in CodeRush features that generate exception-throwing statements (like Throw Exceptions Contract).

Now these CodeRush features generate the specified throw-expression operation if the corresponding preference is set in the Visual Studio settings.

Give CodeRush a Try!

Download CodeRush from the Visual Studio Marketplace.

Every 30-day sprint we work hard to make CodeRush the best it can be. Let us know how we’re doing, and what we can do to make CodeRush even better for the way you develop.

In the next major release of DevExpress (v18.1), we are dropping support for Internet Explorer (IE) 9 and 10 in DevExtreme and dependent products. The following subset of products will be affected:

• DevExtreme
• XAF Web & Mobile
• The following ASP.NET controls and their MVC extensions (these controls are built with DevExtreme):
  • ASPxQueryBuilder
  • ASPxWebDocumentViewer
  • ASPxReportDesigner
  • ASPxDashboard
  • ASPxDashboardViewer

We actually wanted to drop support in 2017 but we know that there is a small subset of our customers who are still using and still need IE 9/10. This is also why we've been prolonging our support for IE9/10 in other ASP.NET controls for a while

In a few months when v18.1 is released, DevExtreme controls (client-side and MVC) will no longer support IE 9/10. I recommend upgrading to the latest versions of IE, however, Microsoft recommends that you switch to Microsoft Edge. Of course, there's plenty of other great browers available like Chrome, FireFox, etc.

Microsoft no longer supports IE9 and IE10

Microsoft has stopped supporting IE9 and IE10 since January 12, 2016. It officially claims that:

Beginning January 12, 2016, only the most current version of Internet Explorer available for a supported operating system will receive technical supports and security updates. Internet Explorer 11 is the last version of Internet Explorer, and will continue to receive security updates, compatibility fixes, and technical support on Windows 7, Windows 8.1, and Windows 10.

According to the world-wide browser usage statistics the IE versions older that 11 share just about 0.1% of users.

Modern Browsers, ftw!

However, it's now time to move on. For us at DevExpress, it's a costly proposition to support older browsers. There's the need for compatibility testing, for patching older versions for our support, but there are two overriding concerns:

• Because these older browsers are no longer updated, there is a great risk of security breaches for you, your users, and your organization.
• We cannot take advantage of modern web technologies (and approaches). That means we cannot deliver the best possible performance, user, and developer experience with DevExpress products. This is especially so for modern client-side JavaScript applications that need modern browser features.

In short, that's why we've made the decision to remove explicit support for IE9 and IE10 in the set of products mentioned above and we strongly encourage you to do the same, if you have not already done so.

Old Built-in Android Browsers

An excellent feature that we want to utilize for DevExtreme is CSS Flexbox Layout. Unfortunately, it is not supported in the old built-in Android browsers (up to Android 4.3.x). Therefore, will stop supporting old Android browsers in v18.1 as well. Be aware, this might affect those who are developing hybrid mobile apps for Android.

Feedback

I would love to hear your feedback on this decision.

Will this affect you?

Drop me a line below or email me.

Thanks!

Email: mharry@devexpress.com

Twitter: @mehulharry

Just a quick note to say that the DevExpress team are in Frankfurt this week to support two events: BASTA! and Microsoft Tech Summit. Luckily the events are right next door to each other: the first at the Frankfurt Marriott Hotel and the second, over the street, in hall 3 of the Frankfurt Messe.

At BASTA! there’s our DevExpress booth with John Martin, Don Wibier, and Oliver Sturm, with the latter two also presenting various sessions and workshops. At Microsoft Tech Summit, we have another DevExpress booth with Przemysław Włodarczak and yours truly. Yes, two booths at two events in the same city at the same time: I think this is the first time we’ve done this!

If you’re here at either event (or both), first of all my congratulations since they’re both sold out, and second, please do come over to either one and say hi. We’ll be glad to talk about and show off what we’re doing at DevExpress and to investigate how we can help you in your development efforts this year. See you soon!

Last week, on Wednesday and Thursday, was the Microsoft Tech Summit (MTS) at the Messe Frankfurt. Hall 3 to be precise. And you had to be precise: although the Messe is a sprawling convention center with six halls, let alone the concert hall (pictured), due to security concerns you had to enter by one gate and one gate only.

With me was Przemysław Włodarczak, our whizz CodeRush developer from Poland, so you can imagine that the CodeRush demos he did in the booth were something to be experienced. Me, on the other hand, I had my hands full in demoing our WPF controls, as well as DevExtreme, especially for ASP.NET Core and Angular. We met existing customers (including a couple who were weaning themselves off their Silverlight apps!) and touched base with some possible new customers. Let’s hope we were able to sway them with our demos, if not the DevExpress Eat-Sleep-Code t-shirts we were giving away.

The surreal thing about this MTS event was the layout in the hall. To emphasize the themes of Cloud, Cloud management and development, the sessions were all held in eleven “Cloud” tents inside the Hall. These were inflatable white tents with rows of seating inside. An imaginative solution, to be sure, although I was told the really popular sessions meant that things got a little warm inside.

For us, with our hotel and the BASTA! event half a mile away, we got very used to the freezing cold winds funneled by the Messeturm as we walked back and forth to the hotel. Back in the day, when I worked for a certain bank in Frankfurt, this tower was known as the Pencil, for obvious reasons. It was the tallest building in Europe until 1997, when the Commerzbank Tower (also in Frankfurt) was completed.

Starting with the upcoming major release, v18.1, the DevExtreme hybrid mobile-related tools will be deprecated and placed in to maintenance mode. However, we plan to support creating mobile apps through popular hybrid frameworks, more on this later.

Our hybrid mobile-related tools includes our SPA Framework and Visual Studio Mobile Tools. [Note, that the Knockout integration will not be deprecated and you can continue to use DevExtreme knockout bindings in your apps.]

Maintenance mode means that we'll only fix critical bugs and not introduce any new features. Therefore, we do not recommend starting new projects with the hybrid mobile-related tools.

Why deprecate the hybrid mobile tools?

Here's four main reasons on why we plan to put our hybrid mobile tools in to maintenance mode:

1. The DevExtreme hybrid mobile tools were great when we first introduced them, however, today there are other popular frameworks that provide similar benefits
2. It's costly for us to support our hybrid mobile tools due to changes in dependent external tools and vendors
3. This will free up the team to provide you the tools that you've been asking for
4. You can replace some of our hybrid mobile tools with modern equivalents that are available today

Rest assured that the DevExtreme brand and tools are doing great and will keep growing. We are only deprecating the hybrid mobile tools.

History

Back in 2011, there was a lack of good hybrid mobile app frameworks that allowed you to build hybrid mobile apps with native looking UI and behavior. To address this market need for mobile, we launched DevExtreme. However, we designed DevExtreme as a product for both mobile (Cordova/ PhoneGap) and desktop web development.

We loved that a client-side framework, based on JavaScript, is flexible and can be used in multiple scenarios. So, we decided to create DevExtreme using several aspects of hybrid web development:

• UI controls and mobile themes (DevExtreme UI Widgets)
• App layouts and navigation (DevExtreme SPA Framework)
• Project seeding (DevExtreme Visual Studio Multi-Channel App Wizard)
• Debugging and deployment (DevExtreme Visual Studio Mobile Tools)
• Support the popular jQuery library
• Support the promising KnockoutJS library

That was many years ago and the landscape for hybrid mobile apps and client-side frameworks has changed.

Current Landscape

Today, there are three dominant client-side UI frameworks that developers are considering when starting a new web app: Angular, React, or VueJS. Yes, there are other frameworks too but they don't have a large userbase.

Let's take a look at some client-side libraries and how they shaped our decision to deprecate our hybrid mobile tools:

1. PhoneGap

Adobe's PhoneGap has been around a long time and it continues to grow with new features and tools. Unfortunately, changes in PhoneGap causes headaches for our DevExtreme customers and the DevExtreme team too because DevExtreme hybrid mobile tools rely on PhoneGap.

Another source of breaking changes affecting DevExtreme is Apple. Randomly, they may change the mobile app acceptance rules, deployment package requirements, or other hybrid mobile app requirement.

Essentially, this causes the DevExtreme team to spend resources fixing external issues rather than providing more value to our customers.

2. Angular

Today, Angular is the most popular framework. It targets Angular developers, has thousands of contributors, and is quite mature now. In short, Angular provides a great framework for desktop web development. However, Angular has made tremendous progress in providing hybrid mobile development too by using tools like the Ionic Framework.

It's also accompanied with a number of useful services for UI design, push notifications, DevOps, and other aspects of hybrid mobile development.

3. React

Facebook's React framework has been gaining popularity for the past few years. They also have a great mobile development framework called React Native. React Native allows you to build mobile apps with a native UI using JavaScript. Developers' experiences with React Native has drastically improved too with the introduction of the Expo toolchain. In fact, the React community is bringing new tools and improvements as it grows.

4. VueJS

VueJS is a young framework but with a rapidly growing community. It's difficult to predict the mobile future of VueJS, but some products such as Quasar or Weex might become mainstream for hybrid or native VueJS mobile development in the future.

5. KnockoutJS

DevExtreme provides deep integration with our controls and KnockoutJS. Unfortunately, there are fewer developers who use KnockoutJS each year.

We'll continue to support KnockoutJS because our integration is mature and it doesn't take many development resources. However, we do not plan to base our tools on KnockoutJS in the future. Instead, we are looking forward to Angular, React, and VueJS tooling.

Mobile Future of DevExtreme

The future looks bright for DevExtreme because in addition to growing our support for more client-side frameworks, we have plans to provide you support to create hybrid mobile apps using other hybrid frameworks and without the deprecated DevExtreme hybrid mobile tools. In a future major release, we're planning to bring you things like Visual Studio wizards, app layouts, and modified mobile themes.

However, you can create mobile solutions today with DevExtreme and a hybrid mobile app framework. For example, you can use the Ionic Framework and integrate the DevExtreme charts or other DevExtreme controls.

Are you developing a progressive web app (PWA) for both desktop and mobile devices? Then you can seamlessly use rich DevExtreme UI controls in it as well.

Alternative Recommendations

Since our DevExtreme hybrid mobile tools are going in maintenance mode, we've come up with a few possible replacements that are available today. Let's take a look:

• DevExtreme SPA Framework provides client-side application capabilities such as routing, navigation between views, app layouts, and view rendering and management. The modern frameworks we mentioned above like Angular, React, Vue, Iconic, etc. have these same capabilities out-of-the-box or as a separate npm packages that you can add. In a future major release, we plan to provide you new responsive app layouts that based on these modern frameworks and they will use DevExtreme controls in them. In essence, you'll have a File->New type of project template using Angular, React, etc and it will provide you a way for you to create new responsive web apps with DevExtreme controls.

• DevExtreme Visual Studio Multi-Channel App Wizard is very useful because it allows you to get started quickly by building you a mobile solution based on your data. This wizard creates an OData web service, then scaffolds a DevExtreme SPA Framework application, and also generates the views based on the new OData service. I'm happy to say that we'll replace this wizard with similar tools that can generate an ASP.NET MVC/Core API back-end and Angular views that will be bound to it.

• DevExtreme Visual Studio Mobile Simulator represents an in-browser HTML container for modeling real devices using screen size, orientation, and user agent. Google Chrome has a similar built-in feature. Moreover, it also simulates touch events. We recommend switching to Chrome's built-in tool.

• DevExtreme Visual Studio Mobile View Designer is a tool for visually creating mobile views with DevExtreme controls using drag-n-drop operations. This tool isn't used much according to it our usage statistics and user feedback. Creating views via markup is a common task these days for web developers. We don't have any plans to replace this tool, but if you need, you can find free or commercial tools for mobile app prototyping.

• DevExtreme Visual Studio Native Packer can create a native app package locally for uploading to Apple App Store, Google Play, and Windows Store. This functionality is available today from the PhoneGap Build service and we recommend using it instead.

• DevExtreme Visual Studio Courier App is used for remote debugging of DevExtreme hybrid mobile apps by accessing a local web-server from the Internet using your mobile device via an HTTP proxy. These days, you can find several different tools to perform remote debugging of your mobile apps. For instance, if you target React Native, you can use the Expo Client app. If you target Angular then Ionic View is your choice. You can also use the ngrok service to access your localhost remotely. We recommend using one of these other remote debugging tools going forward.

• DevExtreme iOS and Android Themes mimic native mobile apps appearance and behavior. We are going to replace the Android mobile theme with a modern Material Design one. The iOS mobile theme is going to be substituted with the improved Generic theme that will look very similar.

Wrapping up

So to recap, we are placing the DevExtreme hybrid mobile tools into maintenance mode because:

• There are many great client-side hybrid mobile app frameworks available today
• To avoid costly breaking changes and issues with mobile frameworks and vendors
• DevExtreme will shift focus on providing great UI controls for existing popular client-side and hybrid frameworks

As noted above, we have plans to replace some of these tools so that you can continue to build great UI in your apps that are client-side, hybrid mobile, PWA, etc.

Help us by sharing your mobile strategy with us. Do you plan to develop mobile using one of the following?

• Responsive website with PWA features
• Hybrid Ionic
• React Native app
• Xamarin
• Native mobile app
• Or something else?

Please leave a comment below or email me and your feedback will help us plan for future releases.

Thanks!

Email: mharry@devexpress.com

Twitter: @mehulharry