App Closes detection 2

MIT App Inventor Help
1

Hi.
From a topic with the same name (now closed) I learnt that AppInventor has no block capable to notice that an app user is closing the app (unless they do it in the expected way: By pressing the "back" button from Screen1).
They also explain that there are extensions to help with this issue (but using them might be a problem if you want to publish your app in GooglePlay later).
Detecting the app closing is something I really need, because inadvertendly closing one of the apps that are communicating with the server, could make the server crash.

I'm thinking on a work-around:
Instead of running all my app blocks in Screen1, maybe I could put almost all of them in a 2nd screen.
So before closing the app, hopefully there will happen a Screen1 .OtherScreenClosed event.
My doubt is:
Will this event also trigger if the user closes the app from the recent open apps' manager menu?

2

The options for closing an app:

  1. Button with "close application" block
  2. Back button of the device
  3. Home button and removing the app via the task manager.

The last one cannot be prevented.

1 Like
3

Thanks Anke
Is what I feared: That it couldn't be prevented, nor noticed by the app to do something (like warning the server) before closing.

4

you might want to try the tools extension together with its ActivityStateChanged event

if state = "stop"
then do something

Taifun

2 Likes
5

Of course, I had thought of this and also of checking whether the device was switched into idle (sleep) mode (using my IdleMode extension). However, both of these things happen when the app goes into the background, i.e. before the app is closed via the task manager, and so does not change anything.

However, if the server connection should already be interrupted when the app goes into the background, this could of course be achieved this way. But then the app would no longer work in the background (= app not visible).

6

You can check this also using my small ActivityLifecycle extension.

Btw, in my tests onStop is always triggered after onPause.

7

Thanks to all for your kind explanations and cute extensions.
I believe that I'll rather implement a KeepAlive communication protocol between apps and server, to detect inactive apps.
I Know how to do this using just AppInventor blocks.

8

Can you redo the server code to make it more pseudoconversational ?

That would reduce the need for your app to tip toe around the server.

9

Thanks for your advice, Abraham.

I had to lookup in Wikipedia to know what pseudoconversational means, but in fact that's quite the way the server works (just acts upon an app message, replies if required, stores the new status of the app's request, and goes to serve the next message from other app).

The problems is, the server is arranging dinamically the sharing of car trips between each car driver and one or several passengers, for the whole duration of the trip, including the sharing of trip expenses according to each one’s trip lengt and the number of occupants in the car along the trip.

If one of them happens to close the app during the trip (by other way than pressing the "back" button), better than the server knows that won't receive further updates from this app, neither the app will longer receive server messages.

I think a KeepAlive routine will be required. Especially in case a mobile runs out of battery.

10

Maybe the shared data base structure can help your problem if it is atomic in its description of the trips?

  • driver
    • shift 1
      • shift start info (odometer, timestamp)
      • shift end info (odometer, timestamp)
      • passengers
        • passenger 1
          • pickup event
            • odometer reading
            • timestamp
          • drop off event
            • odometer reading
            • timestamp
        • passenger 2
          • pickup event
            • odometer reading
            • timestamp
          • drop off event
            • odometer reading
            • timestamp

Lost connections would be reflected in the shared data base as missing events

  • (picked up a passenger but never dropped them off before end of shift.)
  • (dropped off a passenger but never logged picking them up)

It would be up to the driver's app to fill in the blanks, I imagine.

11

If you manage to know that the app of the user of one type is no longer available to communicate a trip event, then you can arrange an alternative procedure, or communication protocol, for the server to tell the other type of user to do it instead.

12

The time-based data base structure I mentioned above could be augmented with location data, both in the driver's route history ((location, timestamp)...) and in the passenger (and prospective passenger) pickup and dropoff requirements.

If a passenger dropoff happens at a location matching another passenger's dropoff location in the same car, and both have been picked up, then it could be inferred that the second passenger has been dropped off at that location too. (excluding cases of sleeping kindergarteners in the back of the school bus).

1 Like