Cannot detect unable to connect in Android or IOS

[mthand]

I have a small app which calls a webservice in our desktop app, which runs a server.
I have an FM mobile app which works fine when the server is available.  It sucessfully connects and calls either of two small XMLRPC webservices.

If I shut down the server, though, the mobile versions hang trying to connect.

If I build to a  Win32 , it sucessfully handles the failure to connect.
But If I build to either Android or IOS, it hangs.  I never get the OnConnect.

I traced the hang to rtcSockBaseSyn, and it hangs in this procedure :


 TRtcSocketBaseSyn.MsgLeave;

Seems to be looping.  There is an IFDEF in there about NEXTGEN which is probably the issue.
I don't know what that means, though.

Blocking is true, multithreading is false.
I'm using the V628 2013Q4 version of RTC.

Hopefully there is a simple setting to handle this ?

[D.Tkalcec (RTC)]

TRtcSocketBaseSyn.MsgLeave has to be looping for as long as the component is in use, because that is the main loop for the blocking socket implementation, responsible for all socket operations. The fact that this method is looping only means that the components are doing something. The question is: What messages are being processed in that loop and what causes the loop to continue after a failure to connect.

Since this is a simple App, can you post a complete list of all RTC components you are using with all the properties you have set up, together with a list of events which you have implemented on them?

That might shed some light on the topic.

Btw ... the only difference between NEXTGEN and "oldgen" compiler is that the NEXTGEN version doesn't call FREE after executing the loop, because the NEXTGEN compiler has auto-reference counting, which automatically frees the object. Other than that, there is no difference between NEXTGEN and "oldgen" compilation. If all your App versions use Blocking=True and MultiThreaded=False, they should all behave the same, because RTC uses the same implementation in that case. The only real difference will be in the low-level API. Windows uses blocking WinSock, all other platforms use blocking BSD sockets.

Best Regards,
Danijel Tkalcec

[mthand]

Thanks for the quick response.
I will put together the project for you.

I might be able to put the server on a public accessable location so you can replicate exactly.
I'll send the stuff hopefully with an hour.

[D.Tkalcec (RTC)]

You don't have to bother making the Server accessible over the internet. Since your problem is happening only when the Server is inaccessible, I just need to know how you are using the components.

Best Regards,
Danijel Tkalcec

[mthand]

OK. I did already make the server accessible before your note, so this zip is a complete working program if that helps.


https://www.dropbox.com/s/jkfjn2po8mtnn83/RTCfm1.zip

When built under Win32, clicking the "isThere" button properly catches the failed connection.
When built for either Android or IOS, it all hangs and never connects.


Please don't laugh too hard when you look at the source 

[D.Tkalcec (RTC)]

Ok. I will take a look at the Project and get back to you.

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

First thing I've noticesd is that you are using the Execute method on the TRtcClientModule component, which requires that the rtcFMX.GUI unit is used somewhere in your project when compiling it for non-Windows platforms, but you aren't using that unit anywhere.

See this FAQ Topic.

I can't test your Project in Delphi XE5, because every time I try to look at the form, a message box popus up warning me that there is no disk in drive "\Device\Harddisk2\DR6". I guess some component on your Form is trying to access a file for which you have entered a full path somewhere on your local drive and the Delphi IDE is too dumb to throw a single exception, but keeps on showing that dialog over and over again, making it impossible for me to do anything else than kill the IDE. I'm trying to find out where that path is being used, so I can get the project to open and compile.

Best Regards,
Danijel Tkalcec

[mthand]

Thanks !

the FMXGUI was the issue.

I remember seeing that mentioned somewhere, I should have paid closer attention to the documentation.

I really appreciate your help with this.  We're trying to interface with an older D7 app that does XMLRPC (no datasnap or anything like that)  and RTC has been our best solution so far.

thanks again !

[D.Tkalcec (RTC)]

I don't use the Execute nor WaitForCompletion methods in my Applications, so I forget about that unit when someone reports a problem with their Android and iOS Apps. Funny thing is that every time someone has a problem on Android or iOS, the reason was in fact that they were using the Execute or WaitForCompletion method, but didn't use the rtcFMX.GUI unit.

I've made the above FAQ topic sticky now.

Best Regards,
Danijel Tkalcec