You are not logged in.
Pages: 1
Hi,
this is the concept:
1. Compile a mORMot server with Lazarus into a dynamic library
2. Create an Android "remote service"/"IOS background app" with Delphi using this dynamic library to start/stop/manage the mORMot server
3. Access the server from a FMX app via websockets.
Is this a viable path?
Does using websockets use more energy than using intents to communicate?
Last edited by Leslie7 (2020-06-29 21:22:33)
Offline
You can link a dynamic library (.so) on iOS.
So you need to compile the source as static libray (.o).
But it is a possible path for sure.
WebSockets issue on mobile has no energy problem, but it may have reconnection issues. It is more common to have the network disconnected on a mobile, when you switch from one GSM tower to another.
Also on server side, HTTPS will use less resource - especially with a nginx as reserve-proxy. Currently, our WebSockets server consumes one thread per connected client, whereas our HTTP server is able to use a thread pool.
So I guess using regular HTTPS may be a better option.
Online
Hi,
this is the concept:
1. Compile a mORMot server with Lazarus into a dynamic library
2. Create an Android "remote service"/"IOS background app" with Delphi using this dynamic library to start/stop/manage the mORMot server
3. Access the server from a FMX app via websockets.Is this a viable path?
Does using websockets use more energy than using intents to communicate?
He asked if is a viable option to connect locally on mobile device to mORMot server? FMX is the client and mORMot Android/iOS background app is the server.
I'm also interested in the same approach, because we can get sqlite encrypted access on mobile, plus MORE IMPORTANT: real unified code between mobile, desktop, server - and only the GUI differs.
Offline
EMK, encryption an unified data handling are the main driving factor for me too. Potentially being able to access the same server remotely can be a benefit for support as well.
Using Android Studio to create the service might be better option because with Delphi even the service without GUI seems to consume lots of memory.
Creating the IOS background app with Lazarus instead of Delphi might be an option as well.
Last edited by Leslie7 (2020-07-03 09:22:06)
Offline
You can link a dynamic library (.so) on iOS.
So you need to compile the source as static libray (.o).
But it is a possible path for sure.WebSockets issue on mobile has no energy problem, but it may have reconnection issues. It is more common to have the network disconnected on a mobile, when you switch from one GSM tower to another.
Also on server side, HTTPS will use less resource - especially with a nginx as reserve-proxy. Currently, our WebSockets server consumes one thread per connected client, whereas our HTTP server is able to use a thread pool.
So I guess using regular HTTPS may be a better option.
Good to hear.
The goal is to have a local server on the mobile device. HTTP or HTTPS is better for this?
I would assume that local connections should not be effected by switching GSM tower. Maybe the device going to sleep mode and coming back needs to be handled.
Offline
A local connection on the mobile device? Weird...
I don't understand how it may work reliably, since even background Services could be shutdown at any time by the mobile OS, to save power.
If you embed the mORMot server as a .o static library, then you can call it in-process directly.
Online
Now I understand where you are coming from. Sounds like a good solution.
I need to figure out how to reference and link the .o files with Delphi.
In theory having a local server makes sense in some cases. EG when more than one app is using it. Also the server has tags telling the OS to keep it in memory as much as possible. The UI app will be removed before the server. The result is that at least half of the app has a chance to survive in memory --> faster reload.
If there is fast and reliable way for the UI app to check if the server is running and to start it if not then it might even work.
Offline
I need to figure out how to reference and link the .o files with Delphi.
I am not really finding anything useful about this by googling.
Offline
Pages: 1