HttpClient infinity Timeout?

Ionic Framework ionic-v3
1

Hi, I’d like to tell you a quick story about my question, as I’m just wondering why is it so.

I’ve made a basic tracking app including backgroundGeolocation and I then POST all the location details to a FQDN website using HttpClient. It’s working fine and seems to be accurate enough.

Tonight I went for a walk about my town lake, and the tracking facility worked fine, for about half of my trip around the lake.

I know this, because I came home, looked at the server part and saw the tracks on the map of where I had gone - but only half of the track.
So, I opened the app, and then, it proceed to uploaded the rest of the tracks, and voila, the rest of the track appeared on my server.

My question is related to HttpClient, and what the timeout is, or if the app just keeps the data in an infinite holding pattern until it gets suitable reception and can then upload the data?

It was just weird behaviour, and i don’t think it is related to background/foreground geolocation.

I’m doing nothing special with the upload code. Should I be running a timeout, or just doing it this way?
Is the built-in Post method better? I think this way that I’m currently doing I’ve got (seemingly) more control over things.

I’m just after a why, or is it the best practice.
Thanks.


  this.httpClient.post(URLlink, trackJSONdata)
  .subscribe(data => {
    this.data.response = data["_body"]; 
  not-exist-on-type-response
  }, error => {
    console.log("Oooops!");
  });
2

That’s a good question, and hard to answer directly. What I can say is this:

I often use the “message-in-a-bottle” metaphor to describe one way to think about asynchronous programming. HttpClient requests are a replicator combined with a bottle cannon. Once you queue up a request, it just sits in the cannon until somebody subscribes to it. At that point, the ordinary course of events is that the request goes through, the returned Observable emits the requested response, and then completes. The cannon gets packed up and put into storage. However, if something goes wrong, instead of the ordinary response, you get an HttpErrorResponse, and the cannon stays ready to fire further bottles, but won’t do so until you ask.

So there isn’t a timeout, and I guess “infinite holding pattern” isn’t a bad description. You’re in total control of what happens next, though. If you subscribe again to the same request, it will fire again at that point. Rinse and repeat until the request succeeds or you give up on it.

As for best practices, two important things about the code snippet you posted:

  • Never access anything that starts with a leading underscore from outside the class that defines it. Regular readers of this column are probably sick of hearing me rail about how much I hate JavaScript, but this is another terrible thing about it. It has no proper access control, so we have to rely on convention. In a sane language, you would not be able to access _body; in JavaScript-land the language won’t save you from yourself: you have to abide by the convention and agree not to.
  • post (and any other HttpClient function that returns content) takes a return type parameter: this.http.post<ReturnedThingy>(url, food) will give you an Observable<ReturnedThingy>. You virtually always want to take advantage of this.
1 Like
3

Thanks for your prompt reply. I’ll mull over this answer and see what I can think of how best to reply. :slight_smile: