#51 2014-07-21 01:20:29

ubaltino
Member
From: Brasil
Registered: 2014-05-23
Posts: 24
Website

Re: XE4 and FireMonkey

I need a practical example of a Client for FireMonkey (iOS and Android).

I think many are perhaps awaiting Exmplo 30. If someone could, could post it for us.

Thank you.


Ubaltino Faleiro
www.sistemainteligente.com
Brasil - Goiás - Goiânia

Offline

#52 2014-08-07 23:04:13

Sabbiolina
Member
Registered: 2014-05-20
Posts: 120

Re: XE4 and FireMonkey

Hi AB.

what is the right way to call a service-based interface as in example 14 from android application?

In crossplatform missing TSQLClientHTTP then:
  Client.ServiceRegister ([TypeInfo (ICalculator)], sicShared);

can not be translated.

You must use CallBackGet? but how?

Thank you

Offline

#53 2014-08-08 05:36:52

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: XE4 and FireMonkey

You have to generate the unit from server.

We will write the doc today.
:-)

Offline

#54 2014-08-08 09:07:04

Sabbiolina
Member
Registered: 2014-05-20
Posts: 120

Re: XE4 and FireMonkey

I found a conversion problem in SynCrossPlatformREST using FireMonkey on android.

I manually entered a very large ID 2147483647 + 1 ($ 7FFFFFFF + 1)

and I noticed that TSQLRecord.Fid as integer can not convert it.

I modified the code using int64 and the problem is gone.

  TSQLRecord = class(TPersistent)
  protected
    fID: int64;
    fInternalState: cardinal;

    fFill: TSQLTableJSON;
    {$ifdef ISSMS}
    class function GetRTTI: TRTTIPropInfos;
    /// you should override these methods
    class function ComputeRTTI: TRTTIPropInfos; virtual;
    procedure SetProperty(FieldIndex: integer; const Value: variant); virtual;
    function GetProperty(FieldIndex: integer): variant; virtual;
    {$endif}
  public
    /// this constructor initializes the record
    constructor Create; overload; virtual;
    /// this constructor loads a record from a REST instance from its ID
    constructor Create(aClient: TSQLRest; aID: integer;
      ForUpdate: boolean=false); overload;
    /// this constructor loads a record from a REST instance
    // - you can bind parameters by using ? in the SQLWhere clause
    // - FieldNames='' retrieve simple fields, '*' all fields, or as specified
    constructor Create(aClient: TSQLRest; const FieldNames, SQLWhere: string;
      const BoundsSQLWhere: array of const); overload;
    /// this constructor ask the server for a list of matching records
    // - you can bind parameters by using ? in the SQLWhere clause
    // - FieldNames='' retrieve simple fields, '*' all fields, or as specified
    // - then you can also loop through all rows with
    // ! while Rec.FillOne do
    // !   dosomethingwith(Rec);
    constructor CreateAndFillPrepare(aClient: TSQLRest; const FieldNames,
      SQLWhere: string; const BoundsSQLWhere: array of const);
    /// finalize the record memory
    destructor Destroy; override;
    /// fill the specified record from the supplied JSON
    function FromJSON(const aJSON: string): boolean;
    {$ifdef ISSMS}
    /// fill the specified record from Names/Values pairs
    function FromNamesValues(const Names: TStrArray; const Values: TVariantDynArray;
      ValuesStartIndex: integer): boolean;
    {$endif}
    /// fill all published properties of this object with the next available
    // row of data, as returned by CreateAndFillPrepare() constructor
    function FillOne: boolean;
    /// go to the first data row, as returned by CreateAndFillPrepare(),
    // then fill all published properties of this object
    // - you can use it e.g. as:
    // ! while Rec.FillOne do
    // !   dosomethingwith(Rec);
    // ! if Rec.FillRewind then
    // ! repeat
    // !   dosomeotherthingwith(Rec);
    // ! until not Rec.FillOne;
    function FillRewind: boolean;
    /// get the object properties as JSON
    // - FieldNames='' to retrieve simple fields, '*' all fields, or as specified
    function ToJSON(aModel: TSQLModel; aFieldNames: string=''): string;
    /// return the class type of this TSQLRecord
    function RecordClass: TSQLRecordClass;
      {$ifdef HASINLINE}inline;{$endif}
    /// contains the TSQLTableJSON instance after CreateAndFillPrepare()
    property FillTable: TSQLTableJSON read fFill;
    /// internal state counter of the mORMot server at last access time
    // - can be used to check if retrieved data may be out of date
    property InternalState: cardinal read fInternalState;
  published
    /// stores the record's primary key
    property ID: int64 read fID write fID;
  end;

What do you think of this correction?

Offline

#55 2014-08-08 10:08:33

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: XE4 and FireMonkey

ID should be a 32 bit integer, since it should map the pointer size.
(even if SQLite3 by itself allows 64 bit IDs)
We typecast IDs to pointers (i.e. TSQLRecord) for one-to-many relationship.

Our ORM would never create such a large ID.
So I do not think there is any issue here.

Offline

#56 2015-05-22 10:01:35

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: XE4 and FireMonkey

Update: the IDs are now defined as TID = Int64 in newer version of the framework.

Hope it would help.

Offline

#57 2016-04-25 07:21:37

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: XE4 and FireMonkey

Some updates about NextGen, after a few years and Delphi releases.

1. Strings are not immutable yet.
And the potential future change, even if still documented, does not appear on the roadmap.
My guess is that it is in fact not likely to happen (soon).

2. RawByteString and UTF8String have been re-introduced in NextGen, with Delphi 10.1 Berlin of April 2016.
See http://synopse.info/forum/viewtopic.php?id=3280
Not all AnsiString(codepage) type, just UTF-8 and RawByteString.

Worth noting the Embarcadero moves, in the direction we expected.
Even if our position was not take in account at first, they have gone back to a more practical move.
Backward compatibility is IMHO to be preserved as much as possible.

If only they did not embrace the ARC memory model, and force it for NextGen...
I just hope they won't force ARC for the upcoming Linux 64 platform.
This would break a lot backward compatibility with OOP existing code. It would not affect RAD-oriented projects, but would definitively break OOP projects, written as source, with a lot of classes.
See http://blog.synopse.info/post/2016/02/0 … nd-of-2016

Offline

Board footer

Powered by FluxBB