Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-04

Android native application with local webserver

8 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

Hello
I finish first stage to move my webapp as native Android application. Its consists one java file with declaration webWiew, and all rest, written in FPC, is build as library. Of course start is thought jni, but after that http server (based on Synapse) is started, and build in browser can play with them.

If someone is interesting: attached patch consist changes to enable pthreads and dynamic linking working on Android

Darek

Reply by email

Michael Schnell
to Unknown author
Show quoted text 6 lines
Hello I finish first stage to move my webapp as native Android application. Its consists one java file with declaration webWiew, and all rest, written in FPC, is build as library. Of course start is thought jni, but after that http server (based on Synapse) is started, and build in browser can play with them.

Sounds great.

So your way to overcome the native-code <-> user interface barrier on Android is to make the apllication a web server and access it via the browser ?

I understand the executable has a built-in web server, so it is _not_ a CGI. Correct ?

Did you already succeed in managing the usual obstacles of this: creating timers, notifying the main thread from worker threads, doing application initiated "active" user notifications on the web-page ?

Thanks a lot !
-Michael

Reply by email

Dariusz Mazur
to Michael Schnell

W dniu 2011-04-14 09:38, Michael Schnell pisze:

Show quoted text 15 lines
On 04/13/2011 11:11 PM, wrote: > Hello > I finish first stage to move my webapp as native Android application. > Its consists one java file with declaration webWiew, and all rest, > written > in FPC, is build as library. Of course start is thought jni, but after > that http server (based on Synapse) is started, and build in browser can > play with them. Sounds great. So your way to overcome the native-code <-> user interface barrier on Android is to make the apllication a web server and access it via the browser ?

yes,
this is the same application as for linux or windows

I understand the executable has a built-in web server, so it is _not_ a CGI. Correct ?

yes

Did you already succeed in managing the usual obstacles of this: creating timers,

yes

notifying the main thread from worker threads,

yes

doing application initiated "active" user notifications on the web-page ?

I'm not sure I understand
when I need this, web page (by Javascript) sequentially ask server

Darek

Reply by email

Michael Schnell
to Dariusz Mazur
Dariusz Mazur wrote
> Did you already succeed in managing the usual obstacles of this: > creating timers, yes

Great ! How ?

> notifying the main thread from worker threads, yes

Great ! How ?

Show quoted text 5 lines
> doing application initiated "active" user notifications on the > web-page ? > I'm not sure I understand when I need this, web page (by Javascript) sequentially ask server

This is what I meant. So you do polling in the Java script, killing the performance of the whole device. There are Java script based algorithms (such as "Comet") that might or might not help and might or might not introduce additional problems.

-Michael

Reply by email

Dariusz Mazur
to Michael Schnell

W dniu 2011-04-14 11:35, Michael Schnell pisze:

Show quoted text 6 lines
On 04/14/2011 10:36 AM, Dariusz Mazur wrote: > >> Did you already succeed in managing the usual obstacles of this: >> creating timers, > yes Great ! How ?

What is the problem when pthreads works?

>> notifying the main thread from worker threads, > yes Great ! How ?

server work in own thread, each request in own, each session (whole application for one user) in own
communication between request thread and session threads are done via FIFO queue

my old demo webapp
http://www.emadar.com/fpc/xwebdemo.zip

Show quoted text 9 lines
>> doing application initiated "active" user notifications on the >> web-page ? >> > I'm not sure I understand > when I need this, web page (by Javascript) sequentially ask server This is what I meant. So you do polling in the Java script, killing the performance of the whole device. There are Java script based algorithms (such as "Comet") that might or might not help and might or might not introduce additional problems.

I don't think so
But when browser send request, server don't response at now, only wait 30s and then (if its nothing to respond) send message to browser with order to repeat request.

Darek

Reply by email

Michael Schnell
to Dariusz Mazur
Dariusz Mazur wrote
What is the problem when pthreads works?

In fact this supposedly is a Lazarus LCL problem, so we might be in the wrong discussion group here,

The LCL's "Application" object defines a main thread, that allows for "event driven programing" (the program flow stalls after the initialization using (close to) 0% CPU and e. g. TTimers fire "main thread events" that are queued in an "Event Queue" and handled one after the other as soon as possible when the time of one has come (waking up the main thread at this point).

Now the LCL provides the code that does this in (some of) its "Widget Type"- (aka "interface"-) implementations. There are several of those, but only those with a GUI binding do provide event driven programming. (Otherwise you could use a "noGUI" one for doing a kind of "WebGUI").

To allow for decent thread programming in an environment with event driven programming, the threads need to be able to notify the (event driven) main thread by firing queue-able main-Thread events. This can be done by stuff like "TThread.Synchronize" (defined in the RTL, but needs the help of the LCL <or whatever> ), "TThread.Queue" (not yet implemented, but available in Delphi), "Application.QueueAsychCall" (implemented in the LCL), and PostMessage (Windowish stuff, but quite decently cross-platform - implemented in the LCL).

server work in own thread, each request in own, each session (whole application for one user) in own communication between request thread and session threads are done via FIFO queue

So the "Server" is the "Main Thread", which is supposed to do most of the "Office Logic" work, including handling the TTimer events. IMHO, it's not a good idea top do the Office Logic stuff directly in the threads that are fired by the single requests, as this will ask for huge problems with mutual access of commonly used data, which the user does not really want to handle with a great count of CriticalSections or similar synchronization stuff. I feel that it would be good to have the "requests" transformed to "main Thread Events", so that a "normal" (= not thread aware) user is able to do the programming seeing only a single thread.

Show quoted text 5 lines
I don't think so But when browser send request, server don't response at now, only wait 30s and then (if its nothing to respond) send message to browser with order to repeat request.

OK. If the program works only on request and the java code does a long sleep, the CPU use will be decently low. But of course this will not provide a very agile experience to the user.

Thanks a lot for making this work !

-Michael

Reply by email

Dariusz Mazur
to Michael Schnell

W dniu 2011-04-14 16:08, Michael Schnell pisze:

Show quoted text 25 lines
On 04/14/2011 02:55 PM, Dariusz Mazur wrote: > What is the problem when pthreads works? In fact this supposedly is a Lazarus LCL problem, so we might be in the wrong discussion group here, The LCL's "Application" object defines a main thread, that allows for "event driven programing" (the program flow stalls after the initialization using (close to) 0% CPU and e. g. TTimers fire "main thread events" that are queued in an "Event Queue" and handled one after the other as soon as possible when the time of one has come (waking up the main thread at this point). Now the LCL provides the code that does this in (some of) its "Widget Type"- (aka "interface"-) implementations. There are several of those, but only those with a GUI binding do provide event driven programming. (Otherwise you could use a "noGUI" one for doing a kind of "WebGUI"). To allow for decent thread programming in an environment with event driven programming, the threads need to be able to notify the (event driven) main thread by firing queue-able main-Thread events. This can be done by stuff like "TThread.Synchronize" (defined in the RTL, but needs the help of the LCL <or whatever> ), "TThread.Queue" (not yet implemented, but available in Delphi), "Application.QueueAsychCall" (implemented in the LCL), and PostMessage (Windowish stuff, but quite decently cross-platform - implemented in the LCL).

I've implement message queue (like in Windows), also VCL/LCL style communication with widgets. TThread.synchronize was reimplement, because there is many "Main thread" - per each session. All enough to use the same source do build desktop and web application.

Show quoted text 6 lines
> server work in own thread, each request in own, each session (whole > application for one user) in own > communication between request thread and session threads are done via > FIFO queue So the "Server" is the "Main Thread",

No , I mean this is main thread of listen socket

which is supposed to do most of the "Office Logic" work,

"office logic" and changes in used widgets (controls) is done in session thread, and when computing if finished, request thread prepare response, based on new state of "visible" widgets, there are mutexes, to coordinate flow between this two threads.

Show quoted text 9 lines
including handling the TTimer events. IMHO, it's not a good idea top do the Office Logic stuff directly in the threads that are fired by the single requests, as this will ask for huge problems with mutual access of commonly used data, which the user does not really want to handle with a great count of CriticalSections or similar synchronization stuff. I feel that it would be good to have the "requests" transformed to "main Thread Events", so that a "normal" (= not thread aware) user is able to do the programming seeing only a single thread.

In my attempt single session (like desktop application) work in own thread. In session can be use inner threads, events, modal windows etc. similar like in desktop.

Show quoted text 8 lines
> > I don't think so > But when browser send request, server don't response at now, only > wait 30s and then (if its nothing to respond) send message to browser > with order to repeat request. OK. If the program works only on request and the java code does a long sleep, the CPU use will be decently low. But of course this will not provide a very agile experience to the user.

Why. When server want to push to browser response earlier (response took less than 200ms including ping), when browser (user) want ask, then send new request, no one wait

Darek

Reply by email

Michael Schnell
to Dariusz Mazur
Dariusz Mazur wrote
I've implement message queue (like in Windows), also VCL/LCL style communication with widgets. TThread.synchronize was reimplement, because there is many "Main thread" - per each session. All enough to use the same source do build desktop and web application.

GREAT !!
Would it not make sense to make this a new LCL "Widget Set" ?

Show quoted text 6 lines
>> server work in own thread, each request in own, each session (whole >> application for one user) in own >> communication between request thread and session threads are done >> via FIFO queue > So the "Server" is the "Main Thread", No , I mean this is main thread of listen socket

Sorry I can't follow you here :-( .

Show quoted text 5 lines
> which is supposed to do most of the "Office Logic" work, "office logic" and changes in used widgets (controls) is done in session thread, and when computing if finished, request thread prepare response, based on new state of "visible" widgets, there are mutexes, to coordinate flow between this two threads.

Is this invisible to the application programmer, so that (s)he sees just one thread with no need to synchronization ?

Show quoted text 12 lines
> including handling the TTimer events. IMHO, it's not a good idea top > do the Office Logic stuff directly in the threads that are fired by > the single requests, as this will ask for huge problems with mutual > access of commonly used data, which the user does not really want to > handle with a great count of CriticalSections or similar > synchronization stuff. I feel that it would be good to have the > "requests" transformed to "main Thread Events", so that a "normal" (= > not thread aware) user is able to do the programming seeing only a > single thread. In my attempt single session (like desktop application) work in own thread. In session can be use inner threads, events, modal windows etc. similar like in desktop.

Sorry I can't follow you here :-( .

Show quoted text 10 lines
>> I don't think so >> But when browser send request, server don't response at now, only >> wait 30s and then (if its nothing to respond) send message to >> browser with order to repeat request. > OK. If the program works only on request and the java code does a > long sleep, the CPU use will be decently low. But of course this will > not provide a very agile experience to the user. Why. When server want to push to browser response earlier (response took less than 200ms including ping), when browser (user) want ask, then send new request, no one wait

Sorry I can't follow you here :-( . (Julian, can you help ?)

-Michael

Reply by email