It has been observed that the Delphi documentation states that the constants True and False have the values 1 and 0 respectively, not the -1 and 0 that the default string conversions apply. This does actually make sense but also lays a trap for the unwary.
In my previous post on Anonymous Classes I erroneously referred to them as “dynamic objects” (thanks to commentors for pulling me up on that). Dynamic objects are something else entirely (although what precisely they might mean can vary on different platforms and in different languages). I have now corrected that post on this point, and also on another point that Marc Hoffman called me out on (again, thanks for that). And so the time has now come to expose the true identity of these so called “Anonymous Classes”.
There is another use case for anonymous classes, even simpler than that of providing implementations of interfaces: Anonymous POCO’s.
A few years ago (2011 to be precise) someone asked a question on StackOverflow about support for anonymous classes in Delphi. The reason for the question was that the poster was trying to use Delphi to develop for Android and on that platform the widespread use of callback interfaces makes anonymous classes highly desirable.
In my previous post I provided a simple example of how to use Retrofit to define, create and use a REST API client. Even in that simple example the issue of how to deal with different responses to a request came up. That is, where the response we receive does not conform to the strongly typed response we expected (or hoped for). Here’s how we deal with that, in a strongly typed way.
I’ve recently been working on a new project involving an Azure hosted ASP.NET MVC WebApi application (actually a pair of them) and native mobile and web applications. Everything is – of course – built using Oxygene. For the Android mobile app I was looking for a REST API client library and have settled upon Retrofit and thought I would share the experience.
Yesterday I initially posted that you couldn’t mix Unified Syntax with “traditional” interface and implementation sections. Or what I am now calling Segregated Syntax. As sometimes happens, shortly after writing what I thought I knew to be true I discovered it wasn’t ! Sorry about that. 🙂 I promised to illustrate the scenario where I found it both possible and useful, and here it is.
In the periodic table of the elements, at #9 we find Fluorine. Curiously though the name “Fluorine” is not used (that I am aware of) anywhere in the Elements 9.0 release which dropped this week. But there is plenty of interest in this release, aside from Period Table curios.
This is a quick follow up post to further tease some of the exciting developments in the world of RemObjects Elements. Yesterday I posted about implementing a Windows version of my trivially simple RandomNumber application. Today, I present another Windows version. But this one doesn’t use .NET.
This final post in the mini-series re-creating a random number app for OS X, Android and .NET has taken a while not because it’s complicated but because I’ve been distracted by a far more significant cross-platform project and some significant and exciting developments in the world of Fire and Elements. More on that later First, let’s get this .NET app out of the way.