[CLOSED] [iOS] Location publishes cease after losing WIFI connection and don't restart again about android HOT 12 CLOSED

Comment by stefanoco from Tuesday Jan 14, 2014 at 07:17 GMT

On 01/14/2014 07:36 AM, Ben Jones wrote:

Not sure what exactly is going on here but since the latest version on
iOS I have noticed that when the phone moves out of my home WIFI range
and onto 3G, location publishes stop - all kinds. Even when the phone
arrives home and goes back on WIFI nothing happens.

Kind of random behaviour here:

• when location publish is in "manual" mode and a geo-fence area is
  defined (waypoint+radius) nothing is being published going in/out of the
  area, and the area in this case is also Wifi covered (home, office)
• when location publish is in one of "auto" modes sometimes going out of
  Wifi coverage gives no publishing for the rest of the day.

I'll try to better observe the real behaviour but I suspect that when
I'm leaving a Wifi covered area with MQTTitude stopped and I launch it
while driving, it works well. I'll do a few tests.

Thanks for the great app anyway!!!

Stefano Costa

from android.

Comment by jpmens from Tuesday Jan 14, 2014 at 07:18 GMT

Works fine here, on two distinct devices ... I assume you've set PUBs to 'manual mode' (as discussed yesterday, I think it was)? Have you tried automatic mode?

from android.

Comment by sumnerboy12 from Tuesday Jan 14, 2014 at 07:36 GMT

Hmm good point JP. I did have it set to manual publish. I have just changed it to automatic so will keep an eye on it tomorrow as the wife makes her way into work.

CK did mention that the region stuff was independent from the auto-publishing, but perhaps there is something awry in the connection logic when in manual publish mode, preventing region events from getting sent?

from android.

Comment by stefanoco from Tuesday Jan 14, 2014 at 07:45 GMT

Debugging with MQTTitude + MQTTInspector ;-)

from android.

Comment by jpmens from Tuesday Jan 14, 2014 at 07:48 GMT

;-)

from android.

Comment by ckrey from Tuesday Jan 14, 2014 at 08:22 GMT

:D

from android.

Comment by ckrey from Tuesday Jan 14, 2014 at 08:52 GMT

Here's what happens (works as designed, not as desired):

If the app goes into Background, the connection is disconnected because the app cannot maintain the TCP connection in background.

If you bring the app back into foreground, you'll notice the BLUE connection indicator, meaning disconnected, nothing to do.

When a location change is recorded (no matter if manual, significant, move or region mode), a messages is prepared and an attempt to connect to the broker is started.

If there is an error, connect will be retried after 2, 4, 8, ..., 64, 64, .... seconds until it succeeds.

BUT....

If the application is in background or is sent to background, the retries are stopped until the next message is generated.

When your are stationary (e.g. at home), nothing will happen. The queued messages will sit and wait until the app receives the next location event.

With automatic modes switched off, even when bringing the app to foreground, no new location updates are generated.

Pressing the BLUE location indicator initiates a reconnect...the queue is emptied to the server.

For the time being, to avoid the situation, don't switch to manual mode.
I'll have to think of a good solution.
What makes the situation worse is the fact that the application is not active while in background. IOS only wakes it up when a location change happens - which is not happening while you are stationary.

from android.

Comment by sumnerboy12 from Tuesday Jan 14, 2014 at 09:03 GMT

Ok - I can live with that Chris - I was only trying to reduce the number of publishes by setting to manual mode since all I really need is the enter/leave events, but if it needs to remain on auto in order to keep sending messages even when in the background, that is fine. Thanks for the update!

from android.

Comment by jpmens from Tuesday Jan 14, 2014 at 09:09 GMT

Excellent description @ckrey -- I've taken it to the Wiki.

from android.

Comment by ckrey from Tuesday Jan 14, 2014 at 11:14 GMT

What I will do:

a) make sure the app tries to connect in any case when opened in foreground
b) set an alarm if the app goes into background while messages waiting to be transmitted. The alarm will display as a user message. The user may tap on the message to open the and try to reconnect.

from android.

Comment by jpmens from Tuesday Jan 14, 2014 at 11:17 GMT

Excellent. That should cover it!

from android.

Comment by sumnerboy12 from Tuesday Jan 14, 2014 at 19:13 GMT

Great - thanks @ckrey !

from android.