Category Archives: development

development, embarcadero, professional, software development

RAD Studio XE4 with Delphi for iOS is here. Who will use it?

14 Comments

Embarcadero has released RAD Studio XE4, its suite of development tools for Window, Web and for the first time, Apple iOS. iOS support first appeared in an earlier release, but in preview, and the current effort works using a new LLVM-based ARM compiler so is somewhat unlike the preview. Individual products such as Delphi XE4 are also available separately.

Looking at what’s new in Delphi and C++ Builder in XE4 it is apparent that iOS support is by far the main change since RAD Studio XE3, though there are two other significant changes:

  • Prism, a version of RemObjects Oxygene that compiles a Delphi-like language to .NET (and soon other targets) has been removed. Oxygene lives on at RemObjects.
  • FireDAC, a data access engine acquired from DA-SOFT, is now part of RAD Studio.

I ran up the new RAD Studio on a Parallels VM on a Mac, a VM on a Mac being the best way to try cross-platform development for OS X and iOS. The new IDE immediately presents you with instructions on setting up for iOS development (though I am not a fan of videos, preferring clear text instructions) but I no problems configuring the Mac agent (called PAServer) which makes this work. Start a new mobile app and you can pick a starter template or begin with a blank canvas.

image

I picked the Tabbed Application and was soon trying out my new app on the iOS simulator

image

So far so good, though the ability to run up a quick app is no proof of the quality of the development tool. Still, a few reflections.

As I noted earlier, it seems to me that Delphi developers are either Windows developers using the tried and trusted VCL (in which case there is very little for them in XE4), or developers who are targeting mobile platforms and using the cross-platform FireMonkey framework in order to share code between Windows, Mac and mobile. I guess it is also possible that developers targeting iOS alone will be so taken with Delphi or C++ Builder that they will come in as new users.

VCL developers now have 64-bit compilation and a mature framework, and given that the efforts of Embarcadero are now focused elsewhere, and that even Microsoft is going slow on new features for what it now calls “desktop Windows”, there is little reason for such developers to upgrade.

The key questions then are about the quality of the FireMonkey framework and the iOS support. It is hard for me to be objective, since I know Delphi from of old and it is a familiar environment. Delphi or C++ Builder for iOS has obvious attractions for such developers. I would be intrigued though to know what an Objective C or even a JavaScript developer would make of Delphi, coming to it fresh. I am sceptical whether an Xcode developer would find enough productivity benefit in Delphi and FireMonkey to want to move over, and suspect also that many would not be impressed by the FireMonkey approach to iOS controls, which are generally custom drawn rather than true native, or faked completely like the Segmented Control which you are meant to put together from SpeedButtons with segmented styling, as explained in the Delphi iOS tutorial:

image

Embarcadero is making a big play of being “true native” but native is not just about the executable code (I have written more about this elsewhere) and cross-platform always involves compromise.

There is also some disquiet in the developer community about the cost of keeping up to date with RAD Studio. The full RAD Studio XE4 Architect edition currently costs £2,892.60 ex VAT for a new user, or £1,927.80 to upgrade. If you just want basic Delphi, Delphi XE4 Pro is a more reasonable £642.60 for a new user, or £352.80 to upgrade – but you do not get iOS support for that, that is another £320.40 for the Mobile Add-on, and FireDAC if you need it a further £285.00. When XE3 came out, Embarcadero promised that iOS and Android support would be available later at a “low cost”; of course that is a relative and subjective term, but I can understand if some feel that the price is on the high side. Or you can buy software assurance and get upgrades free; I don’t have prices for that but the cost is significant.

It is unfortunate for Embarcadero that there is intense competition in the iOS tools space, not only from Apple’s excellent and free tools, but also from the likes of Xamarin and Titanium.

None of the above is intended to detract from the achievement of bringing Delphi to iOS, with Android promised, which is considerable.

development, professional, software development

Changes in the Delphi language for ARM and mobile support

1 Comment

Delphi developers should note changes in the Delphi language coming as a result of the move towards the LLVM compiler for mobile support. Embarcadero has released a paper describing these in detail. The just-released RAD Studio XE4 includes the ARM compiler for iOS, with an Android compiler to follow later this year.

It seems to me that Delphi developers will now fall into two broad camps:

1. Windows VCL developers for whom the new FireMonkey cross-platform framework is of little interest, either because they are not developing for Mac or mobile, or because they prefer other tools for those platforms.

2. Developers who are embracing the new platform targets, migrating code to FireMonkey or starting new projects there, and planning to share code across all platforms as far as possible.

If you are in the first camp, you need not worry too much about language changes yet. I believe it is Embarcadero’s long-term intention to unify Delphi’s compilers around LLVM on all platforms, but when or whether this will happen for Win32 and Win64 is moot; my guess is that what the company now calls the “classic compiler” will be around for a long time yet. However the Mac compiler may migrate to LLVM sooner. (I am speculating).

Currently, RAD Studio XE4 includes five compilers:

  • The Win32 compiler (DCC32)
  • The Win64 compiler (DCC64)
  • The Mac compiler (DCCOSX)
  • The iOS Simulator compiler (DCCIOS32)
  • The iOS ARM compiler (DCCIOSARM)

Of these, only the last one currently uses LLVM, though the iOS Simulator compiler behaves as closely as possible like its ARM cousin. In general the language changes are currently only applicable by default for the LLVM and Simulator compilers as far as I can tell.

What are the language changes? My quick summary of the biggest changes is as follows:

  • One string type only: UTF16, reference counted, immutable (though this is a point of confusion; reading the paper it seems it is not yet immutable as it describes modifying in place, but may become so).
  • 0-based strings. There is a compiler directive $ZEROBASEDSTRINGS, which is off for Delphi XE3 and Delphi XE4, but on for the mobile compiler in XE4.
  • Automatic reference counting. Objects are destroyed automatically when the reference count hits zero. MyObj.Free; does not destroy the object, only reduces the reference count (and destroys it if zero). You can create weak references (which do not increment the count) by using the [Weak] attribute. If you really want to destroy the object, use MyObj.DisposeOf;.

In addition, the With statement is now deprecated.

The language changes are described in detail in the paper The Delphi Language for Mobile Development, which you can find here.

.net, development, embarcadero, professional, software development

No more Delphi for .NET: Prism removed from RAD Studio XE4

Embarcadero is removing Prism from the next version of RAD Studio, XE4, expected later this month.

Prism is actually a third-party product, based on RemObjects Oxygene. Prism and Oxygene let you code in Delphi and compile to .NET or Mono.

Marc Hoffman from RemObjects explains the change here:

Starting with the upcoming release of XE4, Embarcadero Prism will no longer be part of the RAD Studio SKU, and there will be no “XE4″ branded edition of Prism.

But worry not. As you all know, Prism has been nothing more than a re-branded version of our Oxygene for .NET product — and Oxygene will keep going on, stronger than ever.

In fact, Oxygene has long outgrown its Prism-branded edition, first when we introduced full native support for Java and Android to the language over 18 months ago, and of course with our upcoming support for truly native iOS and Mac apps, shipping next month.

The disappearance of Prism is the final chapter in the story of Delphi for .NET. Borland’s Delphi was first released in 1995, and combined a visual interface builder superficially similar to Visual Basic with a native code compiler, enabling full access to the Windows API  as well as better performance than Microsoft’s VB.

Delphi built up a strong following, but in 2002 when Microsoft brought out the .NET Framework Borland worried that Delphi would be left behind. In 2002 it brought out CSharpBuilder, an IDE for C# targeting the .NET Framework, and in 2003 Delphi 8 which also targeted .NET.

Other .NET versions followed, but whereas native code Delphi was a compelling alternative to runtime-based platforms like VB and .NET, the .NET versions of Delphi were less distinctive. Developers coding for .NET preferred Microsoft’s Visual Studio, while Delphi developers preferred to stick with native code.

When Embarcadero acquired the Delphi tools from Borland in 2008, it dropped .NET support from Delphi itself and replaced it with Prism.

I doubt that the disappearance of Prism will cause much consternation. Prism developers will simply switch to Oxygene instead.

development, microsoft, software development, visual studio, windows

Microsoft’s Windows 8 app problem will not be solved by incentivising junk

3 Comments

Microsoft has launched a “Keep the cash” offer to developers. Publish up to 20 apps, 10 for Windows Phone and 10 for Windows 8, and get $100 for each of them.

image

The offer is little use for most of the world. The terms state that “Offer good only to legal residents of the 50 United States & D.C. aged 18 or older”.

It is little use for Microsoft either. How much development time does $100 buy? Still, there is a way to make sense of it for hobbyists or developers with some spare time. What you do is to create one of those apps that does very little but is specific to something like a particular sports team or pop star, and maybe searches the web for news about them. Then you replicate it 10 times over for 10 different teams or celebrities. Then you adapt it for both phone and Windows 8 store. That’s 20 apps, $2000.

In other words, the only thing this will achieve is to increase the amount of dross in these two stores. Microsoft is pumping the numbers, so that there is an appearance of success on the most naive analysis, counting the apps.

Incidentally, this is something that Windows Store VP Antoine LeBlond assured me Microsoft would not do, at the launch of Surface RT in New York last year.

Does Microsoft have an app problem? Yes, particularly on Windows 8. Windows Phone 8 is less of a problem; Microsoft’s phone is actually building some momentum from what I can tell and app availability is not too bad, despite some gaps such as Instagram and BBC iPlayer.

The app problem is nothing to do with quantity though. 10 good apps for the Windows Store is worth more to the platform than 10,000 poor ones. In fact, filling the store with junk is a negative that will cement the perception that there is little there that is worthwhile.

Rather, the app problem is the consequence of several factors:

1. The development platform is not good enough. Most things can be done, but not easily, and the default look and feel results in blocky apps that tend to scale badly on big screens. The built-in controls are too primitive. The user interface is insufficiently intuitive and users struggle to discover the menus and features hidden in the Charms bar.

2. Microsoft has so far failed to establish Windows 8 as a tablet platform. The reasons are complex and to do with the Windows heritage, the way OEM and retail partners treat Windows, and the fact that there are other tablet platforms (iOS and Android) out there which meet the need for many people.

3. Windows 8 is out there in reasonable numbers, but most users spend most of there time in the desktop, making the Windows Store app platform less successful than the quantity deployed would suggest.

4. Businesses are mainly standardising on Windows 7, not Windows 8, to the detriment of the new app platform.

In this context, the best thing that could happen for Windows 8 is the appearance of new compelling apps that will drive users to the underused tablet personality. Microsoft could and should do some of those (there are a few efforts, like Fresh Paint).

Those apps, though, will not be developed for $100. They will be developed either by enthusiasts who love the platform (which will not happen until the platform is improved), or by businesses who invest real money and effort in building them.

As it is, this misguided initiative does little other than to draw attention to the problems Microsoft has with its new Windows.

development, mobile, professional, software development, web authoring

Native apps vs HTML 5: no consensus over how to choose

2 Comments

Wondering whether to invest in native apps or HTML5 web apps (maybe wrapped as native) for your next mobile development project? Welcome to plenty of confusion about which is the best path to take. Here are a few pieces of evidence from this month:

A Compuware survey of 3,500 consumers showed a preference for mobile apps over mobile websites:

When consumers were asked about the benefits of using a mobile app versus a mobile website (a website that is specifically designed to be viewed on a mobile device), the majority (85 percent) said they preferred mobile apps primarily because apps are more convenient, faster and easier to browse.

Just 1% expressed a preference for mobile websites over apps. Note that consumers cannot be expected to know whether or not a native app is actually written in HTML5 or not; but here is an intriguing report from Xero, which makes accounting software:

Very early on we chose to build Xero Touch using HTML5 technologies. That choice showed that we care about the future of the open web and its continued success as an application delivery platform and we firmly believe that HTML5 is the future of development across any and all platforms. We do not regret this choice – but we’ve found that building a complicated mobile application in HTML5 has been hard. Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex.

… the lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go … Maintaining and iterating a web app was becoming a big impediment – so the next release of Xero Touch will be built with native technologies and we’ve already made a lot of progress. It does feel better.

If a company is so unhappy with its development platform that it is willing to endure the pain and expense of switching, that is evidence of deep dissatisfaction.

On the other hand, here is the UK’s Government Digital Service:

Our position is that native apps are rarely justified. Since November 2012, central government departments and agencies have to get approval from Cabinet Office before starting work on apps. For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs, especially if the underlying service design is sub-optimal. Departments should focus on improving the quality of the core web service.

Is this because the Government Digital Service is spending public money and therefore apps are an unnecessary luxury? That is arguable, though it has not stopped the BBC (also publicly funded) from delivering a ton of apps, to predictable complaints from owners of less favoured platforms like Windows Phone.

This one will run and run. HTML5 will get better, but so also will native platforms, so I doubt this difficult choice will get easier any time soon.

It may be a matter of whether your particular app is a good fit for HTML5 or not. However, I am not aware of any consensus over what characteristics make an app a good or bad fit for an HTML5 solution, except that for broad reach HTML5 cannot be beaten, and for full access to device and OS features there is no substitute for native.

.net, development, microsoft, professional, software development

Internal Windows Runtime apps are prohibitively expensive to deploy, says Microsoft Regional Director

5 Comments

Now we know why Microsoft has been so reluctant to divulge details of how to deploy a business app that uses the Windows Runtime (also known as Metro apps or Windows Store apps; though in this case the Windows Store app designation is particularly silly since these apps are precisely not Store apps).

Presuming Windows MVP and Regional Director Rockford Lhotka is correct, a business that wishes to sideload Windows Runtime apps (in other words, to deploy but not via the Windows Store), a business needs to purchase a $30 sideloading key which, by a stroke of marketing genius, is only available in packs of 100.

image

Note the above screen grab shows a price of more than $30.00. I believe this is because Lhotka’s figures do not allow for any reseller markup, though there could be regional differences as well.

Here is what Microsoft’s Antoine Leblond said back in April 2012:

To enable sideloading of a Metro style app onto a PC:

  • Set Group Policy for “Allow all trusted apps to install”. If you cannot use Group Policy, then you can set this through the following setting: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1
  • Verify that the app is signed by a CA that is trusted on the target machines
  • Activate a special product key by using a script on the target machine to enable sideloading. We’ll go into more detail about how the IT admin will acquire the product keys in an upcoming blog post. The product key only needs to be install and activated once on the PC.

I have not seen the promised upcoming blog post but would be interested in doing so if anyone has a link?

Sideloading keys are only valid on Windows 8 Pro or Windows 8 Enterprise.

As a further disincentive, if you want to avoid running a PowerShell script on each target machine, you will need either System Center or InTune to manage the PCs. InTune is the cheaper option, at $6.00 per device per month. Lhotka calculates:

Let’s assume that your organization has 100 Windows RT or Windows 8 Pro devices, so you buy $3000 worth of side-loading keys. And let’s assume you use InTune. Finally let’s assume your devices have a 3 year life – which is pretty typical for corporate devices where you buy a service agreement from Lenovo or Dell or another vendor.

These 100 devices will cost $3000 for keys, plus $6 per device per month. This means that your org with 100 devices will pay around $23,000 extra to deploy a WinRT app just for this licensing.

and he concludes:

Right now it appears that Microsoft has worked very hard to devise a licensing and deployment scheme for WinRT apps designed specifically to discourage the creation of any WinRT business apps. Whether this is intentional or accidental I can’t say, but it is surely the case that no responsible business or IT manager could look at these scenarios and think that a move to WinRT for business app development makes sense at this time

That said, I am not sure he is being completely fair. I doubt a business will subscript to InTune just to support sideloading, and for those who do not want to subscribe, running a PowerShell script is not that hard. It seems to me that the problem could be mostly fixed by offering the sideloading keys in smaller packs.

I would add that now is probably not the moment to deploy a Windows Runtime app. The platform is not as good as it should be, and there is a case for waiting for the first major update in my opinion.

Still, $3000 for a licence pack is substantial, especially for a small business with fewer than 100 PCs.

The “Modern UI” side of Windows 8 has not taken off as yet, and a rational approach would be to encourage rather than discourage corporate developers to target the platform.

Note: a Microsoft Regional Director does not work directly for Microsoft. Lhotka works for Magenic. A Regional Director is an independent professional who is recognized for their ability to train and evangelise development on Microsoft’s platform.

development, microsoft, mobile

Windows Runtime flaws spoil new Windows Store (Metro) apps

1 Comment

The Windows Runtime, the new touch-friendly platform in Windows 8. It solves many problems. Not only is it tablet-friendly, but apps are sandboxed for security, and easy to deploy. No setup hassles, just one-click (or tap) install or uninstall. It also supports three types of development covering most tastes: native C++, .NET Framework, or HTML and JavaScript. In order to ensure responsive apps, Microsoft made many of the APIs asynchronous, so that users would not have the frustration of a frozen user interface or spinning hourglass during long operations.

At least, that is the theory. When I came to write my own simple app though, I was surprised how fiddly it was, and that something trivial like displaying a tweet including a working hyperlink turned out to involve Run elements, a ContentControl, a converter class and so on. Even then, I could not get the mouse cursor to turn to a hand icon when hovering over the link.

This hands-on experience gives me sympathy with others struggling to implement more complex projects. Some have posted about their experiences. Here is Frank Krueger, who has ported his neat iCircuit electronic circuit simulator from iOS and Android to Windows RT:

You would be shocked to see some of the crazy bits of code I had to put in because the Win8 platform, while very rich, is also very generic and doesn’t help you at all to build standard apps (document based, tools, etc.) That is to say, Cocoa is a very mature platform designed to make apps feature-rich and consistent while also making the developer’s life easy. WinRT on the other hand gives you rectangles and a blog post that says “good luck”.

He lists a number of problems, including having to reboot Windows constantly while testing the Share Charm; having to disable media elements in he app because of 500ms delays, no control over buffer sizes, and playback issues; and graphics issues:

I want to do real-time 2D vector drawing. Direct2D is perfect for this. But WinRT puts all sorts of limitations on onscreen rendering, most notably: you can only have 1 DirectX swap chain (view) per window. That means I can’t use Direct2D for rendering the scope which means the scope is slower than it needs to be. Dear Microsoft, go spend a few minutes and see how beautifully CocoaTouch and OpenGL work together on iOS. You might get inspired.

Next up is Media Monkey, a popular Windows media player which has been ported to the Windows Runtime platform. I was pleased to see this, as it lets me play FLAC music files on Surface RT. It is not very stable yet though, and I have had difficulty getting it to index the collection of FLAC files which I have on a network-connected drive.

image

What I found most interesting though were comments about the difficulty of displaying lists beyond a trivial size. One user complained:

When I first started MM scanning my music library, I was seeing the Album list grouped into sections headed up by the Alphabet letters. However, as more Albums got added, the heading letters vanished – and I now have an unbroken list of Albums – a great wodge that is very tiresome to navigate through by scrolling.

to which the Czech developer replied:

It’s a big problem, but not in MediaMonkey, but in system itself. Disabling groups is only crashes prevention because of system limitation :-(. Because of this we cannot use semantic zoom as well.

This has caused me to wonder whether part of the reason for the small number of excellent Windows Store apps is the difficulty developers have in getting them to work right. If so, that is a sad state of affairs for Microsoft’s shiny new platform.

In fairness, this is version 1.0, and the best hope is that a significant update to the platform will come before too long with improved controls, performance and features.

.net, development, professional, software development

Cross-platform frameworks ordered by percentage of shared code

4 Comments

Following my piece on different approaches to building the user interface in cross-platform frameworks, twitter user Sam Hogarth pointed me to the PropertyCross project. This implements a non-trivial application in 8 different cross-platform tools, covering Android, iOS and Windows Phone. Note that only four of the frameworks support Windows Phone.

Using the pie charts presented for each framework, I was able to order them by percentage of shared code as follows:

1= Adobe AIR (100%), JQTouch (100%) , RhoMobile (100%), Sencha Touch (100%)

5. Appcelerator Titanium (around 90%)

6. JQuery Mobile (around 80%)

7. Xamarin (around 40%)

8. Native (0%)

A couple of notes. Of the 100% frameworks, three do not support Windows Phone, and the one which does (Rhomobile) seems to be a bit broken on Windows Phone, judging by the screenshots. The Property Details and Favourites pages do not render properly.

You would get more code sharing with Xamarin if you only supported two rather than three platforms. That is logical: since it does not abstract the GUI.

In most cases (not Rhomobile) it is striking how different Windows Phone appears versus iOS and Android, even with jQuery Mobile which uses HTML5.

image

database, delphi, development, professional

Embarcadero acquires AnyDAC data access libraries for Delphi, C++ Builder

3 Comments

Embarcadero has acquired the AnyDAC data access libraries from DA-SOFT, including its main author Dmitry Arefiev. These libraries support Delphi and C++ Builder and support connections to a wide range of database servers, including SQL Server, DB2, Oracle, PostgreSQL, SQLite, Interbase, Firebird, Microsoft Access, and any ODBC connection.

AnyDAC is well liked by Delphi devlopers for its performance, features and support. Its architecture includes a local data storage layer similar to the dataset in Microsoft’s ADO.NET.

While it is good to see this set of libraries added to the mainstream product, developers are asking the obvious questions. What will happen to the cost and to the support for AnyDAC?

I am both scared and relieved at the same time. We took the AnyDAC route a few years ago, getting out of the BDE, and we have not regretted it for a second. My fright comes from the fact that DA-SOFT could not be beat in terms of customer support…many of us have come to DA-SOFT with a problem, only to have it fixed the next day. It is only realistic to think that with Embarcadero, this will no longer be the case.

says Dan Hacker on product manager Marco Cantu’s blog.

development, open source, software development

LocationTech: a new Eclipse working group for location technologies

The Eclipse Foundation has announced a new working group, called LocationTech.

What is it? There is only one project currently, called LocationTech Technology.

Here is what it covers:

LTT projects provide artifacts such as libraries, user interfaces, and methodology logic that enable location aware applications and services. The nature of this work is scoped as follows:

  • Developing and delivering location aware services for web, mobile, and desktop based systems.
  • Storage, exchange, processing, and interpretation of massive data volumes with a component of spatial information
  • Apply Model based design in the context of geospatial information systems, building information modeling, and computer aided design
  • Aggregating and relating data from diverse sources including a spatial component. e.g. Analytics, Geospatial Business Intelligence, Geocoding, Routing
  • The implementation of generally applicable geospatial standards (e.g., Open Geospatial Consortium, ISO TC211, SQL MM, etc.)

The group is sponsored by IBM, Oracle, OpenGeo and Actuate.

Projects hosted at LocationTech benefit from a range of services, including git code repository, bugzilla bug tracking, hudson continuous integration, apache and drupal for a project dashboard, and “intellectual property services” covering licensing and related areas.

LocationTech is seeking involvement from OpenStreetMap (discussed here) and MapBox, among others.

Names not on the list of sponsors include Google and Nokia. Is this, perhaps, an effort to support location-based development in a manner that does not include a dependency on Google?