Android Question [SOLVED] HttpJob not working after app is swipe-killed and restarted

[Sandman]

I have a strange problem with HttpJob not working in a very specific case. I feel there's probably some concept here that I am unaware of, but I can't figure out what it could be. (Nor was I able to find a forum post about this, sorry if I missed it.)

Once I start my app, the genericRequest below is called every ten seconds via a timer, and it works like a charm.

But if I put my app in the background, open the Recent apps and swipe-kill it, and then re-open the app from the Desktop, it fails. (If I then do a Force close of the app and start it again it works fine.)

I've read Erels post The result of swiping an app from the recent apps list so I understand that there's some service stuff still running (perhaps) in the background. And when I force close the app I also kill that. Fine, but how does that in any way affect my ability to use HttpJob??

I should also say that I'm running my app as Release, with BridgeLogger enabled. And I control the receiving server so I've verified that it doesn't get any kind of request in this situation.

This is my code. I have verified that the incoming values are fine. (This means they are identical to when the request works.) In the log I can see GENERIC: 1 just fine, but GENERIC: 2 never happens, even after 30 seconds (or ten minutes for that matter).

Any ideas?

Private Sub genericRequest (url As String, values As Map, files As List) As ResumableSub

    Dim job As HttpJob

    job.Initialize("", Me)
    job.PostMultipart(url, values, files)
    job.GetRequest.Timeout = 5000 ' This value doesnt affect anything for me

    LogColor("GENERIC: 1", Colors.Cyan)

    Wait For (job) JobDone(job As HttpJob)

    LogColor("GENERIC: 2", Colors.Cyan)

   ' More code goes here, not displayed in the post

End Sub

 

[Erel]

Where is this code placed? In a service? Is it a foreground service?

 

[Sandman]

It's in a standard class, dim'd and inited in Starter. The sub is called from Starter. (I've added checks for IsInitialized, and it always is.)

 

[Erel]

When you swipe an app that doesn't have a foreground service, the process is killed. This means that when it is later started it starts from scratch. You can see that by clicking on the app icon. FirstTime in Activity_Create should be true when you restart the app.

Can you post the logs?

 

[Sandman]

I'm not sure I understand what you're saying.

If I force close an app, all traces of it seems to be gone. (If I bring up the UI again where I can force close it, the button is disabled - so it's actually showing if the app is around or not.)

If I swipe-kill an app it seems to be in a sort of half-closed state (like you described in your post I mentioned initially, I suppose). It's gone, but if I bring up the UI where I force close the app, it's possible to do so - the button is enabled.

So there seems to be a difference between swiping and force closing. And I'm not sure what you mean by "clicking the app icon"?

Here's a part of my log. The first part is me starting the app after a fresh install, so nothing old in memory.

STARTING APP: Service_Create ================== 2017-09-27 21:33:52
GENERIC: 1
** Service (starter) Start **
*** Service (httputils2service) Create ***
** Service (httputils2service) Start **
** Activity (main) Create, isFirst = true **
** Activity (main) Resume **
GENERIC: 1
** Service (httputils2service) Start **
GENERIC: 2
GENERIC: 2
** Activity (main) Pause, UserClosed = false **
** Activity (actworking) Create, isFirst = true **
** Activity (actworking) Resume **
GENERIC: 1
** Service (httputils2service) Start **
GENERIC: 2
** Activity (actworking) Pause, UserClosed = false **
*** Service (starter) Create ***

...and now I've put it in the background and swipe-killed it, and this gets added to the log instantly, before I even start the app again...

STARTING APP: Service_Create ================== 2017-09-27 21:34:11
GENERIC: 1
** Service (starter) Start **
** Service (starter) Start **
sending message to waiting queue (CallSubDelayed - SubmitJob)

...and if I now launch the app again, this is logged...

** Activity (main) Create, isFirst = true **
** Activity (main) Resume **
GENERIC: 1
sending message to waiting queue (CallSubDelayed - SubmitJob)
** Service (httputils2service) Start **

I noticed that the httputils2service wasn't started after the swipe-kill, so the last line in the log above is actually from an added StartService(HttpUtils2Service) first in my genericRequest - it did no difference.


And I forgot to mention that I have enabled android.app.Service.START_STICKY in my Starter:

#Region Service Attributes
    #StartAtBoot: False
    #ExcludeFromLibrary: True
    #StartCommandReturnValue: android.app.Service.START_STICKY
#End Region

Something else I forgot to mention: I'm not using the standard library for OkHttpUtils2. I needed the actual status code returned from the server so I had to adjust it according to your instructions in another post here in the forum. (Wish)

 

[OliverA]

Does this particular app require your modded OkHttpUtils2? I guess in either case, for testing purposes, you could try the standard OkHttpUtils2 first and go from there. And how about posting a "watered" down app that has the minimal functionality that reproduces this error, so if others would like to see if they can reproduce your issue, they can (acknowledging that they would have to user their own backend HTTP server for testing).

 

[KMatle]

I never had an issue like that (and I've tested, and swiped all of my apps a thousand times).

Check if you release the job. I can't see it in your code.

 

[Erel]

And I forgot to mention that I have enabled android.app.Service.START_STICKY in my Starter:

This is a mistake. Use a different service for this.

The starter service should never be explicitly started. Setting it to be a sticky service will cause it to be explicitly started by the OS.

 

[Sandman]

This is a mistake. Use a different service for this.

Well, removing that solved my problem instantly - great!

I've seen that the Starter shouldn't be explicitly started, but I just didn't connect the dots that the sticky flag caused that to happen. I think I made a bad assumption that the OS started it in some other magical way that differed from when the user starts the app.

Very nice, thanks.

 

[Sandman]

This has been solved, but for completeness and for future readers wanting to get the full picture, here's answers to questions asked:

Does this particular app require your modded OkHttpUtils2?

Yes it does, as I need the actual http status code received. If i didn't need that, I would use the standard library. (The best code is the one I don't have to write so I'm all for keeping down my codebase if possible. )

Check if you release the job.

I do, it's just not visible in the code I posted.