Marcio

Remy,

Remy,

I did the same process with TNetHTTPClient and it worked without errors.

procedure TForm2.Teste;
var
  MS: TMemoryStream;
begin
  MS      := TMemoryStream.Create;

  MS.Clear;

  NetHTTPClient1.Get('http://admin:seleta77@192.168.73.45:80/cgi-bin/snapshot.cgi?channel=1',
                     MS);

        MS.Position := 0;
        if ( MS.Size > 0 ) then //and ( IdHTTP1.ResponseCode = 200 ) then
        begin
                MS.SaveToFile('C:\temp\TesteCamera\Teste.jpeg');
        end;
  MS.Free;
end;
 

Remy,

I put a log component, and put the result attached, tried all the ways and I was unable to make the connection on the camera.

I collected and collected some parameters of the component events and follows below.

I saw on GIT, that there was an instance of a user about the difficulty of Digest authentication with Idhttp.

If you can help me I will be very grateful for the help

https://github.com/IndySockets/Indy/issues/182

log eventos.txt

log.txt

Remy,

I did it according to your guidance, put true on the authorization and includes the Unit IdAllAuthentications and then tried it with the IdAuthenticationDigest.

And yet when executing get, it returns the http / 1.1 401 unauthorized error

    Request.BasicAuthentication := true;

in the rest of the code I kept the same, I must still perform some other implementation

I'm connecting to an IP camera to capture the image but an error occurs that I can't solve.

My code

function TForm2.fGetImagem(pUsuario, pSenha, pUrl : string ; out  pImagem : TJPEGImage ) :Boolean;
var
  MS: TMemoryStream;
  IdHTTP1 : TIdHTTP;
  I       : Integer;

begin
  I  := 0;
  MS := TMemoryStream.Create;
  IdHTTP1 := TIdHTTP.Create(nil);
  With IdHTTP1 do
  begin
    ReadTimeout      := 15000;
    Request.BasicAuthentication := False;
    Request.Username := pUsuario;
    Request.Password := pSenha;
    Request.UserAgent := 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36';
    HTTPOptions := [hoInProcessAuth, hoForceEncodeParams];

  end;

  try
    while (IdHTTP1.ResponseCode <> 200) AND (I < 2 ) do
      try
        MS.Clear;

        IdHTTP1.Get(pUrl, MS);

        MS.Position := 0;
        if ( MS.Size > 0 ) and ( IdHTTP1.ResponseCode = 200 ) then
        begin
          pImagem.LoadFromStream(MS);
          pImagem.CompressionQuality := 40;
          pImagem.Scale              := jsHalf;
          pImagem.Compress;
          Break;
        end;
        I := I + 1;
      except
        On E: Exception do
        begin
            ShowMessage(E.Message+IdHTTP1.ResponseText );
          I := I + 1;
          IdHTTP1.Disconnect;
        end;
      end;
  finally
    if IdHTTP1.ResponseCode = 200 then
      Result := True
    else
      Result := False;

    //Limpa variaveis
    MS.Free;
    IdHTTP1.Disconnect;
    IdHTTP1.Free;
  end;

end;
 

Error http/1.1 401 unauthorized

And I get headers in my connection :
Connection: close
Content-Length: 0
WWW-Authenticate: Digest realm="Login to 65B90F5B97C45465", qop="auth", 
nonce="44eedea6-bf2d-4d70-870a-14277bf1e02d", opaque=""

In the camera material you have this information, but I did not understand how to return it if you receive the 401 error

Video products support either basic authentication or digest authentication, see RFC 2617 for detail. If the http request sent by client does not provide valid "Authorization" header information, video products would return HTTP status code 401 and some information for authentication, then client should calculate authentication information according RFC 2617, and sent request again with authentication information using “Authorization” header. Video products return the required resource only if authorization information correct.

For example:

1. When basic authentication fails, response is:

HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="XXXXXX"

The client encodes the username and password with base64, and then sends it to server. A valid Authorization like this:

Authorization: Basic VXZVXZ

2. When digest authentication fails, response is:

HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="DH_00408CA5EA04", nonce="000562fdY631973ef04f77a3ede7c1832ff48720ef95ad", stale=FALSE, qop="auth"

The client calculates the digest authorization using information like username, password, nonce, HTTP method and URI with MD5, and then sends it to server.

For example:

Authorization: Digest username="admin", realm="DH_00408CA5EA04", nc=00000001, cnonce="0a4f113b", qop="auth", nonce="000562fdY631973ef04f77a3ede7c1832ff48720ef95ad", uri="/cgi-bin/magicBox.cgi?action=getLanguageCaps", response="65002de02df697e946b750590b44f8bf"

In my opinion, this is an unnecessary concern.

When opening a project if it is not compatible with the current version of Delphi the migration already takes place, including you can parameterize the behavior in the Settings menu, whichever happens we have to treat it as a bug.

Adjustments and optimizations may actually be needed as the environment evolves, but this can and the best tool for this is the RAD itself.

As for project settings, when I have to do something more radical, I simply delete the .dproj file, and open the .DPR file, so Delphi recreates the default settings and I can adjust again.

Hello,

Right-click the Libraries menu, and then click Revert to Default.

Delphi already deletes the old ones and loads the new libraries.

https://community.idera.com/developer-tools/b/blog/posts/august-2019-delphi-android-beta-plans-august-roadmap-update

As a follow-up to our 10.3.2 release that introduced macOS 64-bit support for Delphi, C++17 for Windows 64-bit, new RAD Server tooling, key quality enhancements (addressing 400 customer requests) and more, we are planning a 10.3.3 release, with Delphi Android 64-bit being the key new platform feature.

We received many requests for Android 64-bit from our customers and a 10.3.3 release allows us to deliver this speedily and with full compatibility with apps and code developed in 10.3.2.

Given there is no significant change to the Delphi language and the underlying memory management model in 10.3.3, our customers should be able to migrate their applications to Android 64-bit faster. The same is likely true for component vendors. While we still plan to transition the Delphi language for mobile, removing ARC memory management, this will happen at a later time.

As 10.3.2 adoption is high, upgrading to 10.3.3 should be a faster option than migrating applications to 10.4. 10.3.3 will also include additional features and quality improvements to make 10.3.3 one of RAD Studio’s best versions.

Please keep in mind that the Google Play Store extension for our Delphi and C++Builder customers is in effect for existing 32-bit applications. This allows our customers to provide updates to existing applications in the Google Play Store applications until August 2020, but only after an extension has been granted. 10.3.3 will remove this limitation for Delphi by including complete support for Android 64-bit apps.

We’re planning on kicking off an NDA Beta for the 10.3.3 release, codenamed Sugarloaf, later this month. All customers on Update Subscription will be invited to participate in the Beta and will be able to start migrating their applications even earlier with Beta versions, which will include a specific Beta EULA waiver permitting Google Play Store deployment.

Here’s what’s planned for 10.3.3:

Platform Enhancements

• iOS 13 & macOS Catalina Support 
• RAD Server Deployment with Docker 

C++

• Expand C++ libraries support

Delphi

• Android 64-bit platform support

User Experience

• Further IDE UI/UX Improvements
• New Downloads/Licensing Portal 

Quality Focus Areas 

• App Tethering for VCL and FMX
• IDE Quality 
• C++ Toolchain performance and quality improvements

With the addition of 10.3.3 this fall, we’re now planning the 10.4 release for early in 2020. As outlined in our May 2019 PM roadmap commentary blog post, 10.4 is going to focus on improved code tooling, language enhancements, VCL High DPI styles, RAD Server enhancements, FireMonkey features and quality and more. 

On 2/7/2019 at 12:38 PM, Hans♫ said:

I investigated all recent crash reports delivered to XCode for the app. The majority of the crashes contains a reference to a sqlite file in our app and "Code 0xdead10cc", which means "terminated by the OS because it held on to a file lock or sqlite database lock during suspension"

 

The positive news is that the user will not discover the crash because it happens when it enters suspension state anyway.

 

In this crash you reported on blocking sqlite, you tried to disconnect from the base when the application enters IDLE mode, and perform the connection again, because as the base is leased exclusively, the system probably has to maintain resources for this, it might be a way to save battery power, I'm not an IOS expert, but I'm just interpreting the message.

Marcio

2 hours ago, Dmitry Arefiev said:

The patch and instruction is published there:

https://quality.embarcadero.com/browse/RSP-23656

Thank you Dmitry!

Thank you Dave!

I made the changes indicated in the patch and it worked perfectly!

10 hours ago, Dave Nottage said:

I referred to the callstack, not the actual code. The Callstack window is the one in the very top left of your first picture. It's possible to copy/paste what is inside that window.

Dave,

In moment of error CallStack

The result this function is   TFDJSONDataSets 

 LDataSetList:=  ClientModule1.ServerMethodsClient.GetDatabase('1','1234',vErros, 1670, '','');
 

The TFDJSONDataSets is returned by the DataSnap Rest, but when it receives this return for appllication and will convert is that the error occurs

System._DbgExcNotify(-1634508784,0x9b16e5a8,0x9c6b1159,0x9b16e5a8,0x9c6b1159)
System.NotifyReRaise(0x9b16e5a8,0x9c6b1159)
System._RaiseAtExcept(0x9b16e5a8,0x9c6b1159)
System._RaiseExcept(0x9b16e5a8)
System.Internal.Excutils.DoRaiseJNIExceptionCallBack('class java.lang.IllegalStateException','java.lang.IllegalStateException: Cannot set request property after connection is made')
Androidapi.Jni.HandleJNIException(0xb30b95a0)
Androidapi.Jnimarshal.ExecJNI(0x9e9364c0,0x9b777c08)
:9D237614 DispatchToImport
:9D25B930 dispatch_first_stage_intercept
System.Net.Httpclient.Android.TAndroidHTTPClient.DoExecuteRequest(0xae4a3240,0x9984c900,@0x9e9367e8: 0xb30b9480,0x9980f5e0)
System.Net.Httpclient.THTTPClient.ExecuteHTTPInternal(0xae4a3240,0x9984c97c,0x9980f5e0,0xb30b94cc)
System.Net.Httpclient.THTTPClient_ExecuteHTTP_ActRec._0_Body(0x998cd080)
:9D117836 __stub_in36s__ZN6System3Net10Httpclient30THTTPClient_ExecuteHTTP_ActRec7_0_BodyEv
System.Classes.TAnonymousThread.Execute(0x99888768)
System.Classes.ThreadProc(0x99888768)
System.ThreadWrapper(0xae595e18)
:B6CE5E34 __pthread_start(void*)
:B6CC056C __start_thread
:00000000 ??

43 minutes ago, Dave Nottage said:

When the crash occurs as per your first image, can you click "Break", so that the callstack shows, please? Then present here what the callstack actually shows (preferably paste the text, rather than a picture)

Dave,

Only Android , win32 work fine, and 10.3 work fine too.

unit System.Internal.ExcUtils;

line 839

{$IFDEF ANDROID}
procedure DoRaiseJNIExceptionCallBack(const JNIExceptionClassName: string; const Msg: string);
begin
  raise EJNIException.CreateWithClassName(JNIExceptionClassName, Msg);
end;
{$ENDIF}
 

I have an android application that synchronizes data with a DataSnap server, did the tests with version 10.3 and had no problems with win32.

I updated to version 10.3.1 and when calling the function, the java.lang.illegalStateException error occurs, as per the attachment.

In win32 the error does not occur and it works perfectly, does anyone know what it can be?

I was debugging until the moment where the error occurs, see the last image..

Thank you

Hi, 

I use livebinding to popular Listview.

I have a listview application with dynamic items, which is connected to a fdmemtable,

when clicking repeatedly on any item in the listview, the application closes.

If you put the listview without the dynamic items, and clicking several times this does not occur I'm using delphi 10.2.3 works ok, but in delphi 10.3 comunity, the error occurs, with android 8.0.1

Has anyone had this problem ?

I have an application that uses DBExpress, Query, Provider and ClientDataset.

I will migrate to Firedac, currently all query and provider are in the DataModule and in form only the ClientDataSet and DataSet.

What is the best scenario, advantages and disadvantages :

1 - Leave the Query in the DataModule and in the Form only the DataSet.
2 - Place Query on Form and use DataModule only for Global Objects.

Has anyone used the refind for conversion?

Thanks