Archive for January, 2013

Delphi 2012 Redux

Thursday, January 31st, 2013

I delayed publishing this post as I contemplated the wisdom of doing so, but 2012 has been a big year for Delphi, so I thought I would review the events of the year and make my predictions for 2013 even if it’s the last day of January rather than the first.

Corporate

One of the biggest news items was of course Marco Cantu joining EMBT as a Delphi Product Manager. Sadly, this was not the only staff change at EMBT. Barry Kelly among others, decided to leave EMBT, and there were anonymous reports of lay-offs, and a large degree of employee dissatisfaction including no raises for employees since EMBT acquired CodeGear, as well as hiring of junior engineers in economically advantageous areas of the globe.

The new EULA agreement for XE2 included changes prohibiting the use of DBX drivers (EMBT’s and third party) for accessing remote databases in the Pro version of Delphi. These “proposed” changes were leaked to the community, and the agreement was subsequently changed to exclude the new restrictions.

With the release of FireMonkey (FMX) on Sept. 1, 2011 it’s been over a year that FireMonkey has been out in the wild. The introduction of FireMonkey heralded the deprecation of the VCL despite numerous enhancements, it’s clear that EMBT is betting the future expansion of the Delphi/BCB market on FMX.

Desktop

Since FMX was released, there have been two major component vendors providing support for FMX; TMS and FastReports. Delphi XE3 has also been released with an updated version of FireMonkey (FM^2). With third party advanced grid and reporting capabilities, FMX now has a sufficient tool set to author cross platform desktop applications for LOB (Line Of Business) applications.

Many of the technical blog articles on FMX have been quite critical of its implementation and lack of completeness in the version 1.0 release even in the desktop space.  Some of these deficiencies have been addressed in version 2, but the framework is still maturing, and the latest feedback on FM^2 by those deep diving the technology is not extremely positive.

Mobile

In the mobile space, several applications were authored and accepted into the Apple App Store using XE2 with FMX before FMX support for iOS was removed in the subsequent release (XE3). Users who bought XE2 for iOS were left with a discontinued version of the framework and development tool, with no clear indication what the future held for them. These early adopters were then required to pay to upgrade to XE3 for the privilege of beta testing the up-coming Mobile Studio, in order to ascertain what their migration path would look like, and whether they should continue to support EMBT’s efforts in the mobile space.

The Future?

With the layoffs/departures from EMBT, as well as delayed compiler releases it appears the decision to bet the farm on FireMonkey is not paying off yet, and even EMBT employees may no longer believe in the strategy. This is further validated by the attempted EULA change which would have required Pro users to buy a higher priced SKU, and the 10% price hike in the new year.

I think EMBT has bitten off more than they can chew. Trying to implement a cross platform UI framework is a major endeavor with minimal payback (development tool licenses only), and lots of competition. There are free frameworks out there, and ones that have been around for a long time. Creating a framework specific to the Delphi/BCB tool set immediately limits its market, and dramatically increases the code base that EMBT has to maintain. From what I can see, they are already challenged in that respect (just look at the number and age of QC reports). It’s been over a year since FireMonkey was released, and the adoption rate appears to be minimal if you look at the available components and applications based on FMX.

IMHO, the writing is on the wall.  Expect to pay more for Delphi/BCB licenses while EMBT pours their revenue into FMX to develop the market.   Expect to wait longer for bug fixes and suffer from longer startup times due to increased anti-piracy efforts. I would also expect that the Android and Linux support will be even later than indicated as EMBT focuses on the Mac/iOS platforms trying to get traction in one of the most appealing market segments for Delphi developers.

As unfortunate as it may be, I believe that FMX will continue to flounder and that’s why you don’t see vendors like Developer Express, or Raize porting their VCL products, and even after over a year the monkey is hardly on fire.  FMX will likely become a niche framework, used by some developers for XPlatform support and 3D development, while the number of developers moving to different languages and tools for new development continues to escalate.  Certainly the release of mobile studio will be a pivotal event for the future of FMX, and therefore Delphi.

When a Date Drives you Nuts

Wednesday, January 30th, 2013

It’s been several years since I used datasets for anything other than quickly displaying the results of a SQL Query or Proc.  Recently I have been reminded why I dislike the TDataSet based RAD development approach so much.

If you’ve ever done a DBX conversion you would know that DBX maps datetime database columns to TSQLTimeStampFields instead of TDateTimeFields.  If your datasets use persistent TFields, which is typically the case so developers can make use of TField events to provide formatting, and validation, then you’re in for a treat!  All the persistent TFields have to be removed so new ones can be generated at design-time using DBX to ensure the right field types are used.  Of course you don’t want to remove any additional TField descendants created at design-time that are not in the dataset, so it might be necessary to go through each one to determine if the TField originates from the underlying dataset (using FieldKind may not be enough).

Once you’ve finished re-mapping all the TFields, you have to re-connect all the event handlers.  Hopefully, the original developers actually centralized all the database related code into datamodules, or you will be going through every form in the entire project.  Even re-connecting all the dataset TField handlers in the datamodules may be a treat if handlers were not shared across TFields of the same type.  For instance, if you use the OnSetText, OnGetText events to provide standard date formatting for TDateTimeFields using edit masks for input with a different format for displaying the date, you have to reconnect numerous handlers to each persistent TField event and the only way to tell if you have it right is GUI testing.  If you don’t get it right you will see errors from TField.SetAsString() with no idea what field is causing the exception.  The easiest way to actually find out is to put a breakpoint on the method, enable Debug DCUs, and generate the error through the UI.

In an application using domain objects with the MGM pattern for presentation, all the TField handlers would be replaced with mediators that perform the translation between the UI presentation layer and the database layer.  If you need to enhance the application to work with a variety of date formats, for instance, instead of locking it down to the corporate standard format which I see most often when using TField events, the enhancement would only involve a change in one place (the mediator).  It’s a much DRYer approach.  While using TField events doesn’t necessitate multiple handlers for the same purpose (one per TField type instance), not many developers think about consolidating such code across the application, and the result is a maintenance nightmare, especially if you ever think about changing the database layer.

Avoid vendor lock-in, even if you’re not thinking about changing your database, consider using an ORM, or even database application layer interfaces such as hcOPF’s IhcQuery and IhcStoredProc so changing your database layer doesn’t result in sleepless nights.  One “proposed” EULA change could have you swapping a database layer in a hurry ;-)