Android Question How many websockets in a client?

[LucaMs]

I am very indecisive (and confused) about this issue.

Having 3 or more b4j websocket servers, each of which manages a game (with a common user database), would it be better if the client (B4A-Android app) had a websocket for each server or one only?

I'm also arguing with myself to decide which objects to create and where to put them (in the app, of course). Surely they will have to work in a foreground service, but I don't know whether to create a "websocket handler" object (for each websocket) and put it directly in the service or, having a class for each game, put it in this one and the instance of this class in the service... or maybe in a different way yet (for example no "websocket handler" class at all, its code directly inside the game class).



If these doubts weren't enough... if in the future I wanted to make a B4I-iOS version of the app I wouldn't know how to "fix" the lack of services here - After all, I don't know iOS nor B4I at all.

 

[Erel]

I'm also arguing with myself to decide which objects to create and where to put them (in the app, of course). Surely they will have to work in a foreground service, but I don't know whether to create a "websocket handler" object (for each websocket) and put it directly in the service or, having a class for each game, put it in this one and the instance of this class in the service... or maybe in a different way yet (for example no "websocket handler" class at all, its code directly inside the game class).



If these doubts weren't enough... if in the future I wanted to make a B4I-iOS version of the app I wouldn't know how to "fix" the lack of services here - After all, I don't know iOS nor B4I at all.

Use B4XPages. You will not need to think about such things at all.

Having 3 or more b4j websocket servers, each of which manages a game (with a common user database), would it be better if the client (B4A-Android app) had a websocket for each server or one only?

I'm not sure that you gave us enough information, but as a general rule, if you have 3 connections then the state will be more complicated as you will have cases when one connection breaks while the others still work.

 

[LucaMs]

First, thanks for the reply, Erel.

I'll try to prepare a better explanation and a "reply to your reply" but I have to focus on making it as concise and short as possible (no one has time to waste, let alone you), so I need time

 

[LucaMs]

Because of this:

making it as concise and short as possible

I can't explain in detail why I did what I'll write below that bad way.

I have already developed (for quite some time) a client (B4A) - server (B4J-Jetty websocket server) pair for a game, which has been running.

The (bad) "structure" of the client is roughly like this:

(This kind of "structure" forced me to almost duplicate many routines).

Use B4XPages. You will not need to think about such things at all.

I had thought of using B4XPages (also for a possible future B4I-iOS version) but the problem of choosing whether to use a single websocket or one for each game server would remain. Same thing regarding the number, type and "location" of objects.
Additionally, a service module is required; it must contain at least one websocket (or an object that contains the websocket, one of the many doubts) as messages received by the server (or servers) must be received even if the user sends the app to background (home button, incoming phone call, ...).

I'm not sure that you gave us enough information, but as a general rule, if you have 3 connections then the state will be more complicated as you will have cases when one connection breaks while the others still work.

I didn't mean more than one websocket connected simultaneously but one at a time (maybe two, but I'd like to be concise ).
The user chooses a game and the app connects to the related server.

So I might have:

a) 3 "websocket handler" classes, 3 game classes (containing the 3 "websocket handler" instances/object) into the "comunication service module"
b) the 3 game classes containing the "websocket handler" class code directly, still in the service
c) 1 websocket handler class only, in the service, to be connected and disconnected from one server at a time. In this case the message sent by the server should contain a reference/id of the game to which it refers.

Writing and "thinking", maybe the option (c) should be the best (although the code may not be very readable, manageable, updatable, ... )


Perfect! I was neither clear nor concise, as usual

 

[Erel]

Additionally, a service module is required; it must contain at least one websocket (or an object that contains the websocket, one of the many doubts) as messages received by the server (or servers) must be received even if the user sends the app to background (home button, incoming phone call, ...).

This is solved with B4XPages and doesn't require a foreground service unless you really want the app to continue running in the background for a long time. Even in that case it will be much simpler with B4XPages as you can just add a foreground service without any code.

 

[LucaMs]

This is solved with B4XPages and doesn't require a foreground service unless you really want the app to continue running in the background for a long time. Even in that case it will be much simpler with B4XPages as you can just add a foreground service without any code.

Sorry, Erel, I don't understand. Even with B4XPages if the app is sent to background, even for just one second, the only way I know to receive messages from a websocket server is to use a service (in fact I don't know how to do with B4I, but for the moment I don't need this).

 

[Erel]

I don't understand. Even with B4XPages if the app is sent to background, even for just one second, the only way I know to receive messages from a websocket server is to use a service

No. B4XPages classes are never paused.

 

[LucaMs]

No. B4XPages classes are never paused.

I can't imagine how that's possible.

It is true that I was confused (just to do something new ) "thinking" that they were all instantiated in the Activity Main and instead they are in the internal code module but... ok, I avoid thinking about it.

So, in any B4XPage (class) I put a websocket it would never lose data sent by the server, even with the app in background (unless the app is killed by the operating system, of course)?

 

[Erel]

Yes. Yes. Yes. Yes. Yes.

More information here: https://www.b4x.com/android/forum/threads/b4x-b4xpages-what-exactly-does-it-solve.119078/#content

 

[LucaMs]

Yes. Yes. Yes. Yes. Yes.

More information here: https://www.b4x.com/android/forum/threads/b4x-b4xpages-what-exactly-does-it-solve.119078/#content

I re-read all last night (and I VERY appreciate the long list of great benefits) and also watched the video again... in slow motion (but you didn't like my joke, apparently ).

But I've already written a nonsense; B4XPages does contain references to the pages you declare and instantiate elsewhere, though.

Okay, thanks, Erel.


BTW, if I read during the day, maybe I would be slightly less confused

 

[LucaMs]

Erel, know that I no longer need a service module, the client (the websocket) receives messages from the server even if the app is sent to background.


One more reason to love XP (XP = B4XPages, nothing to do with Windows XP).

Thank you for your answers in this thread and even more for the XPs !!!

 

[LucaMs]

Not only I no longer need a service module...

Please, Erel, try to understand what I am about to write, even if I already know that I will not explain it well.

B4XPages (XP) solve another problem of my app!!!

1 - a user-player of my app takes an action, which should appear graphically on all the other clients connected. So che server sends a message with this info to all clients;
2 - one client-app is in background.

Before XP, using a service which received all server messages and called an Activity routine that started the animation (animation but always data too, of course) my "solution" was: "Service, if the app and the Activity is in background, don't call the Activity routine, the app will request the server the new full state of the game on Activity_Resume".

Now, since server's messages are received even without a service (maybe one day I'll understand how) I thought that even the things just written would work, being in the same B4XPage class, that is, the app would work in the background exactly as if it were in the foreground, so I did a test and... it is so! the app in background works exactly as if it were in foreground!

Wonderful! Great! Incredible! Amazing! (at the moment no other english adjectives come to my mind ).

So, all in all, I was right from the start:
(year) 9.90 - The Revolution


Thank you again, Erel. With the first millions that I will earn thanks to this, I will make a very small donation
(or when Douglas will donate to me ).

[In fact, as soon as I can ]

Note that I have never published the app I "talked" about.

 

[LucaMs]

Wonderful! Great! Incredible! Amazing! (at the moment no other english adjectives come to my mind ).

Fantastic

 

[Erel]

Now, since server's messages are received even without a service (maybe one day I'll understand how) I thought that even the things just written would work, being in the same B4XPage class, that is, the app would work in the background exactly as if it were in the foreground, so I did a test and... it is so! the app in background works exactly as if it were in foreground!

Wonderful! Great! Incredible! Amazing! (at the moment no other english adjectives come to my mind ).

B4XPages is indeed the most important new feature since the Resumable Subs feature.

 

[LucaMs]

B4XPages is indeed the most important new feature since the Resumable Subs feature.

 

[Erel]

Why no links???