Our mORMot won't hibernate this winter, thanks to FireMonkey
Everybody is buzzing about FireMonkey...
Our little mORMot will like FireMonkey!
Here is why...
What is FireMonkey?
FireMonkey is a scalable vector graphics based GUI framework exploiting GPU capabilities for hardware accelerated cross platform GUI’s, running on Windows, Mac OS X and iOS.
It's based on previous work of Eugene A. Kryukov, who has been hired by Embarcadero last year.
This previous framework was named DXScene, and you can still browse a lot of pictures, even on iOS support on Eugene's blog.
What's up, doc?
FireMonkey is the main feature of XE2, but not the only one.
From the compiler point of view, the main features are 64 bit compilation, and OS X cross-compilation and cross-debugging. You'll need to buy a Mac (or try some hack to install a virtual Mac on your PC) in order to test it, but it's very promising.
In comparison, the DataSnap enhancements included in XE2 are not so groovy: client proxy generation – for Android, .NET, Objective-C, Blackberry, iOS etc.. Should not be so difficult to implement, in a RESTful / JSON world...
LiveBindings – a way to create ‘live” relationships not just between objects but between individual properties of objects - is a tempting technology. Sounds more compatible with the n-Tier model than the previous RAD approach.
Our mORMot won't hibernate this winter
Thanks to FireMonkey, our mORMot / SQLite3 framework will
be able to stay awake during this winter.
Here is why:
- Delphi XE2 still lacks of a standard ORM, and our framework is just there, with some unique features (like its Client-Server, SOA architecture);
- Its n-Tier design makes it easy to change the presentation layer: the RESTful server can be accessed, through JSON, by light clients running on OS X or iOS - our mORMot is just waiting for FireMonkey to appear at its burrow's entrance - it is already LiveBindings friendly;
- Our kernel database is SQLite3, which is already part of both OS X and iOS;
- Our code was designed to be 64
bit ready, and since the optimized asm functions have their "pure
pascal" version, it will be able to run on ARM - even low-level performance
PCardinal(...)^=..) will work as expected, since iOS uses little-endian ARM mode, just as x86/x64 CPUs (as Android BTW);
- Most of the framework low-level stuff is concentrated in the SynCommons unit - we tried to avoid code duplication where possible, and there is already a full coverage of regression tests, ready to be run on new Operating Systems / CPUs;
- We don't rely on third-party components, and we manage the full source code of all our used units;
- Some Windows-specific units (like SynGdiPlus or such) are already simple and abstract enough to be implemented easily on another platform - and some specific classes (like the http.sys kernel server) have their own "generic" version (using plain sockets or Fastcgi).
So we are waiting for the fire to be released... monkeys and marmots on your mark!
FPC at the end of the tunnel
For its ARM back-end, it sounds like if Delphi will use FPC / Lazarus on the OS X site, within XCode, to create iOS applications. Even if I'm quite sure Embarcadero will get rid of the FPC compatibility as soon as possible (i.e. when their ARM compiler back-end will be available), there was certainly some internal debate in the San Francisco's building to embed or not FPC to Delphi XE2. I'm quite happy that the war I spoke about one year ago did not occur.
I don't know if it comes from open-mindedness or from pragmatism, but it surely put some lights on Free Pascal, which deserves it.
And since it will most probably use either Carbon on MacOS X (this is the main reason why Delphi XE2 is not able to produce 64 bit applications yet), or the C APIs of iOS, you will be able to use the same standard "Delphi" syntax for all platform, and won't have to use Objective Pascal paradigm.
Feedback and comments are welcome on our forum.