B4A Library B4A Welcomes SSE

so, there's something called server side events (SSE).
it apparently has something to do with notifications
from a web server to a browser. i'm guessing it's what
happens when you see an annoying pop-up message
from a web server asking persmission to send you
notifications. good luck with that; not!

i noticed a thread earlier in the week relating to
server side events (SSE), but for b4j.

anyway, the thing is: mirabile dictu! it works with okhttputils2.
that is, it doesn't interfere with okhttputils2 (at least not that
i have seen); you can do your normal okhttputils2 business
at 1 url while still receiving notifications from a totally
different url. wait, what? for example, if you had a website
that sent periodic world cup updates as notifications, you could
receive them while downloading jpg's or updating your mysql
database on another url. win-win, right?

so, for what it's worth, i put it out there. i tested it with a
website that allows test sse connections. it sends notifications
out every few seconds. i capture in an event, so i have
them flashing in a text label. while that's going on, i can download
some other files and post some database updates using the
same, declared okhttputils2 client. or so it seemed to me.

you can turn off the notifications when you want without
affecting your current okhttpclient (in fact you MUST turn them off
when you exit your app). i haven't implemented a turn-back-on button.
the library is mostly a proof of concept at this point, but i leave it up
your vivid imaginations to see how it might be used, if at all.

in addition to the library and its .xml file, you need to copy an attached
okhttp-sse-related jar to your additional libraries folder. technical point:
the jar's version is 4.9.3. it uses the standard okhttp3 jar of the same vintage.
we have a slightly older okhttp3 jar in our b4a libraries folder, but the
library seems to work ok with it. so i went with what we have.

take a look at the attached image to see about setting things up and the
notifications i received.

you need to start the okhttpservice module first (normally, it is not started until you
perform your first okhttp download or post. in this case, you need to start it early on.
initialize the gsse library and tell it the url of the web server providing the updates.

at that point, you don't have to do anything else. notifications should start hitting the
gotEvent sub. do with the notification what you will.

if you want to carry out some other okhttp routine, do it as normal.

note: for whatever reason on my pixel 3a, there was a noticeable lag between the
time i started the okhttputils2 service and when it was actually up and running. there
is no "wait for" to indicate that the service is running. and if it isn't actually running,
the sse setup will fail. i added a 5 second sleep and then check to see if the
service is active. if it is, i continue with sse. you could try with less time.

initially, i did the whole thing in inline java. then i decided to put it in a library for
people who just want something to plug in.

erel encountered a problem recently regarding okhttp and proxies. his solution
involved his usual magic with javaobject calls. as the solution got more involved,
he added some inline java. the same approach could probably be used for sse.
i chose the way i did it because i was comfortable with it, but it isn't the only way.

 

[drgottjr]

below please find a slightly updated version (0.05) of the gsse library (jar/xml).

the event raised when a notification is received has been changed to
provide a little more information to the caller: a type (as string) and the
notification body (as string). it also raises the event more in accordance
with our conventions: eventname + "_" + plus sub name.

at some point until recently, it seemed like every site i visited
wanted to send me notifications. suddenly, for whatever reason, i can't
find a site that actually sends notifications. so it's difficult to test things.

as with most responses received by okhttputils2, the developer has to
know what is being sent, that is, an expected mime type and, possibly,
a structure of some sort.

the same seems to be true of sse; there is a protocol to follow. the protocol
as implemented by ok was not followed exactly by the 1 site i found to test sse
connections. the site, however, did specifiy that notifications were sent as a json
object. so at least i knew what to look for. it did not, however, specify this in the
actual notification, which - according to ok - is supposed to be specified as a
so-called "type".

if some sites follow the protocol and others don't, it makes things difficult to handle
the notifications smoothly. of course, ok's understanding of the protocol could be
wrong. or, maybe i read the spec wrong.

the way things work is you need to know the url that the site uses for sse.
and you need to know the structure of the data they're pushing. you will
probably have to look at your browser's developer's tab to see what is what.
in other words, you can't point an sse connection at b4x.com or google.com
or yahoo.com and expect notifications. sites sending notifications will use a
dedicated url for that. your browser learns that url when you agree to accept
notifications. that's the url you indicate when initializing the library's sse connection.

last, this technology may actually be called "server sent events", not "server side events".
google seems to respond with mostly the same hits to a search for either. SSE, on the
other hand, will get you a lot of different things.

 

[Mashiane]

@drgottjr

Thank you so much for this. I am currently working on a class that is based on Pocketbase and just need to conclude it with SSE.

PocketBase - Open Source backend in 1 file

Open Source backend in 1 file with realtime database, authentication, file storage and admin dashboard

pocketbase.io

So far its written in b4j.

Pocketbase CRUD REST API & SSE with PostMan and then HttpUtils

Hi CRUD Examples Attached PocketBase is an open source backend consisting of embedded database (SQLite) with realtime subscriptions, built-in users management, convenient dashboard UI and simple REST-ish API. It runs on Linux, Windows and Mac, You can get it here, https://pocketbase.io/ We...

www.b4x.com

They provide an API endpoint for the SSE, a combination of a GET (connection & events) and then a POST (for subscriptions).

I kindly request your help and advise on this matter. For example, using the API endpoints in a b4j environment.

Thanks in advance.

Mashy.

 

[Mashiane]

Update: I have found a solution based on this implementation by Erel

Consuming http streams

Standard http communication is made of a request being sent from the client to the server and the server response sent back to the client. As I'm sure you know you should use OkHttpUtils2 for such requests. There are other protocols such as WebSockets that allow bi-directional and long lasting...

www.b4x.com

Thank you.

 

[drgottjr]

naturally, i saw your thread about pocketbase and
sse. i don't do much with b4j, and i don't know what
pocketbase is, so i really didn't have anything to add
to the discussion.

i was, however, intrigued by the mention of a so-called
"SSE" request for okhttputils2 (and, by extension, for
http clients in general). i was not familiar with any
such form. since we use ok's implementation
as the base for okhtttputils2, i did some reasearch
to see if ok knew anything about sse. that led to
the discovery that once you had an okhttpclient in
hand (with okhttputils2), you could have it connect
sse-ly to an obliging server for notifications.

as far as i have seen, the http protocol does not
include an sse verb (in addition to get, post, etc).
it seems to be one of the many extensions
arising out of http's original simple concept. and
since you seem to have solved the problem yourself,
there isn't too much for me to advise on.

out of curiosity, i'll take a look at pocketbase.io to
see if they provide a standard way to handle sse.
perhaps they provide a test site. the test site i found
did provide a way for me to create a custom notification.

without tearing ok's code apart (as well as that used by
pocketbase's server), it's hard to know exactly how either
source treats sse requests and connections. sse is
described as being "one way" (after the initial connection),
but that may just be a simple catch phrase for the masses
to wrap their heads around the technology.

 

[drgottjr]

pocketbase appears to implement its own
server sent events protocol. it's not going
to work with okhttputils2 (as it is currently
written). if pocketbase followed ok's
implementation of sse, i don't see why
you couldn't use my library with b4j (untested
by me).

in theory, if you worked at it, you could
probably make it look to the user like they
were making an okhttputils2 call and then
branch off to your own code which communicates
with pocketbase using its sse protocol.

the 2 modules which make up our okhttp.b4xlib
library are available to us to modify. similarly to, eg,
job.download or job.poststring methods, you
could invent a "job.sse" method which branches
to your code instead of to okhttp's. that branching
would not be trivial (which is why we have okhttp
in the first place). you would have to code your
own background service for all the network
traffic and handle the callback or event raising
for the b4j side, not to mention connection shutdown...