|
<< Click to Display Table of Contents >> State-less and Memory Management |
  
|
|
<< Click to Display Table of Contents >> State-less and Memory Management |
|
NG-ConnectionPack components implements state-less wrappers for corresponding REST services. Components do not store internally any returned data, such as file objects or calendar events.
This implies, that on each request new set of objects will be returned. Most of such objects are really implemented as Delphi records (thanks to Delphi new language features, which allow the records to have properties and methods); so, the memory management is mostly automatic.
For example, to to retrieve root level files from the Dropbox service the following code can be used:
var
files: TArray<TNGCloudFile>;
i: Integer;
begin
files := DropBox.Root.Files;
for i := 0 to High(files) do
Memo1.Lines.Add(files[i].Name);
end;
Since TNGCloudFile is really a record, there no need to perform manual disposing of such objects. The rationale for such design is that usually a lot of objects are exposed via service component methods, and, moreover, a lot of related objects, such as file parent object or folder child objects can be exposed on demand, and are actually related to each other in a tricky way.
Another rationale, is that its possible that we will add some caching capabilities in the next versions of NG-ConnectionPack.
Most of the returned objects are actually active objects, which means that they contains methods, which requires Http request to the corresponding REST service. This implies that the objects internally stores a reference to the corresponding service component. And so, objects are considered valid only while the corresponding service component is not destroyed.
Some properties can still work even after that, but, generally its not correct to use such objects after the service component was destroyed, and so, on method calls which really requires the service, an exception will be raised.
User's authentication is performed on demand, and the access_token can be refreshed transparently to application; so, re-authenticating the user or refreshing access_token does not generally invalidate returned objects. But, its of course, not valid to use object returned from one account after re-authentication using another user's account.