Yaron

However, the above did not fully solve my problem, it would have been better if there was a way to get the IP from within functions that are called by mars in Server.Resources, otherwise I'm not sure how to connect the IP from Server.Ignition to an action in Server.Resources in a multi-threaded environment.

I believe I figured it out, here's how to show a pop-up dialog with the IP address: In "Server.Ignition.pas" CreateEngine, I added : FEngine.OnBeforeHandleRequest := function (AEngine: TMARSEngine; AURL: TMARSURL; ARequest: TWebRequest; AResponse: TWebResponse; var Handled: Boolean ) : Boolean begin Result := True; ShowMessage(ARequest.RemoteIP); end; And also had to add "MARS.Core.URL, Web.HTTPApp" to the "uses" section.

I'm using ISAPI, not Indy for the server-side code, so I can't get the IP the way you suggest. I'm hoping for a more generic approach that will work in all MARS output modes (stand-alone application EXE, ISAPI, etc)

Maybe one of the MVPs knows a way to do this by leveraging the underlying java code? I need the UI to look sleek and a blank white screen transition sorts of gives a clunky vibe.

I am using Rio, doesn't seem to help with my issue.

You should also be aware that disabling hardware acceleration can harshly impact battery usage for your app.

I'm not sure you can really disable hardware acceleration as FMX for Android relies on the GPU canvas which is OpenGL hardware accelerated. But seriously though, OpenGL hardware acceleration has been built into smartphones for well over 5 years, so even old phones have it. Not to mention you would have to use Delphi v10.2 or older to even support versions of Android older than v5 and you won't be able to upload these apps into the app store because they don't support the Android SDK google is requiring to upload new apps to the store (not to mention the 64bit issue).

I also tried having the TWebBrowser visible off-screen by calling "WebBrowser.SetBounds(clientWidth,0,clientWidth,clientHeight)" and then returning it on-screen when the user clicks a button. On windows it works well enough (no white flash) but on Android I still see it flashing white for a split second.

Since I've now reached a point where I must take action, I've done as you suggested, hopefully the process will be speedy.

I'm aware of the beta, but like I wrote above, I would like to avoid wasting an entire work day installing & configuring a beta version of Delphi if the final release is just around the corner. And if it's not just around the corner then my subscription might end and I'll be stuck with a beta version. Like I wrote, no good options for me to plan for when no release information is forthcoming.

Just got word from google that my 32bit project that was in beta would not be approved for the extension, not sure if it was because it was in beta or if I requested the extension too late. It's a shame that Embarcadero couldn't get the extension accepted all the way to the actual release date of v10.3.3. Now I'm stuck between a choice of two bad options: 1. Waste hours installing a beta version. 2. Wait an unknown period of time with the hope that a release will be out soon. All this while the clock is ticking on my subscription and without the ability to release anything for Android.

I eventually created an auto-executing HTML form and used TWebBrowser.LoadFromStrings() to load the HTML and automatically login. I even made the login 'pretty' by having the form hidden and showing a logo with a CSS based "processing" animation. The end result looks smooth & professional.

I'm wondering if there's a release date planned, I hate installing Delphi each time, takes a while to get everything re-configured on a clean install and doing in-place upgrades has been hit & miss for me.

I'm doing something similar and encountered some of the same issues. 1. Since ISAPI is a DLL, did you add "IsMultiThread := True;" to let the memory manager know this DLL is using multiple threads (otherwise you can get random-seeming crashes)? 2. I'm not sure your logging code is thread safe, it might be useful to add a critical section to your log writes. 3. There should be no problem using global read-only variables across threads as long as these variables are not classes that do things in the background. 4. If you're accessing a database, make sure to use connection pooling. 5. Do you get a ~90sec freeze when trying to stop the application pool? Make sure to terminate the ISAPI dll correctly. This is my original thread in which the nice people of this forum helped me identify some of these issues:

I believe I might be able login by using LoadFromStrings() to feed the html form and auto-activating JS to TWebBrowser with the form's action set to my login url, which will bypass the need to actually modify the html content.

I have already written a Delphi ISAPI DLL that hooks into the microsoft IIS server and outputs HTML/JS/CSS. That part is done and working well in all browsers. Now, for convenience I would like to create a separate Android app (using Delphi) that uses the TWebBrowser component to open the web server's URL and automatically log-in by filling in the html form fields (user/pass) and press the "submit" button. With this second part I'm struggling since I don't know how to get to the HTML content displayed by the TWebBrowser component and how to trigger the form's "submit" button.

I'm not sure I understand you, do you mean to write the Android app in ReactNative instead of Delphi? I don't have any experience with ReactNative, that's why I'm trying to use Delphi to simply wrap the html generated by my back-end code in a TWebBrowser component.

The Delphi back-end is already rest-based, but the whole point of using HTML/JS for the front-end is to avoid having to design the UI for each platform (web/desktop/android) and rely on CSS to style the UI for every device without having to deal with device resolution/scale within Delphi code.

You beat me to it, I just found this: https://mathiaspannier.wordpress.com/2016/07/17/how-to-properly-cleanupshutdown-a-delphi-isapi-which-uses-threads/ Which is essentially the same answer, can't close the connection in the finalization section when dealing with ISAPI.

Looks like I'm encountering an IIS issue when using this scheme. In the ISAPI's DLL's finalization code I call "FDManager.Close" and in IIS, when stopping the application pool associated with the DLL it can take ~60 seconds before I can restart the pool, any ideas? This is the error I get: When checking my logs, It doesn't seem to exit cleanly (the debug message that the "DB Closed" does not show up in the log), but there doesn't seem to be an exception, here's the code I use: Try FDManager.Close; Except on E : Exception do {$IFDEF TRACEDEBUG}AddDebugEntry('Exception disconnecting from DB : '+E.Message){$ENDIF}; End; {$IFDEF TRACEDEBUG}AddDebugEntry('DB Closed');{$ENDIF} When I run the same code locally as an EXE that handles the HTTP requests, there are no issues, any ideas?

Thank you! Took me a bit to understand the mechanics, but with your help I managed to rewrite the code with minimal changes and so far it's working. P.S. "FDManager.Active :=True;" no longer works in Delphi 10.3, it simply doesn't exist anymore, but "FDManager.Open" seems to be the replacement.

Does that mean that for every http request (that requires DB access) I have to create a new instance of TFDConnection and then connect to the DB? This is the first time I'm writing an ISAPI dll with DB access and the threading model is not exactly clear to me. My original (perhaps flawed) assumption was that IIS will load additional DLLs in separate threads to handle concurrent http requests. I would like to avoid the 100ms penalty for connecting to the DB on each request, any tips?

It took me hours of research to find the tools & documentation and haven't found any up-to-date text describing a similar process, so I decided to post my findings here in case someone else has the same requirement. I wrote (in Delphi) a simple windows service that runs the FireSQL "nbackup.exe" command line tool to create a DB backup every [x] hours using this command line: "c:\Program Files\Firebird\Firebird_3_0\nbackup.exe" -U SYSDBA -P [password] -B 0 "c:\path\database.FDB" "[output_file]" The windows service keeps [x] number of backup files (erasing old files) and creates a new backup every [y] minutes. Personally, I used 1 full-db backup per hour, covering an entire week (168 files). I then use the open-source SyncThing P2P file sync tool (also running as a windows service) to securely & automatically sync the DB backups with every PC assigned as off-site backup. 100% automated, secure, zero cost.

Not my quote: I basically used it cause that's the example I was able to find in the documentation for exporting the DB. In theory I could have used the windows task scheduler, but I needed more control and I'm using the service to perform other timed DB actions. And I couldn't just call nbackup directly from the task scheduler as I'm erasing old DB files and numbering new backups based on existing backup file names (a running counter in the file name) and some more logic is required for this.

SyncThing has a Linux/Mac/FreeBSD/etc... client, so in theory the off-site backups can be on pretty much any widely used OS.