Well I am sure about that.
You can't get it.
2 Likes
so you mean there's no solution sir.
I have a timer that always counts up, which should also count in the background. I added the extension for that. But the problem is that it doesn't always work, so sometimes it works great, sometimes it doesn't. If the screen is on but I'm not in the app, then it works too. It just doesn't work when the screen is closed.
Show your blocks.
And what do you mean by "background"? Is the app closed or just not visible but not closed?
2 Likes
First, thanks for the quick response.
I'm making a time tracking app that counts and saves the working hours - a so-called time clock. So the timer should always run when the screen is on but I'm out of the app when the screen is closed etc. So the timer should always run.
I would like to create an app like this:
The Blocks:
Back Pressed:
Back pressed is for not being able to push back.
EingestempeltTxt:
Stamped Text is a label that shows when one has Stamped.
EingestempeltBtn:
Stamped Button is a TimePicker where you can optionally enter when you stamped.
Clock2:
There are three texts in Clock2. One for seconds, one for minutes and one for hours. If seconds is greater than 59, than seconds is reset to 0 and text minutes is plus 1. If minutes is greater than 59, than minutes is reset to 0 and hours of text are plus 1. And with TinyDB, the working hours are saved so that you can later see how long you worked, etc.
Initialize:
When initializing, Clock2 is set to True so that it should count up as soon as it starts, like other time clocks.
The question is, is it even possible to create such an app here? If not, it is possible with other similar programs such as Kodular etc.
Since the app has to be open (active) at the time of clocking in and clocking out (taking timestamps), I don't see any problems implementing such apps with AI2 (or Kodular, Niotron, ...).
Try this simple app (initially just for one day and one break / pause):
1 Like
Of course, it should be "Clock in" 
I changed / updated it.
Incidentally, this has nothing to do with my extension.
Thanks again for the answer, it helped. But I've now switched to Kodular because I found it easier. There is an item called ListView Image and Text. A new item is created with every click on the stamp button, which also works perfectly. The problem is, every time the screen is restarted, the list view is emptied because it is not saved. I've searched the internet but haven't found anything on how to save a ListView. Can you please help again 
? Thank you and have a nice day.
If using Kodular, then ask on the Kodular community.
Does my test app (APK) work for you (also after restarting the app)?
1 Like
Yes, it worked perfectly.
I asked here because I saw in the Kodular Community that Anke had answered a few topics.
1 Like
There is good reason, 1 - we then know which distribution you are using, 2. AI2 and Kodular are different in many ways, what works on one does not necessarily work on the other. This is why it is best to ask on the correct community.
4 Likes
We should move this into a new topic, because it has nothing to do with my extension anymore.
2 Likes
really Thank You very Much 
1 Like
The Android Developer link pretty much describes the distinction between onPause and onStop.
Essentially onPause is not killable by the OS, but onStop is.
So do anything important in onPause, as onStop may not fully execute....
Did you check it yourself?
I had tested it extensively on dozens of devices at the time, and as I already pointed out, after on Pause (at least on non-tablets) onStop is always executed. As you can see in my tests, I was able to store something with onPause as well as with onStop. However, it may be that this behaves differently on tablets (as Evan Patton said; I haven't tested it).
No, I did not test it myself, but I do believe what I read on the Android Developer page (which is linked to right at the top of your extension description)
I'm NOT saying onStop never happens straight after onPause, but the docs say it is possible that onStop may not reach the end of execution.
The OS may destroy the app before it concludes - this may not always be the case, and hence why it appears to be OK to use onStop.
BUT as they do document it, I'd consider that it is risky to reliably use onStop for important things like saving configs, but onPause will not get aborted by the OS so that's where it should take place.
A distinct but important difference I'd say 
Cheers, Ray