You are not logged in.
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
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
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
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
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