NetworkOnMainThreadException

#1

Hello,
I've been developing a websocket application for android, and have
been testing out several web socket libraries. I came across
autobahn and It looks promising, but on my first attempt to use it on
a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
description on the homepage it sounds like this library should be
doing all of its communication OFF of the android UI thread, but that
doesn't appear to be the case, as I get the exception on my very first
call to .connect. Am I missing something or has this library not
been tested on 3.0+ devices where the OS is more strict about ANR
Behaviour?

0 Likes

#2

It does run on background threads:

<img src="cid:part1.070...@gmail.com" alt="">

and according to this user

it works on Android 4.

However, I currently only have / test 2.2 and 2.3 devices.
Note that the socket to the server side is created on main thread,
and then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.
However no actual socket read/writes are performed on main thread!
Probably the initial socket connect should be done on a short lived
connector thread …
so that the initial socket connection also happens asynch. and on
background thread.

···

http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6b47e9e6d11

0 Likes

#3

Thanks for the quick reply. I posted in the other thread to see if
that user has any insights. do you have any example of making a
connection in a way that won't block the UI thread? everything I have
seen makes their connections this way.

Thanks,
Andre

···

On Feb 13, 8:28 am, Tobias Oberstein <tobias.o...@gmail.com> wrote:

Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

> Hello,
> I've been developing a websocket application for android, and have
> been testing out several web socket libraries. I came across
> autobahn and It looks promising, but on my first attempt to use it on
> a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
> description on the homepage it sounds like this library should be
> doing all of its communication OFF of the android UI thread, but that
> doesn't appear to be the case, as I get the exception on my very first
> call to .connect. Am I missing something or has this library not
> been tested on 3.0+ devices where the OS is more strict about ANR
> Behaviour?

It does run on background threads:

and according to this user

http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...

it works on Android 4.

However, I currently only have / test 2.2 and 2.3 devices.

Note that the socket to the server side is _created_ on main thread, and
then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.

However no actual socket read/writes are performed on main thread!

Probably the initial socket connect should be done on a short lived
connector thread ..
so that the initial socket connection also happens asynch. and on
background thread.

0 Likes

#4

the solution likely will be to wrap the try block

https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/de/tavendo/autobahn/WebSocketConnection.java#L190

into an AsyncTask ..

give me 1-2h and I see if I can make that work .. even when I can't test it ..

\Tobias

···

Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

Thanks for the quick reply. I posted in the other thread to see if
that user has any insights. do you have any example of making a
connection in a way that won't block the UI thread? everything I have
seen makes their connections this way.

Thanks,
Andre

On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> > wrote:

Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

Hello,
I've been developing a websocket application for android, and have
been testing out several web socket libraries. I came across
autobahn and It looks promising, but on my first attempt to use it on
a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
description on the homepage it sounds like this library should be
doing all of its communication OFF of the android UI thread, but that
doesn't appear to be the case, as I get the exception on my very first
call to .connect. Am I missing something or has this library not
been tested on 3.0+ devices where the OS is more strict about ANR
Behaviour?

It does run on background threads:

and according to this user

http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...

it works on Android 4.

However, I currently only have / test 2.2 and 2.3 devices.

Note that the socket to the server side is _created_ on main thread, and
then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.

However no actual socket read/writes are performed on main thread!

Probably the initial socket connect should be done on a short lived
connector thread ..
so that the initial socket connection also happens asynch. and on
background thread.

0 Likes

#5

Thanks for looking into it, I think you were right in that other
thread, you can test it by using strict mode on < 4.0 devices.. also
the android emulator supports 4.0 well enough to test it too.. If
there is anything I can do to help just ask.

···

On Feb 13, 9:00 am, Tobias Oberstein <tobias.o...@gmail.com> wrote:

the solution likely will be to wrap the try block

https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...

into an AsyncTask ..

give me 1-2h and I see if I can make that work .. even when I can't test
it ..

\Tobias

Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

> Thanks for the quick reply. I posted in the other thread to see if
> that user has any insights. do you have any example of making a
> connection in a way that won't block the UI thread? everything I have
> seen makes their connections this way.

> Thanks,
> Andre

> On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> > > wrote:
>> Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

>>> Hello,
>>> I've been developing a websocket application for android, and have
>>> been testing out several web socket libraries. I came across
>>> autobahn and It looks promising, but on my first attempt to use it on
>>> a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
>>> description on the homepage it sounds like this library should be
>>> doing all of its communication OFF of the android UI thread, but that
>>> doesn't appear to be the case, as I get the exception on my very first
>>> call to .connect. Am I missing something or has this library not
>>> been tested on 3.0+ devices where the OS is more strict about ANR
>>> Behaviour?
>> It does run on background threads:

>> and according to this user

>>http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...

>> it works on Android 4.

>> However, I currently only have / test 2.2 and 2.3 devices.

>> Note that the socket to the server side is _created_ on main thread, and
>> then used on
>> the writer and reader background threads. Both of these threads need
>> access to that socket,
>> so I think it make sense to create it on main thread.

>> However no actual socket read/writes are performed on main thread!

>> Probably the initial socket connect should be done on a short lived
>> connector thread ..
>> so that the initial socket connection also happens asynch. and on
>> background thread.

0 Likes

#6

ok, here

https://github.com/oberstet/AutobahnAndroid/commit/398cd0559b75b21ac53b559099ce90051f0b0e3f

it does not produce StrictMode network access on UI messages anymore.

Could you give it a try on real devices?

That is: use the latest code from the repo ..

Caveat: I still need to figure out how to forward any errors happening during connection
as exception (to maintain ifc compat.) ..

Another thing: do you use code like

http://android-sdk.appspot.com/reference/android/os/StrictMode.html

and if so, what config options to

setThreadPolicy /setVmPolicy

Thanks!
\Tobias

···

Am 13.02.2012 15:18, schrieb Andre P LeBlanc:

Thanks for looking into it, I think you were right in that other
thread, you can test it by using strict mode on< 4.0 devices.. also
the android emulator supports 4.0 well enough to test it too.. If
there is anything I can do to help just ask.

On Feb 13, 9:00 am, Tobias Oberstein<tobias.o...@gmail.com> > wrote:

the solution likely will be to wrap the try block

https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...

into an AsyncTask ..

give me 1-2h and I see if I can make that work .. even when I can't test
it ..

\Tobias

Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

Thanks for the quick reply. I posted in the other thread to see if
that user has any insights. do you have any example of making a
connection in a way that won't block the UI thread? everything I have
seen makes their connections this way.
Thanks,
Andre
On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> >>> wrote:

Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

Hello,
I've been developing a websocket application for android, and have
been testing out several web socket libraries. I came across
autobahn and It looks promising, but on my first attempt to use it on
a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
description on the homepage it sounds like this library should be
doing all of its communication OFF of the android UI thread, but that
doesn't appear to be the case, as I get the exception on my very first
call to .connect. Am I missing something or has this library not
been tested on 3.0+ devices where the OS is more strict about ANR
Behaviour?

It does run on background threads:
and according to this user
http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...
it works on Android 4.
However, I currently only have / test 2.2 and 2.3 devices.
Note that the socket to the server side is _created_ on main thread, and
then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.
However no actual socket read/writes are performed on main thread!
Probably the initial socket connect should be done on a short lived
connector thread ..
so that the initial socket connection also happens asynch. and on
background thread.

0 Likes

#7

So far so good. it connects and works now.. I still have to do some
more testing. my app is a service which requires a connection at all
times, and must be as persistent as possible.. I've had a lot of
problems keeping devices online through bad signal areas and cell
changes.

I'm not using any StrictMode code at all.

···

On Feb 13, 9:56 am, Tobias Oberstein <tobias.o...@gmail.com> wrote:

ok, here

https://github.com/oberstet/AutobahnAndroid/commit/398cd0559b75b21ac5...

it does not produce StrictMode network access on UI messages anymore.

Could you give it a try on real devices?

That is: use the latest code from the repo ..

Caveat: I still need to figure out how to forward any errors happening
during connection
as exception (to maintain ifc compat.) ..

Another thing: do you use code like

http://android-sdk.appspot.com/reference/android/os/StrictMode.html

and if so, what config options to

setThreadPolicy /setVmPolicy

Thanks!
\Tobias

Am 13.02.2012 15:18, schrieb Andre P LeBlanc:

> Thanks for looking into it, I think you were right in that other
> thread, you can test it by using strict mode on< 4.0 devices.. also
> the android emulator supports 4.0 well enough to test it too.. If
> there is anything I can do to help just ask.

> On Feb 13, 9:00 am, Tobias Oberstein<tobias.o...@gmail.com> > > wrote:
>> the solution likely will be to wrap the try block

>>https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...

>> into an AsyncTask ..

>> give me 1-2h and I see if I can make that work .. even when I can't test
>> it ..

>> \Tobias

>> Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

>>> Thanks for the quick reply. I posted in the other thread to see if
>>> that user has any insights. do you have any example of making a
>>> connection in a way that won't block the UI thread? everything I have
>>> seen makes their connections this way.
>>> Thanks,
>>> Andre
>>> On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> > >>> wrote:
>>>> Am 13.02.2012 14:13, schrieb Andre P LeBlanc:
>>>>> Hello,
>>>>> I've been developing a websocket application for android, and have
>>>>> been testing out several web socket libraries. I came across
>>>>> autobahn and It looks promising, but on my first attempt to use it on
>>>>> a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
>>>>> description on the homepage it sounds like this library should be
>>>>> doing all of its communication OFF of the android UI thread, but that
>>>>> doesn't appear to be the case, as I get the exception on my very first
>>>>> call to .connect. Am I missing something or has this library not
>>>>> been tested on 3.0+ devices where the OS is more strict about ANR
>>>>> Behaviour?
>>>> It does run on background threads:
>>>> and according to this user
>>>>http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...
>>>> it works on Android 4.
>>>> However, I currently only have / test 2.2 and 2.3 devices.
>>>> Note that the socket to the server side is _created_ on main thread, and
>>>> then used on
>>>> the writer and reader background threads. Both of these threads need
>>>> access to that socket,
>>>> so I think it make sense to create it on main thread.
>>>> However no actual socket read/writes are performed on main thread!
>>>> Probably the initial socket connect should be done on a short lived
>>>> connector thread ..
>>>> so that the initial socket connection also happens asynch. and on
>>>> background thread.

0 Likes

#8

great.

rgd. robustness when running as service / against network problem and outages .. thats
important for me also.

couple of things:

1)
activity/service lifecycle: currently, I disconnect in onDestroy()

https://github.com/oberstet/AutobahnAndroid/blob/master/Demo/EchoClient/src/de/tavendo/autobahn/echoclient/EchoClientActivity.java#L163

how do you handle (plan to) lifecycle?

2)
we could add an option to send keep alive websocket pings ... that would probably
prevent the network connection go to sleep or degrade from HSPA to UMTS or GPRS/EDGE i.e.

whether thats a good idea is another thing ..

···

==

I'm quite interested in any results and problems in this field .. pls report here ..

Thanks
Tobias

Am 13.02.2012 16:25, schrieb Andre P LeBlanc:

So far so good. it connects and works now.. I still have to do some
more testing. my app is a service which requires a connection at all
times, and must be as persistent as possible.. I've had a lot of
problems keeping devices online through bad signal areas and cell
changes.

I'm not using any StrictMode code at all.

On Feb 13, 9:56 am, Tobias Oberstein<tobias.o...@gmail.com> > wrote:

ok, here

https://github.com/oberstet/AutobahnAndroid/commit/398cd0559b75b21ac5...

it does not produce StrictMode network access on UI messages anymore.

Could you give it a try on real devices?

That is: use the latest code from the repo ..

Caveat: I still need to figure out how to forward any errors happening
during connection
as exception (to maintain ifc compat.) ..

Another thing: do you use code like

http://android-sdk.appspot.com/reference/android/os/StrictMode.html

and if so, what config options to

setThreadPolicy /setVmPolicy

Thanks!
\Tobias

Am 13.02.2012 15:18, schrieb Andre P LeBlanc:

Thanks for looking into it, I think you were right in that other
thread, you can test it by using strict mode on< 4.0 devices.. also
the android emulator supports 4.0 well enough to test it too.. If
there is anything I can do to help just ask.
On Feb 13, 9:00 am, Tobias Oberstein<tobias.o...@gmail.com> >>> wrote:

the solution likely will be to wrap the try block
https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...
into an AsyncTask ..
give me 1-2h and I see if I can make that work .. even when I can't test
it ..
\Tobias
Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

Thanks for the quick reply. I posted in the other thread to see if
that user has any insights. do you have any example of making a
connection in a way that won't block the UI thread? everything I have
seen makes their connections this way.
Thanks,
Andre
On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> >>>>> wrote:

Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

Hello,
I've been developing a websocket application for android, and have
been testing out several web socket libraries. I came across
autobahn and It looks promising, but on my first attempt to use it on
a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
description on the homepage it sounds like this library should be
doing all of its communication OFF of the android UI thread, but that
doesn't appear to be the case, as I get the exception on my very first
call to .connect. Am I missing something or has this library not
been tested on 3.0+ devices where the OS is more strict about ANR
Behaviour?

It does run on background threads:
and according to this user
http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...
it works on Android 4.
However, I currently only have / test 2.2 and 2.3 devices.
Note that the socket to the server side is _created_ on main thread, and
then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.
However no actual socket read/writes are performed on main thread!
Probably the initial socket connect should be done on a short lived
connector thread ..
so that the initial socket connection also happens asynch. and on
background thread.

0 Likes

#9

We connect in onStartCommand and disconnect in onDestroy, and
schedule reconnects w/ an exponential backoff in onClose. All of that
works fine as long as the device maintains a good signal, but using
other libraries I've had problems where the connect attempt will hang
indefinitely when there is a bad signal.

There are other times when the android OS itself seems to just lose
it's internet connection and refuses to reconnect until airplane mode
is toggled.. this usually only happens in very bad signal areas or
during cell changes. I have my code manually toggle airplane mode if
its connection attempts fail for more than a few minutes.

I've also encountered plenty of problems maintain a connection with
only a partial wake lock, it still seems to lose its connection
shortly after sleeping and and reconnects immediately on turning on
the screen... As I understand it, a partial wake lock should be
sufficient to maintain a network connection but that doesn't appear to
be the case for me.

the application send a lot of data, so there is little chance that is
timing out unless the connection is very poor, but I did implement my
own ping just in case nothing is received for a while.

···

On Feb 13, 10:37 am, Tobias Oberstein <tobias.o...@gmail.com> wrote:

great.

rgd. robustness when running as service / against network problem and
outages .. thats
important for me also.

couple of things:

1)
activity/service lifecycle: currently, I disconnect in onDestroy()

https://github.com/oberstet/AutobahnAndroid/blob/master/Demo/EchoClie...

how do you handle (plan to) lifecycle?

2)
we could add an option to send keep alive websocket pings ... that would
probably
prevent the network connection go to sleep or degrade from HSPA to UMTS
or GPRS/EDGE i.e.

whether thats a good idea is another thing ..

==

I'm quite interested in any results and problems in this field .. pls
report here ..

Thanks
Tobias

Am 13.02.2012 16:25, schrieb Andre P LeBlanc:

> So far so good. it connects and works now.. I still have to do some
> more testing. my app is a service which requires a connection at all
> times, and must be as persistent as possible.. I've had a lot of
> problems keeping devices online through bad signal areas and cell
> changes.

> I'm not using any StrictMode code at all.

> On Feb 13, 9:56 am, Tobias Oberstein<tobias.o...@gmail.com> > > wrote:
>> ok, here

>>https://github.com/oberstet/AutobahnAndroid/commit/398cd0559b75b21ac5...

>> it does not produce StrictMode network access on UI messages anymore.

>> Could you give it a try on real devices?

>> That is: use the latest code from the repo ..

>> Caveat: I still need to figure out how to forward any errors happening
>> during connection
>> as exception (to maintain ifc compat.) ..

>> Another thing: do you use code like

>>http://android-sdk.appspot.com/reference/android/os/StrictMode.html

>> and if so, what config options to

>> setThreadPolicy /setVmPolicy

>> Thanks!
>> \Tobias

>> Am 13.02.2012 15:18, schrieb Andre P LeBlanc:

>>> Thanks for looking into it, I think you were right in that other
>>> thread, you can test it by using strict mode on< 4.0 devices.. also
>>> the android emulator supports 4.0 well enough to test it too.. If
>>> there is anything I can do to help just ask.
>>> On Feb 13, 9:00 am, Tobias Oberstein<tobias.o...@gmail.com> > >>> wrote:
>>>> the solution likely will be to wrap the try block
>>>>https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...
>>>> into an AsyncTask ..
>>>> give me 1-2h and I see if I can make that work .. even when I can't test
>>>> it ..
>>>> \Tobias
>>>> Am 13.02.2012 14:50, schrieb Andre P LeBlanc:
>>>>> Thanks for the quick reply. I posted in the other thread to see if
>>>>> that user has any insights. do you have any example of making a
>>>>> connection in a way that won't block the UI thread? everything I have
>>>>> seen makes their connections this way.
>>>>> Thanks,
>>>>> Andre
>>>>> On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> > >>>>> wrote:
>>>>>> Am 13.02.2012 14:13, schrieb Andre P LeBlanc:
>>>>>>> Hello,
>>>>>>> I've been developing a websocket application for android, and have
>>>>>>> been testing out several web socket libraries. I came across
>>>>>>> autobahn and It looks promising, but on my first attempt to use it on
>>>>>>> a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
>>>>>>> description on the homepage it sounds like this library should be
>>>>>>> doing all of its communication OFF of the android UI thread, but that
>>>>>>> doesn't appear to be the case, as I get the exception on my very first
>>>>>>> call to .connect. Am I missing something or has this library not
>>>>>>> been tested on 3.0+ devices where the OS is more strict about ANR
>>>>>>> Behaviour?
>>>>>> It does run on background threads:
>>>>>> and according to this user
>>>>>>http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...
>>>>>> it works on Android 4.
>>>>>> However, I currently only have / test 2.2 and 2.3 devices.
>>>>>> Note that the socket to the server side is _created_ on main thread, and
>>>>>> then used on
>>>>>> the writer and reader background threads. Both of these threads need
>>>>>> access to that socket,
>>>>>> so I think it make sense to create it on main thread.
>>>>>> However no actual socket read/writes are performed on main thread!
>>>>>> Probably the initial socket connect should be done on a short lived
>>>>>> connector thread ..
>>>>>> so that the initial socket connection also happens asynch. and on
>>>>>> background thread.

0 Likes

#10

Regarding keeping a long-lived TCP working .. still learning in that area ..

This one sounds like he knows what he's talking about:

http://stackoverflow.com/a/9253083/884770

Many factors involved ..

···

Am 13.02.2012 17:01, schrieb Andre P LeBlanc:

We connect in onStartCommand and disconnect in onDestroy, and
schedule reconnects w/ an exponential backoff in onClose. All of that
works fine as long as the device maintains a good signal, but using
other libraries I've had problems where the connect attempt will hang
indefinitely when there is a bad signal.

There are other times when the android OS itself seems to just lose
it's internet connection and refuses to reconnect until airplane mode
is toggled.. this usually only happens in very bad signal areas or
during cell changes. I have my code manually toggle airplane mode if
its connection attempts fail for more than a few minutes.

I've also encountered plenty of problems maintain a connection with
only a partial wake lock, it still seems to lose its connection
shortly after sleeping and and reconnects immediately on turning on
the screen... As I understand it, a partial wake lock should be
sufficient to maintain a network connection but that doesn't appear to
be the case for me.

the application send a lot of data, so there is little chance that is
timing out unless the connection is very poor, but I did implement my
own ping just in case nothing is received for a while.

On Feb 13, 10:37 am, Tobias Oberstein<tobias.o...@gmail.com> > wrote:

great.

rgd. robustness when running as service / against network problem and
outages .. thats
important for me also.

couple of things:

1)
activity/service lifecycle: currently, I disconnect in onDestroy()

https://github.com/oberstet/AutobahnAndroid/blob/master/Demo/EchoClie...

how do you handle (plan to) lifecycle?

2)
we could add an option to send keep alive websocket pings ... that would
probably
prevent the network connection go to sleep or degrade from HSPA to UMTS
or GPRS/EDGE i.e.

whether thats a good idea is another thing ..

==

I'm quite interested in any results and problems in this field .. pls
report here ..

Thanks
Tobias

Am 13.02.2012 16:25, schrieb Andre P LeBlanc:

So far so good. it connects and works now.. I still have to do some
more testing. my app is a service which requires a connection at all
times, and must be as persistent as possible.. I've had a lot of
problems keeping devices online through bad signal areas and cell
changes.
I'm not using any StrictMode code at all.
On Feb 13, 9:56 am, Tobias Oberstein<tobias.o...@gmail.com> >>> wrote:

ok, here
https://github.com/oberstet/AutobahnAndroid/commit/398cd0559b75b21ac5...
it does not produce StrictMode network access on UI messages anymore.
Could you give it a try on real devices?
That is: use the latest code from the repo ..
Caveat: I still need to figure out how to forward any errors happening
during connection
as exception (to maintain ifc compat.) ..
Another thing: do you use code like
http://android-sdk.appspot.com/reference/android/os/StrictMode.html
and if so, what config options to
setThreadPolicy /setVmPolicy
Thanks!
\Tobias
Am 13.02.2012 15:18, schrieb Andre P LeBlanc:

Thanks for looking into it, I think you were right in that other
thread, you can test it by using strict mode on< 4.0 devices.. also
the android emulator supports 4.0 well enough to test it too.. If
there is anything I can do to help just ask.
On Feb 13, 9:00 am, Tobias Oberstein<tobias.o...@gmail.com> >>>>> wrote:

the solution likely will be to wrap the try block
https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...
into an AsyncTask ..
give me 1-2h and I see if I can make that work .. even when I can't test
it ..
\Tobias
Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

Thanks for the quick reply. I posted in the other thread to see if
that user has any insights. do you have any example of making a
connection in a way that won't block the UI thread? everything I have
seen makes their connections this way.
Thanks,
Andre
On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> >>>>>>> wrote:

Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

Hello,
I've been developing a websocket application for android, and have
been testing out several web socket libraries. I came across
autobahn and It looks promising, but on my first attempt to use it on
a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
description on the homepage it sounds like this library should be
doing all of its communication OFF of the android UI thread, but that
doesn't appear to be the case, as I get the exception on my very first
call to .connect. Am I missing something or has this library not
been tested on 3.0+ devices where the OS is more strict about ANR
Behaviour?

It does run on background threads:
and according to this user
http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...
it works on Android 4.
However, I currently only have / test 2.2 and 2.3 devices.
Note that the socket to the server side is _created_ on main thread, and
then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.
However no actual socket read/writes are performed on main thread!
Probably the initial socket connect should be done on a short lived
connector thread ..
so that the initial socket connection also happens asynch. and on
background thread.

0 Likes

#11

My current understanding:

If you have a socket open on wireless data (3G, _not_ WiFi), an incoming packet on that socket will
wake up the device (CPU) for a short period of time.

Upon said socket becoming readable, the app should then acquire a PARTIAL_WAKE_LOCK
to handle the data, and after having processed the data, it should release the PARTIAL_WAKE_LOCK.

Things work differently on Wifi ..

When on Wifi, to maintain a socket connection, one needs to hold a PARTIAL_WAKE_LOCK
(for CPU) _and_ a Wifi Lock.

There seems to be no way of forcing a socket connection to packet data, when there is Wifi.

Is above correct / also your understanding?

···

==

Sources:

http://stackoverflow.com/questions/9252587/android-app-lock-required-for-socket-connection

http://stackoverflow.com/questions/5616561/what-events-can-wake-up-a-sleeping-android-device

http://stackoverflow.com/questions/5007721/android-sleep-stages-levels-on-an-android-device

Am 13.02.2012 17:01, schrieb Andre P LeBlanc:

We connect in onStartCommand and disconnect in onDestroy, and
schedule reconnects w/ an exponential backoff in onClose. All of that
works fine as long as the device maintains a good signal, but using
other libraries I've had problems where the connect attempt will hang
indefinitely when there is a bad signal.

There are other times when the android OS itself seems to just lose
it's internet connection and refuses to reconnect until airplane mode
is toggled.. this usually only happens in very bad signal areas or
during cell changes. I have my code manually toggle airplane mode if
its connection attempts fail for more than a few minutes.

I've also encountered plenty of problems maintain a connection with
only a partial wake lock, it still seems to lose its connection
shortly after sleeping and and reconnects immediately on turning on
the screen... As I understand it, a partial wake lock should be
sufficient to maintain a network connection but that doesn't appear to
be the case for me.

the application send a lot of data, so there is little chance that is
timing out unless the connection is very poor, but I did implement my
own ping just in case nothing is received for a while.

On Feb 13, 10:37 am, Tobias Oberstein<tobias.o...@gmail.com> > wrote:

great.

rgd. robustness when running as service / against network problem and
outages .. thats
important for me also.

couple of things:

1)
activity/service lifecycle: currently, I disconnect in onDestroy()

https://github.com/oberstet/AutobahnAndroid/blob/master/Demo/EchoClie...

how do you handle (plan to) lifecycle?

2)
we could add an option to send keep alive websocket pings ... that would
probably
prevent the network connection go to sleep or degrade from HSPA to UMTS
or GPRS/EDGE i.e.

whether thats a good idea is another thing ..

==

I'm quite interested in any results and problems in this field .. pls
report here ..

Thanks
Tobias

Am 13.02.2012 16:25, schrieb Andre P LeBlanc:

So far so good. it connects and works now.. I still have to do some
more testing. my app is a service which requires a connection at all
times, and must be as persistent as possible.. I've had a lot of
problems keeping devices online through bad signal areas and cell
changes.
I'm not using any StrictMode code at all.
On Feb 13, 9:56 am, Tobias Oberstein<tobias.o...@gmail.com> >>> wrote:

ok, here
https://github.com/oberstet/AutobahnAndroid/commit/398cd0559b75b21ac5...
it does not produce StrictMode network access on UI messages anymore.
Could you give it a try on real devices?
That is: use the latest code from the repo ..
Caveat: I still need to figure out how to forward any errors happening
during connection
as exception (to maintain ifc compat.) ..
Another thing: do you use code like
http://android-sdk.appspot.com/reference/android/os/StrictMode.html
and if so, what config options to
setThreadPolicy /setVmPolicy
Thanks!
\Tobias
Am 13.02.2012 15:18, schrieb Andre P LeBlanc:

Thanks for looking into it, I think you were right in that other
thread, you can test it by using strict mode on< 4.0 devices.. also
the android emulator supports 4.0 well enough to test it too.. If
there is anything I can do to help just ask.
On Feb 13, 9:00 am, Tobias Oberstein<tobias.o...@gmail.com> >>>>> wrote:

the solution likely will be to wrap the try block
https://github.com/oberstet/AutobahnAndroid/blob/master/Autobahn/src/...
into an AsyncTask ..
give me 1-2h and I see if I can make that work .. even when I can't test
it ..
\Tobias
Am 13.02.2012 14:50, schrieb Andre P LeBlanc:

Thanks for the quick reply. I posted in the other thread to see if
that user has any insights. do you have any example of making a
connection in a way that won't block the UI thread? everything I have
seen makes their connections this way.
Thanks,
Andre
On Feb 13, 8:28 am, Tobias Oberstein<tobias.o...@gmail.com> >>>>>>> wrote:

Am 13.02.2012 14:13, schrieb Andre P LeBlanc:

Hello,
I've been developing a websocket application for android, and have
been testing out several web socket libraries. I came across
autobahn and It looks promising, but on my first attempt to use it on
a 3.0+ device I get a NetworkOnMainThread exception thrown.. from the
description on the homepage it sounds like this library should be
doing all of its communication OFF of the android UI thread, but that
doesn't appear to be the case, as I get the exception on my very first
call to .connect. Am I missing something or has this library not
been tested on 3.0+ devices where the OS is more strict about ANR
Behaviour?

It does run on background threads:
and according to this user
http://groups.google.com/group/autobahnws/browse_thread/thread/3b75b6...
it works on Android 4.
However, I currently only have / test 2.2 and 2.3 devices.
Note that the socket to the server side is _created_ on main thread, and
then used on
the writer and reader background threads. Both of these threads need
access to that socket,
so I think it make sense to create it on main thread.
However no actual socket read/writes are performed on main thread!
Probably the initial socket connect should be done on a short lived
connector thread ..
so that the initial socket connection also happens asynch. and on
background thread.

0 Likes