XE4 and FireMonkey

paulh · 2013-05-09 10:17:59

Hi Arnaud, apologies if this has already been answered - I did a search for XE4 but found no hits.
I'm getting components in place to upgrade my application development environment to Delphi XE4. I tried a compile yesterday and was getting a compilation error in Syncommon. I have a fairly old version of Mormot that I'm running against (about 9 months old) - and was previously compiled with XE2 - has the framework been tested against XE4 and if so do I just need to get a latest version?

Also, now that FireMonkey in XE4 looks usable for me to write an iPad subset of my Windows app, I will want to make calls to Mormot interface from FMX client - has this been tested and anything I need to do different to the VCL implementation?

Regards

Paul

ab · 2013-05-09 17:32:39

Hi Paul,

I do not have XE4 at hand (no money nor need for it by now).
I suppose the latest version from http://synopse.info/fossil/wiki?name=Get+the+source - which works perfectly for XE3 - will compile for both Win32 and Win64.
If there is any compilation error, please report them here.

About iPad support, I'm afraid it is not feasible with the default set of mORMot units, which supports only Windows by now.
But you can access a mORMot server using Indy + internal JSON process, on any FireMonkey platform.

I'm afraid I would not support the "next gen" compiler, and will switch to FPC.
Immutable strings is a show stopper for me, as is end of UTF-8 string support.
FPC is very impressive and mature. And Lazarus is a great IDE.

paulh · 2013-05-09 19:45:08

Hmm, I didn't realise there would be an issue in moving it to run in firemonkey on iOS - I guess that since I'm only using the client/server interface with encryption and object serialisation I ought now move to my own implementation of these as you suggest using Indy, and object serialisation and a standard encryption mechanism.
As I'll never need to share objects with other clients using this interface, I think I'll avoid JSON and just use Delphi's serialisation of a TPersistent if I find that portable between VCL and FMX.
I've found your server processes to be very reliable so I hope my Indy servers will be as stable!
I've found your architecture to be very simple and clean so hopefully I can continue in the same vein.
Thanks for all the great code.
Paul

ab · 2013-05-10 07:21:07

About using TPersistent streaming via Indy, this is IMHO not a so good idea.
It sounds to be tempting at first, but I've already done this some years ago, and it did not work so well.
You will have to write the server part (and Indy is not so good at it), and Delphi serialization won't allow easily evolution of the content (i.e. client and server must have the same exact signature).
This is why I proposed to use mORMot on the Server side, then use Indy+JSON on FMX3/iPad client side. JSON+RESTful makes using mORMot clients pretty easy.

Honestly, if targeting a iPad client, I would rather use SmartMobileStudio and create an AJAX client.
It will work on iPad, iPhone, and Android, and also on Windows, OSX and Linux desktops.
You can package your SMS app into a native iPad/iPhone application, using PhoneGap.

I'll shortly add native support of SMS clients in mORMot.
It is already working, but I'll provide some official integration wizard (certainly to be added within the SMS IDE itself), and associated documentation.
See http://synopse.info/forum/viewtopic.php?id=1066
You can even use this SMS client code as reference to build your own Indy client.
Perhaps I may be able to add a "FMX client" wrapper, in addition to SMS clients.

paulh · 2013-05-10 15:38:04

Hi Arnaud, my architecture is that I have "Model" classes that are linked into both the server and the client. By use of compiler directives, I separate the server-side methods for each class that read and write the fields from/to the database so that means that by definition the client and server always remain in sync and that way I know the streaming will work.
The client apps are self-updating so as soon as I update the server with an interface change or persistent class change then the clients will go into self-update mode. I don't really mind what is used for the serialisation as it is only a means for freezing objects on server and transporting to clients and vice-versa so if Delphi serialisation doesn't work I'll replace with JSON but it needs to work with deep copies as my parent objects hold child objects in TCollections and life is too short to write code to do deep copying when TPersistent does that for you!

I'll take a look at SMS but there is no way I want to move to a scripted or non-native implementation like PhoneGap. That is why I don't do web development either - it is just such a compromise for the developer and the user.

Delphi is such a productive environment and produces the most amazing native Windows applications. The client app that I have produced for NHS in UK is 15MB in size and is very fast, very attractive and would be 50x more costly for me to create as a browser app. Now I can easily port that app to run native on Mac, iPad and in a few short months Android tablet too.

I suppose each to their own but I'm proud of the architecture I've built utilising your client/server persistent object framework and I'm looking forward to bringing that over to FireMonkey and using the same agility I enjoy on Windows now to implementing truely cross-platform versions using FireMonkey now that it seems to be maturing.

Paul

BrentG · 2013-05-10 20:27:31

>Honestly, if targeting a iPad client, I would rather use SmartMobileStudio and create an AJAX client.
It will work on iPad, iPhone, and Android, and also on Windows, OSX and Linux desktops.
You can package your SMS app into a native iPad/iPhone application, using PhoneGap.<

Ab,

I'm really disappointed you won't be supporting XE4 & iOS as a local database. :-(

I looked at SmartMobileStudio and liked their videos, but the last time I looked they also did not support local databases. I need to write db applications for iPad/iPhone where the user may not always have access to the internet. (They will eventually transmit their local database to a server so that's why I thought of mORMot.)

What development system do you recommend?

The only choice I see is XE4 with FireDac and Sqlite (unfortunately without encryption) and maybe connect to mORMot on the webserver. The lack of encryption (unless I license IB Pro for iOS) on portable devices is something I'd like to avoid.

Brent
P.S.
If I can get you a legal copy of XE4, would that help motivate you? :-)

ab · 2013-05-11 08:13:31

@paul
mORMot allows to (un)serialize nested objects, including TCollection.
http://synopse.info/forum/viewtopic.php?id=1035
I agree how Delphi can be productive - especially in comparison to other platforms.
SMS is also RAD based, so you can achieve a highly productive environment. But it has less integrated components - so you will need external JavaScript components to handle a grid, for instance.
In practice, SMS apps are very fast, when run in a modern browser (like any webkit engines).

@BrenG
As far as I know, SMS does support local database.
http://smartmobilestudio.com/documentat … l-storage/
http://smartmobilestudio.com/documentat … orage-api/
You have direct access to the HTML5 storage DB, i.e. either name/value pairs, either SQLite3.
There is a size limitation for a HTML5 application, but you can remove this size limitation as soon as you package it into a PhoneGap application.
Using FireDAC is therefore not the only choice.

You are the first two to explicitly ask for non-Windows support of mORMot.
This is the reason why we did not put the cross-platform item of the roadmap at first place.
See http://blog.synopse.info/post/2011/08/0 … FireMonkey
I did not do any support for this yet, because:
- FireMonkey was broken several times, has some part of it very poorly written, and do not support L2R languages - is it mature enough?
- iOS support was broken once - and I prefer FPC to this NextGen compiler (see below);
- We do not use FireMonkey in any of our applications;
- SmartMobileStudio is a good, fast growing, cheap, and stable alternative (with lack of documentation and 3rd party components, I admit);
- I also considered WxForms - http://twinforms.com/products/wxformsdelphi/index.php (which seems not supported any more, but did work well);
- Linux support is a goal for mORMot, on the server side.

Immutable strings are something I do not understand well.
Using "array of byte" as a workaround from AnsiString/RawByteString is possible, but will be slower and less convenient.
Honestly, changing from everything from AnsiChar to Byte is just an awful workaround and breaking change.
Just like a regression from the modern/turbo Pascal paradigm to a low-level C data type.

The switch introduced by NextGen/ARM/LLVM is IMHO much bigger than the one introduced with Delphi 2009.
For instance, for third party libraries (like our Open Source mORMot), you can maintain an existing code base for all versions of Delphi (e.g. Delphi 6 up to XE4), but you will have to maintain two versions of the code (or nest it with IFDEF) if you want to support NextGen syntax.

I'm confused with the Embarcadero NextGen compiler.
Performance is not a goal. The RTL is just worse at every Delphi version.

I understand that conversion to NextGen compiler can be easy.
See for instance how TMS reported it to be not difficult for Aurelius.
http://www.tmssoftware.com/site/blog.asp?post=263

But... do not forget that it may be on the depend of the performance.
Using pointers is not evil, if done with knowledge of it.
See http://synopse.info/forum/viewtopic.php?pid=6363#p6363 about FireBird ODBC access using Aurelius or our Open Source mORMot (which allows remote access, by the way, in addition to plain ORM).
IMHO this is one of the great features of compiled object pascal, in comparison to managed code, or the "NextGen" model.
My point is that pointers are not evil, especially for performance.
Of course, I'm speaking about typed pointers, not blank untyped pointers.

We could switch the mORMot code to be Next-Gen compatible, but since we use UTF-8 at the lowest level, it will need a lot of IFDEF.
Using "array of byte" instead of "AnsiString(CP_UTF8)" and "byte" instead of "AnsiChar" is just an awful regression and compatibility break.
We would have to use a lot of function wrappers, or perhaps re-create at hand a UTF-8 compatibility layer.
The whole mORMot core is depending on UTF-8, and IMHO this was *not* a wrong choice, on the contrary.
Deprecation of AnsiString was never prepared by Embarcadero. We knew it about shortstring - OK.
But deprecation of AnsiString in the NextGen compiler sounds like a showstopper to me.

And don't tell me it is required by the LLVM compiler to have immutable strings and UTF-16 encoding.
This is a pure Embarcadero choice.

Switching to FPC sounds a much easier path to me, than this NextGen compiler.

Of course, we will support XE4 for Windows.
I suspect the code already works, since it was working as expected with XE3, and we rely on our own set of low-level functions for most internal work.
If you have a licence to offer, we will make all the XE4 support for Win32 and Win64.

I've just written a blog article about it.
http://blog.synopse.info/post/2013/05/1 … sapointing

moctes · 2013-05-11 18:42:59

Hi Arnaud,

I'm not a mORMot user but a Delphi user, and I'm looking for excuses to make the switch to FPC/Lazarus so If you had a Lazarus mORMot version of the framework I would be tempted to try it on a new project I have on standby for a while.

Best regards,
Mocte

ab · 2013-05-11 20:00:46

On which platform?

moctes · 2013-05-11 21:18:38

Server side (on order of preference) :

1. Linux
2. Windows

Client side :

AFAIK mORMot can serve REST/AJAX so it can be any platform, I have planned some GUI development so Lazarus could serve for that purpose on Win/Linux (haven't seen much Mac OS noise on their forums ) and for the WEB well I haven't made my mind on this yet, there are so many options and I'm evaluating some of them, same goes for mobile.

Thank you.

BrentG · 2013-05-12 22:51:46

Ab,

Thanks for replying so quickly and thoroughly. If I were a dentist and you were in my chair, I fear I may have touched a nerve. :-)
At least it will open up a discussion that will make us aware of problems and benefits that lie ahead.

ab wrote:

@BrenG
As far as I know, SMS does support local database.
http://smartmobilestudio.com/documentat … l-storage/
http://smartmobilestudio.com/documentat … orage-api/
You have direct access to the HTML5 storage DB, i.e. either name/value pairs, either SQLite3.
There is a size limitation for a HTML5 application, but you can remove this size limitation as soon as you package it into a PhoneGap application.
Using FireDAC is therefore not the only choice.

I'm not so sure Sqlite is supported in SMS Pascal but I have asked on their forum and should get an answer back soon.

ab wrote:

You are the first two to explicitly ask for non-Windows support of mORMot.

I'm really surprised to hear this. I feel the future for software development must include mobile devices and that must include data storage. The major obstacle I've been facing is local db storage on these portable devices. Any development system I choose, must have the capabilities for a local relational database, like Sqlite (preferably with encryption in case the phone is lost).

I'm in Canada and we have one of the highest fees for mobile internet connections anywhere in the world. We have low caps and high over usage fees. Roaming fees in other countries, like the U.S. can easily exceed $10,000 for people on holiday just for checking email and watching a few short Youtube videos.

I cannot expect users of my software always to be connected to the internet to store their data in the cloud.

ab wrote:

This is the reason why we did not put the cross-platform item of the roadmap at first place.
See http://blog.synopse.info/post/2011/08/0 … FireMonkey
I did not do any support for this yet, because:
- FireMonkey was broken several times, has some part of it very poorly written, and do not support L2R languages - is it mature enough?
- iOS support was broken once - and I prefer FPC to this NextGen compiler (see below);
- We do not use FireMonkey in any of our applications;
- SmartMobileStudio is a good, fast growing, cheap, and stable alternative (with lack of documentation and 3rd party components, I admit);
- I also considered WxForms - http://twinforms.com/products/wxformsdelphi/index.php (which seems not supported any more, but did work well);
- Linux support is a goal for mORMot, on the server side.
Immutable strings are something I do not understand well.
Using "array of byte" as a workaround from AnsiString/RawByteString is possible, but will be slower and less convenient.
Honestly, changing from everything from AnsiChar to Byte is just an awful workaround and breaking change.
Just like a regression from the modern/turbo Pascal paradigm to a low-level C data type.
The switch introduced by NextGen/ARM/LLVM is IMHO much bigger than the one introduced with Delphi 2009.
For instance, for third party libraries (like our Open Source mORMot), you can maintain an existing code base for all versions of Delphi (e.g. Delphi 6 up to XE4), but you will have to maintain two versions of the code (or nest it with IFDEF) if you want to support NextGen syntax.
I'm confused with the Embarcadero NextGen compiler.
Performance is not a goal. The RTL is just worse at every Delphi version.
I understand that conversion to NextGen compiler can be easy.
See for instance how TMS reported it to be not difficult for Aurelius.
http://www.tmssoftware.com/site/blog.asp?post=263
But... do not forget that it may be on the depend of the performance.
Using pointers is not evil, if done with knowledge of it.
See http://synopse.info/forum/viewtopic.php?pid=6363#p6363 about FireBird ODBC access using Aurelius or our Open Source mORMot (which allows remote access, by the way, in addition to plain ORM).
IMHO this is one of the great features of compiled object pascal, in comparison to managed code, or the "NextGen" model.
My point is that pointers are not evil, especially for performance.
Of course, I'm speaking about typed pointers, not blank untyped pointers.

Yes but performance on an iOS device is not of primary concern. iOS and Android are not a multitasking mutli-threaded environments. It is only going to serve one connection at a time. I certainly wouldn't recommend using FMX to write a high capacity server, on that I think we agree.

ab wrote:

We could switch the mORMot code to be Next-Gen compatible, but since we use UTF-8 at the lowest level, it will need a lot of IFDEF.
Using "array of byte" instead of "AnsiString(CP_UTF8)" and "byte" instead of "AnsiChar" is just an awful regression and compatibility break.
We would have to use a lot of function wrappers, or perhaps re-create at hand a UTF-8 compatibility layer.
The whole mORMot core is depending on UTF-8, and IMHO this was *not* a wrong choice, on the contrary.
Deprecation of AnsiString was never prepared by Embarcadero. We knew it about shortstring - OK.
But deprecation of AnsiString in the NextGen compiler sounds like a showstopper to me.

Why can't you just create your own TmormString class and have all of the {$IFDEF ...} defined in that one unit?

ab wrote:

And don't tell me it is required by the LLVM compiler to have immutable strings and UTF-16 encoding.
This is a pure Embarcadero choice.

From what I've heard, immutable strings have not been implemented yet. It is something Embarcadero is considering in the future. How far into the future, I don't know.

ab wrote:

Switching to FPC sounds a much easier path to me, than this NextGen compiler.

I don't know how polished FPC is at producing iPhone apps. Their iOS documentation seems to be sketchy at best. It appears to me that their iOS platform is more for a hobbyist.

Brent

ab · 2013-05-13 07:14:04

BrentG wrote:

Ab,
Thanks for replying so quickly and thoroughly. If I were a dentist and you were in my chair, I fear I may have touched a nerve. :-)

only for the dentists who masters Delphi.

Your point of view does make sense.

My concern is that I'm still not convinced that FireMonkey is mature enough to be used on the client side, in respect to SMS.
And I can assure you that HTML5 support SQlite3 storage.
This is why SMS is so appealing to me: cross OS, RAD (to some extend, but much easier to work with than XCode), and with a great compiler made by Eric Grange.

In all cases, I do not have XE4 at hand to do the port yet.

But it is feasible, of course.
We can set type RawUTF8 = array of byte and work with it in the framework...
With a lot of IFDEF I'm afraid...
That means, spending a lot of time in working and proven code, just because EMB did not do its own work, and pick up the "easy" path for them, not for us?

BrentG · 2013-05-13 21:18:59

ab wrote:

My concern is that I'm still not convinced that FireMonkey is mature enough to be used on the client side, in respect to SMS.

That's what I'm going to find out too.

ab wrote:

And I can assure you that HTML5 support SQlite3 storage.
This is why SMS is so appealing to me: cross OS, RAD (to some extend, but much easier to work with than XCode), and with a great compiler made by Eric Grange.

I see that they do indeed support Sqlite. I have downloaded SMS and I'm looking at it now. It will take me about a month to determine whether I'll choose SMS or XE4 for iOS.
I assume you've got some examples on using SMS to access mORMot remotely on a server? It will be a few weeks before I get that far, but I had to ask. :-)

ab wrote:

In all cases, I do not have XE4 at hand to do the port yet.
But it is feasible, of course.
We can set type RawUTF8 = array of byte and work with it in the framework...
With a lot of IFDEF I'm afraid...
That means, spending a lot of time in working and proven code, just because EMB did not do its own work, and pick up the "easy" path for them, not for us?

Compared to other language platforms I've used over the past 30 years, Delphi had always been the most backward compatible language, until now. Maybe we got spoiled along the way? [VBG]
We will both have to monitor the XE4 FM newsgroups to see if it is attracting new users and see if it lives up to expectations. Sure there will be a few complainers, but I think the best test to judge success (or not) is to see how many XE4 iPhone apps appear in the Apple app store. In other words, "Can the Dog Still Hunt"?

I will try SMS for a month and maybe Delphi XE4 as well to see which one is better for iOS development. I'll let you know.

Brent

ab · 2013-05-14 09:53:40

About SMS integration see http://synopse.info/forum/viewtopic.php?id=1066
I'm currently adding "official" mORMot support in the SMS IDE in the short term.

Sounds like if all this made the buzz, at least in the Delphi NewsGroups, even Rudy did propose a petition, even if he claims not to need mutable/COW strings and AnsiString.

ab · 2013-05-15 08:33:50

Now mORMot compiles and works with Delphi XE4.

For Win32 and Win64 platforms.

See http://synopse.info/fossil/info/59eb20700d

According to Marco's white paper, strings are "soon-to-become immutable"...
See http://stackoverflow.com/a/16212755/458259
So deprecating AnsiChar is still not a good idea, and the Marco's pdf is very confusing...

BrentG · 2013-05-16 05:33:14

>So deprecating AnsiChar is still not a good idea, and the Marco's pdf is very confusing...

If Marco is confused, is there any hope for the rest of us?

>About SMS integration see http://synopse.info/forum/viewtopic.php?id=1066
>I'm currently adding "official" mORMot support in the SMS IDE in the short term.

That's great news. At least I know it will be there when I need it.

Brent

ab · 2013-10-24 14:04:31

Update: It is even worse than we thought...
One version later, it appears that the compiler itself and the RTL do support AnsiString!
BUT ANSISTRING SUPPORT HAS BEEN HIDDEN!!!

See this great blog article from Andy:
http://andy.jgknet.de/blog/2013/10/the- … e-strings/

BrentG · 2013-10-25 04:43:59

Ab,

All of my programming (and databases) for the past year has been Unicode. I don't think I'll ever need to go back to ANSI.
But I feel your pain. I had the same experience when I switched from EBCIDIC to ASCII some 30+ years ago. I am still recovering from that mental trauma and the night sweats are pretty much a thing of the past. Although I have to admit I still get chills thinking about writing code to convert tape data from one format to another. Brrrr! :-)

I recommend that you bite the bullet and embrace Unicode. The rest of the world has. The more you resist, the more you will be left behind.

Brent

ab · 2013-10-25 06:50:16

We embraced Unicode a long time ago.
Our RawUTF8 type is 100% Unicode, even with pre-Delphi 2009 versions of the compiler.
You are making a confusion between UTF-16 encoding and Unicode.
UTF-16 is NOT Unicode, it is only ONE encoding of Unicode.
http://en.wikipedia.org/wiki/Comparison … _encodings

UTF-8 is more efficient than UTF-16 for Unicode glyphs processing, especially when used in a JSON kind of data encoding (as mORMot uses).
http://www.utf8everywhere.org
XML and JSON are, by default, encoded as UTF-8.
The encoding of URLs is UTF-8.
The encoding XMLHttpRequest uses for encoding text strings when sending data to the server is always UTF-8.
And, when used over a network, you do not need to worry about endianess with UTF-8.

Contrary to popular belief, UTF-16 often takes up more space, even for CJK pages.
UTF-8 is often accused of having a Western bias and while this may be true, content on the Web does use a fair amount of markup and whitespace, which compresses a whole lot better in UTF-8.
Some guy at Mozilla explained the details and concludes with: "We've seen no data showing that UTF-16 is useful in practice on the real Web … except as a legacy encoding of course." - see http://lists.w3.org/Archives/Public/www … /0087.html

BrentG · 2013-10-28 04:28:35

ab,

From your post on 10-24 I was under the impression you were commenting on losing ANSI in Delphi XE5. There is a definite need for ANSI in many situations (like accessing hardware controllers), but for writing vertical market applications or web applications, I feel Unicode is the way to go. As far as adopting UTF-16 instead of UTF-8, then I agree with you. I prefer UTF-8. A non-Unicode text editor can read a UTF-8 text file just fine. UTF-8 is more efficient and more widely used than UTF-16 and is up to twice as fast on networks since it transmits fewer bytes.

I don't know why Emb went with UTF-16. Maybe you should ask David I?

Brent

ab · 2013-10-28 09:12:13

I suspect there is NO official statement from EMB.
And that there won't be any.

Marco's blog post is not the result of any internal debate or discussion, so it is not an official company position.
http://blog.marcocantu.com/blog/strings … rings.html

Marco wrote:

Let me comment:
-Improving RTL functions is always a goal. honestly, with fewer RTL functions (and fewer string types) it becomes easier to focus on those.
-For now, 1-based or 0-based is just a local compiler option, not sure if the request is to keep it this way...
- Immutability, as described above, is a potential future, which would be implemented only if there is a proven advantage
- The loss of AnsiString is the most controversial issue. The problem is that it is also the loss of UTF8String. And of AnsiChar. And of using pointers to directly manage character buffers. Which is not really lost, because this is what we are doing internally and suggesting externally. I do understand the request, but it seems to have different implications for different people (and string formats). Optimizing for English language is not a primary goal, as Delphi is used a lot around the world. Improving the management of raw dynamic arrays of bytes storing characters is certainly on the table.

No arguments here, just self-justification.
They can do whatever they want.
Not listening to customers is perhaps not the best attitude...

fletcher · 2013-10-29 00:19:46

I love your Mormot design and attention to performance.

I can't use it for 2 reasons.

Too much U2S, S2U everywhere. Very confusing and a PITA.
I wish we could declare our object using standard Delphi type: String.

Need XE5 and Firemonkey support for future.

Have you benchmark against kbmMW ?

Regards,
Rob

ab · 2013-10-29 08:43:00

fletcher wrote:

I wish we could declare our object using standard Delphi type: String.

No problem, you can use String within your TSQLRecord or services.

fletcher wrote:

Need XE5 and Firemonkey support for future.

I do not have XE5 at hand, is there any identified compatibility problem?

fletcher wrote:

Have you benchmark against kbmMW ?

It may be a bit like comparing apples and oranges...
kbmMW is very close to DataAbstract and RemObject.
It is RAD-oriented remote access to any DB, not an ORM. You have to create your SQL statements and your DB structure.
For the service part, it has an heavy class-based and wizard-generated approach, very far away from interface-based mORMot behavior.
Just compare http://www.components4programmers.com/d … rvices.pdf and http://blog.synopse.info/post/2012/03/0 … d-services

IMHO mORMOt is much more than this.
Just for the remote DB access, you can even JOIN the external tables.
For the services, there is no comparison between mORMot's KISS design using interfaces and kbmMW.
Then cross-cutting features, like security, caching, logging, are available in mORMot in a centralized and open way.
And I suspect it will be faster, due to our unique design (e.g. using http.sys kernel-mode server, and by-passing the DB.pas slow TDataSet).

fletcher · 2013-10-29 09:50:28

Your samples show always RawUTF8string, not String. Also lots of U2s, S2U. Is that no longer needed?

ab · 2013-10-29 11:06:57

Using U2S/S2U is the best way for performance, and for pre-Unicode version of Delphi.

But it is not mandatory, for Unicode version of Delphi (Delphi 2009 and up).

fletcher · 2013-11-06 09:09:32

I'm confused. As usual. When should we use U2S/S2U and in what Delphi versions?

ab wrote:

Using U2S/S2U is the best way for performance, and for pre-Unicode version of Delphi.
But it is not mandatory, for Unicode version of Delphi (Delphi 2009 and up).

ab · 2013-11-06 12:18:25

Using U2S/S2U or UTF8ToString/StringToUTF8 is mandatory for pre-Unicode versions of Delphi, to avoid charset conversion error to/from UTF-8.
Using U2S/S2U or UTF8ToString/StringToUTF8 is a good idea for Unicode versions of Delphi, to avoid warning of implicit string type conversion at compilation (which are always worth fixing IMHO).

But in your usual code (e.g. TSQLRecord properties definition, or interface-based services), you can always use plain string, if you wish to.

DigDiver · 2013-11-11 10:51:27

I think it is still necessary to add support for next-gen compiler in the future. There are interesting projects that facilitate the development for ios at Delphi and do not depend from FMX.

https://forums.embarcadero.com/thread.j … &tstart=45
http://www.tmssoftware.com/site/tmsicl.asp

ab · 2013-11-11 14:57:00

IMHO only for client-side.
So we would not convert the regular units of mORMot (like SynCommons.pas or mORMot.pas), but create some wrapper units for several targets:
- Delphi NextGen;
- FPC (+ Synapse?);
- SmartMobileStudio;
- C# (WCF);
- Java.

If NextGen would be introduced in the Desktop platforms, it would be a show stopper for us.

moctes · 2013-11-11 16:34:09

Interested in :

- FPC (+ Synapse?);
- SmartMobileStudio;
- C# (WCF);
- Java.

Regards

itSDS · 2014-05-14 09:13:02

After reading a lot in the Forum i think this Post fits best here.

I try to develop a pure delphi app for iOS and Android with XE6, FMX.
For native Data Storage i use UniDac Components.

For Client/Server Communication Sync / Dataexchange i prefer to use mORMot.
I'll write a native mORMot Server with a Port opened to the internet.

This should be secured with ssl and authentication.

ATM im confused which Client Strategy to use.

- How far is the mORMot Client ?
- Is there an Example for the propesed Indy - Client to Access mORMot Server ?
- Since XE5 there is a new Component in Delphi: TRestClient - which works on Android and iOS.
I have Problems to integrate the mORMot - Authentication is this Component - without Authentication it works. I need some hints (maybe example or Links) to program this.

ab · 2014-05-14 10:44:28

Authentication is documented in the SAD 1.18 pdf.

There are several authentication schemes.
You can switch to a simpler authentication scheme, if you need.

We would like to offer an official Indy-based client to the framework.
And we would like to use Mustache templates for auto-generating the .pas client files!
Perhaps the XE5 TRestClient may be used - but it sounds pretty basic and difficult to let evolve, and poorly documented.

If you have any code to help us start with, feel free to send it to webcontact01 at synopse dot info, or post a download link here.
Thanks!

itSDS · 2014-05-14 13:03:37

You're right the TRestClient is undocumented by Embarcadero and you have to dig through the source code and Example to understand.
It is based on Indy and has a JSON decoder integrated.

Sabbiolina · 2014-06-18 21:40:32

Hello, I'm intruding ...

after reading the disappointment strategies embarcadero with strings.

I was wondering what was the state of development of FireMonkey / android / ios.

thanks

ab · 2014-06-18 21:55:35

You have now a "CrossPlatform" sub-folder, containing cross-platform clients.
See http://synopse.info/fossil/dir?name=CrossPlatform

It works now with FireMonkey.
We did not fully test it on Android and iOS (since we do not need it on our side now, and do not have the XE5/XE6 license).
But it should work as expected to define mORMot clients.

Any feedback is welcome.

Sabbiolina · 2014-06-19 07:33:09

Thanks, but how to begin?

You can add in example 28, a version that uses the crossplatform, for the client?

ab · 2014-06-19 07:46:10

You have such sample in "27 - CrossPlatform Clients" folder.
See e.g. FMClient.dpr and MobileClient.dpr but it is only about basic process - the remote ORM is not tested.

martin.suer · 2014-06-19 18:56:00

It doesn't compile for iOS Target or Android Target yet. There are several issues. Several used String Types are not available in Nextgen. TObjectlist is not available. The whole Contnrs Unit is not available.
Do you want me to provide more Information? I can Test on xe5 & xe6 for iOS and Android.

ab · 2014-06-19 20:07:37

martin.suer wrote:

Do you want me to provide more Information? I can Test on xe5 & xe6 for iOS and Android.

Yes, please, I do not have those platforms available on my IDE.

martin.suer · 2014-06-20 15:09:47

ab,

here we go (I used the latest nightly build)

I created a sample FMX mobile client with this code

unit Unit1;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.StdCtrls,
  FMX.Edit;

type
  TForm1 = class(TForm)
    Edit1: TEdit;
    Button1: TButton;
    Label1: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.fmx}

uses
  SynCrossPlatformCrypto,
  SynCrossPlatformJSON,
  SynCrossPlatformREST,
  SynCrossPlatformSpecific;

// didn't want to change the sample unit, so pasted the definition here
// for testing purpose that should do it

type
  TSQLSampleRecord = class(TSQLRecord)
  private
    fQuestion: RawUTF8;
    fName: RawUTF8;
    fTime: TModTime;
  published
    property Time: TModTime read fTime write fTime;
    property Name: RawUTF8 read fName write fName;
    property Question: RawUTF8 read fQuestion write fQuestion;
  end;

procedure TForm1.Button1Click(Sender: TObject);
var
  database : TSQLRest;
  model : TSQLModel;
  rec : TSQLSampleRecord;
begin
  model := TSQLModel.Create([TSQLSampleRecord]);
  database := TSQLRestClientHTTP.Create(Edit1.Text,8080,model);
  TSQLRestClientHTTP(database).SetUser(TSQLRestAuthenticationDefault, 'User','synopse');
  rec := TSQLSampleRecord.Create (database,1);
  Label1.Text := rec.Name;
  FreeAndNil(rec);
  FreeAndNil(database);
  FreeAndNil(model);
end;

end.

When I try to compile, the compiler first tells me that Contnrs.dcu can't be found:

[DCC Fataler Fehler] SynCrossPlatformJSON.pas(63): F1026 Datei nicht gefunden: 'C:\src\MobileMormotTest\Contnrs.dcu'

According to Embarcaderos White Paper http://edn.embarcadero.com/article/43073 in section 5.1 states that the oldstyle Contnrs unit is not available on the mobile platform...

So just to get further I exchanged Contnrs with System.Generics.Collections and added a type declaration for TObjectList:

uses
  SysUtils,
  Classes,
  System.Generics.Collections,
  Variants,
  TypInfo;

type
  TObjectList = TObjectList<TObject>;
  TStringDynArray = array of string;
  TVariantDynArray = array of variant;

That leads to a couple of new error messages:

Abh‰ngigkeiten des Projekts werden ¸berpr¸ft...
Compilieren von Project1.dproj (Debug, iOSSimulator)
dcc Befehlszeile f¸r "Project1.dpr"
  c:\xe6\embarcadero\studio\14.0\bin\dccios32.exe -$O- -$W+ --no-config -M -Q -TX. -[... deleted some pathnames here ...]  -NBC:\Users\Public\Documents\Embarcadero\Studio\14.0\Dcp\iOSSimulator -NO.\iOSSimulator\Debug   Project1.dpr   
[DCC Hinweis] SynCrossPlatform.inc(64): H2586 Alte '$IFEND'-Direktive gefunden. ƒndern Sie diese Direktive in '$ENDIF', oder aktivieren Sie $LEGACYIFEND
[DCC Hinweis] SynCrossPlatform.inc(67): H2586 Alte '$IFEND'-Direktive gefunden. ƒndern Sie diese Direktive in '$ENDIF', oder aktivieren Sie $LEGACYIFEND
[DCC Hinweis] SynCrossPlatform.inc(70): H2586 Alte '$IFEND'-Direktive gefunden. ƒndern Sie diese Direktive in '$ENDIF', oder aktivieren Sie $LEGACYIFEND
[DCC Hinweis] SynCrossPlatform.inc(74): H2586 Alte '$IFEND'-Direktive gefunden. ƒndern Sie diese Direktive in '$ENDIF', oder aktivieren Sie $LEGACYIFEND
[DCC Fehler] SynCrossPlatformJSON.pas(692): E2003 Undeklarierter Bezeichner: 'WideString'
[DCC Fehler] SynCrossPlatformJSON.pas(1152): E2089 Ung¸ltige Typumwandlung
[DCC Fehler] SynCrossPlatformJSON.pas(1157): E2089 Ung¸ltige Typumwandlung
[DCC Fehler] SynCrossPlatformJSON.pas(1169): E2089 Ung¸ltige Typumwandlung
[DCC Fehler] SynCrossPlatformJSON.pas(1189): E2003 Undeklarierter Bezeichner: 'GetWideStrProp'
[DCC Fehler] SynCrossPlatformJSON.pas(1192): E2003 Undeklarierter Bezeichner: 'GetUnicodeStrProp'
[DCC Fehler] SynCrossPlatformJSON.pas(1231): E2003 Undeklarierter Bezeichner: 'SetWideStrProp'
[DCC Fehler] SynCrossPlatformJSON.pas(1236): E2003 Undeklarierter Bezeichner: 'SetUnicodeStrProp'
[DCC Warnung] SynCrossPlatformJSON.pas(1350): W1000 Symbol 'TList' ist veraltet
[DCC Warnung] SynCrossPlatformJSON.pas(1351): W1000 Symbol 'TList' ist veraltet
[DCC Warnung] SynCrossPlatformJSON.pas(1351): W1000 Symbol 'Count' ist veraltet
[DCC Warnung] SynCrossPlatformJSON.pas(1354): W1000 Symbol 'TList' ist veraltet
[DCC Warnung] SynCrossPlatformJSON.pas(1354): W1000 Symbol 'Count' ist veraltet
[DCC Warnung] SynCrossPlatformJSON.pas(1355): W1000 Symbol 'TList' ist veraltet
[DCC Warnung] SynCrossPlatformJSON.pas(1355): W1000 Symbol 'List' ist veraltet
[DCC Fehler] SynCrossPlatformJSON.pas(1392): E2089 Ung¸ltige Typumwandlung
[DCC Fehler] SynCrossPlatformJSON.pas(1413): E2003 Undeklarierter Bezeichner: 'ShortString'
[DCC Fataler Fehler] Unit1.pas(31): F2063 Verwendete Unit 'SynCrossPlatformJSON.pas' kann nicht compiliert werden
Misslungen
Verstrichene Zeit: 00:00:00.4

will leave it with that for now.

Last edited by martin.suer (2014-06-20 15:14:25)

ubaltino · 2014-06-20 20:42:09

ab

You made this statement anteriorly.

"See this great article from the blog of Andy: http://andy.jgknet.de/blog/2013/10/the- and-strings ... /"

Someone tested it, and there was a Client works for iOS and Android?

If succeeded, please tell what version of Delphi.

martin.suer · 2014-06-21 08:54:35

The invalid typecast error comes from the following:

function IsModTime(PropInfo: TRTTIPropInfo): boolean;
begin
  result := IdemPropName(string(PropInfo^.PropType^.Name),'TModTime');
end;

because PropInfo^.PropType^.Name is of type TSymbolName from unit System.Typeinfo and that is defined as follows in XE6

type
{$IFDEF NEXTGEN}
  TSymbolName = Byte;
{$ELSE  NEXTGEN}
  TSymbolNameBase = string[255];
  TSymbolName = type TSymbolNameBase;
{$ENDIF NEXTGEN}

so for NEXTGEN it is a Byte, otherwise a String[255]...

of course a Byte can't be compared to 'TModTime'

If I have some spare time I try to figure out what's the reason ...
My first Idea is that TSymbolName may have no meaning in NEXTGEN and is just a spare byte but who knows...

Last edited by martin.suer (2014-06-21 08:59:49)

ab · 2014-06-24 10:05:50

We just tried to enhance cross-platform client support, especially for the NEXTGEN target.
See http://synopse.info/fossil/info/83df4eccdb

itSDS · 2014-06-25 10:32:27

Im just testing NEXTGEN Code with iOS and found a big Problem concerning:

http://docwiki.embarcadero.com/RADStudi … sktop_Apps

0-based index

procedure DoubleQuoteStr(var text: string);
var i,j: integer;
    tmp: string;
begin
{$if CompilerVersion < 27)}
  i := pos('"',text);
  if i=0 then begin
    text := '"'+text+'"';
    exit;
  end;
  tmp := '"'+copy(text,1,i)+'"';
  for j := i+1 to length(text) do
    if text[j]='"' then
      tmp := tmp+'""' else
      AppendChar(tmp,text[j]);
{$else}
  i := text.indexof('"');
  if i < 0 then begin
    text := '"'+text+'"';
    exit;
  end;
  inc(i);
  tmp := '"'+text.Substring(0,i)+'"';
  for j := i+1 to text.Length - 1 do
    if text.Chars[j] = '"' then
      tmp := tmp + '""'
    else
      tmp := tmp + text.Chars[j];
{$ifend}
  text := tmp+'"';
end;

i just rewrote this func as Example, but there a lot lines of code where you assume s[1] = s[1] but it is s[0]

br Stefan

Last edited by itSDS (2014-06-25 10:34:32)

ab · 2014-06-25 11:02:21

itSDS wrote:

Im just testing NEXTGEN Code with iOS and found a big Problem concerning

There is no problem.

In current code, we wrote in SynCrossPlatform.inc:

  {$ifdef NEXTGEN}
    {$define HASINLINE}
    {$ZEROBASEDSTRINGS OFF}      // we expect to share code among platforms
    {$define ISDELPHI2010}
    {$define ISDELPHIXE}
  {$else}
   ...

So we forced one-based strings everywhere in our units.
No need to rewrite all functions: current version should use one-based strings in all platforms.

itSDS · 2014-06-25 11:33:50

I see you use this Compiler OPTION. In some other Part of my Software i didn't use it and got an error which i fixed as decribed in my former Post.

http://docwiki.embarcadero.com/RADStudi … s_(Delphi)

as decribed here it should not be used as global define only at little Subroutines.

ab · 2014-06-25 19:56:56

itSDS wrote:

as decribed here it should not be used as global define only at little Subroutines.

The direction taken by the NextGen compiler is so controversial that I would not take this document as reference for the future.
Marco did already change a little its POV about immutable strings: in this pdf, the strings are said to be eventually immutable, whereas Marco's newer blog articles just wrote there was nothing less eventual than this...

What we want now is to let all our SynCrossPlatform* units compile and work with mobile platforms.
We won't try to make the code follow all ideas of this pdf.
Even FireDAC and the official RTL do not follow the patterns: AFAIK nowhere in the RTL strings are 0 based.

Compatibility with FPC and SMS is of higher priority that the NextGen target.

itSDS · 2014-06-26 09:48:43

Just as Addon concerning 0-Based Indexes:

The XE6 Debugger ignores the 0-Base and shows the Content of e.g. String-Buffers with 1 Based Index

I really don't like that 0-Base feature of Embacadero

Last edited by itSDS (2014-06-26 09:49:26)

martin.suer · 2014-06-27 16:45:08

Hi Arnaud,

with XE6 I needed to add some changes in SynCrossPlatformSpecific.pas and SynCrossPlatformRest.pas to get the sample which I posted in post #40 running successfully !!!! Wohooo !!!!

It successfully retrieved a record from within the iOS-Simulator running on a Mac accessing a mORMot Server running on a different PC.

These are the changes:

In SynCrossPlatformSpecific I did the following:

changed line 324

   result := ThttpBody(TEncoding.UTF8.GetBytes(Text));

changed line 348

   Text := TEncoding.UTF8.GetString(TBytes(Body));

in the empty line 108 I added

   {$ifdef NEXTGEN} type AnsiChar = byte; {$endif}

And in SynCrossPlatformRest I changed the lines 833 and the following ones:

  while i<=length(aValue) do begin
{$ifndef NEXTGEN}
    inc(n);
{$endif}
    c := ord(aValue[i]);
    case c of
    ord('+'):
      utf8[n] := AnsiChar(' ');
    ord('%'): begin
      if i+2<=len then
        utf8[n] := AnsiChar(HexDecode(aValue[i+1],aValue[i+2])) else
        utf8[n] := AnsiChar('?');
      inc(i,2);
    end;
    else if c>127 then
      utf8[n] := AnsiChar('?') else
      utf8[n] := AnsiChar(c);
    end;
    inc(i);
{$ifdef NEXTGEN}
    inc(n);
{$endif}
  end;

Without these changes compilation failed for ios and android target on XE6.

The issues were type conversion errors between array of byte and TBytes . Also the utf8 variable is defined as a byte array for NEXTGEN in your code and in the UrlDecode procedure chars have been assigned to it.

I am wondering how itSDS was able to compile the units for iOS target ?????

Last edited by martin.suer (2014-06-27 18:20:00)

ab · 2014-06-27 17:48:39

Your patch has been included to the trunk.
See http://synopse.info/fossil/info/5467739ed7207b

Thanks a lot for the feedback!

Now we will start to work on client for interface-based services...

mORMot Open Source

#1 2013-05-09 10:17:59

XE4 and FireMonkey

#2 2013-05-09 17:32:39

Re: XE4 and FireMonkey

#3 2013-05-09 19:45:08

Re: XE4 and FireMonkey

#4 2013-05-10 07:21:07

Re: XE4 and FireMonkey

#5 2013-05-10 15:38:04

Re: XE4 and FireMonkey

#6 2013-05-10 20:27:31

Re: XE4 and FireMonkey

#7 2013-05-11 08:13:31

Re: XE4 and FireMonkey

#8 2013-05-11 18:42:59

Re: XE4 and FireMonkey

#9 2013-05-11 20:00:46

Re: XE4 and FireMonkey

#10 2013-05-11 21:18:38

Re: XE4 and FireMonkey

#11 2013-05-12 22:51:46

Re: XE4 and FireMonkey

#12 2013-05-13 07:14:04

Re: XE4 and FireMonkey

#13 2013-05-13 21:18:59

Re: XE4 and FireMonkey

#14 2013-05-14 09:53:40

Re: XE4 and FireMonkey

#15 2013-05-15 08:33:50

Re: XE4 and FireMonkey

#16 2013-05-16 05:33:14

Re: XE4 and FireMonkey

#17 2013-10-24 14:04:31

Re: XE4 and FireMonkey

#18 2013-10-25 04:43:59

Re: XE4 and FireMonkey

#19 2013-10-25 06:50:16

Re: XE4 and FireMonkey

#20 2013-10-28 04:28:35

Re: XE4 and FireMonkey

#21 2013-10-28 09:12:13

Re: XE4 and FireMonkey

#22 2013-10-29 00:19:46

Re: XE4 and FireMonkey

#23 2013-10-29 08:43:00

Re: XE4 and FireMonkey

#24 2013-10-29 09:50:28

Re: XE4 and FireMonkey

#25 2013-10-29 11:06:57

Re: XE4 and FireMonkey

#26 2013-11-06 09:09:32

Re: XE4 and FireMonkey

#27 2013-11-06 12:18:25

Re: XE4 and FireMonkey

#28 2013-11-11 10:51:27

Re: XE4 and FireMonkey

#29 2013-11-11 14:57:00

Re: XE4 and FireMonkey

#30 2013-11-11 16:34:09

Re: XE4 and FireMonkey

#31 2014-05-14 09:13:02

Re: XE4 and FireMonkey

#32 2014-05-14 10:44:28

Re: XE4 and FireMonkey

#33 2014-05-14 13:03:37

Re: XE4 and FireMonkey

#34 2014-06-18 21:40:32

Re: XE4 and FireMonkey

#35 2014-06-18 21:55:35

Re: XE4 and FireMonkey

#36 2014-06-19 07:33:09

Re: XE4 and FireMonkey

#37 2014-06-19 07:46:10

Re: XE4 and FireMonkey

#38 2014-06-19 18:56:00

Re: XE4 and FireMonkey

#39 2014-06-19 20:07:37

Re: XE4 and FireMonkey

#40 2014-06-20 15:09:47