Anyone doing webSockets for a push app?

S

ScarBelly

Member
Licensed User
Longtime User
Hi,
I'm just getting into b4a and the communication side of things. I see that BlueDude and others are keen on getting some of this to work. I really don't know where to start on the client side of things at all and only a little for the server.

Does anyone have anything to share on using WebViewExtras (thanks warWound) and some javascript to receive pushed data updates? If I can get this working, I'll be happy to share the results.

Thanks,
Steve F
 
Sort by date Sort by votes
S

ScarBelly

Member
Licensed User
Longtime User
Thank you Erel.

I should clarify that I am in need of doing an in-house websocket server for captive clients that have only intranet access. This is a manufacturing production alert (Andon) system. I can't use an internet server.
 
Upvote 0
S

ScarBelly

Member
Licensed User
Longtime User
Sorry, I don't understand. I am new to this. Is SocketServer a part of b4A or what? I didn't find anything with the search.
 
Upvote 0
S

ScarBelly

Member
Licensed User
Longtime User
Ahhh! Thank you, that is just what I needed to see. I'm working on a SuperSocketServer app in .Net and will test it with that sample when I get it up and running.
 
Upvote 0
W

wl

Well-Known Member
Licensed User
Longtime User
I have been doing all kinds of tests for a push system as well (instead of using C2DM).

The Android side was done in some very quick-and-dirty B4A apps.
The server side was done in some very quick-and-dirty C# app.

These are the things I tested:
- polling: have an Android service hit a URL every 30 seconds. The server would reply with a HTML with just a single character (indicating whether or not there was anything to be pushed).

- pushing: the Android service would make a TCP connection to my server app and leave this connection open. The TCP server would also reply with a single character every 30 seconds.

- pushing: run a TCP server on the Android device. to push a message I would need to open a telnet and send a message. Note: this avoids the need to have a server in between but can cause trouble when the Android device has been NATted.

In case of both pushing scenario's it is vital to determine whether a connection was lost as soon as possible, so a reconnect can be attempted. No open TCP connection, no push messages (of course :)


I just did these tests to be able to determine how much extra of the battery was drained in each scenario. This was quite substantial.

Piggy-backing on the already open connection to google server (C2DM) is a lot better, but it in fact depends on a possibility to open a connection to the Google servers.

As far as I am concerned to be continued
 
Upvote 0
S

ScarBelly

Member
Licensed User
Longtime User
Thanks WLambrechts. Did you see much difference in battery life in polling every 30 seconds versus pushing?

I am too concerned about latency and reliability to use C2DM. I would like a response time of under 20 seconds if possible. Time is money.
 
Upvote 0
W

wl

Well-Known Member
Licensed User
Longtime User
Hello,

C2DM is quite reliable and fast. Messages do come through in a matter of seconds. You can try the demo app Erel was referring to to do some testing.

Or: if you want to test C2DM in an easy way you could have a look at: https://market.android.com/details?...xLDEsImNvbS51c2suYXBwLm5vdGlmeW15YW5kcm9pZCJd

It costs a few dollars but this is using C2DM to push messages.

In your case, polling will not be an option: even polling every 30 seconds was draining the battery 30-50% faster (did not measure it in a scientific way).

I'm still testing scenario's but I do have the impression that keeping a TCP socket continuosly open would still matter 30-40%, as soon as you are really starting to send the push messages it will be more.

Surely using C2DM will be the way that uses as least of battery power as possible (the service is running by default on Adroid 2.1 devices and higher). You can also assume the service has been thoroughly developped and tested by Google
 
Upvote 0
S

ScarBelly

Member
Licensed User
Longtime User
Thanks WLambrechts. I am also finding that a websocket server is just not that ready for prime time - too many changes.

I'll try C2DM - I can use it but will bear the blame when it goes down and we can't fix it:BangHead:

It certainly looks like the best solution for now. Plus we need to keep the devices on and app running for at least 10 hours between charges.

BTW - We are using the Samsung Galaxy S Player 5.0. This is one sweet device for this app. Just the right size and features and good battery. If I didn't already have an android phone and tablet, I'd get one for my own use.
 
Upvote 0
You must log in or register to reply here.
Top