You are currently saving an empty list in your code.first fill a list,then save it
1 Like
@SlowBro There is a lot of confusion in your blocks, it looks like you are putting blocks together without understanding what you are doing
Have you seem my shake it example? Run app in background, that fires an alarm whenever phone is shaking - #4 by Taifun
Use that example and restart from there
You create the process only once on button click
It starts the background process... somehow the process must start...and after starting the process then the sensor is activated to listen in the background
Taifun
@Jimis your blocks are mostly ok, you are adding item "1" to the list, you only forgot to store the new list via StoreProperty method again, so later you see the difference after button click in the user interface... don't forget to open the listview there
Also there is no user interface in the background
EDIT: what you are doing is no real background processing, you are only creating the process, so this is not really a test if something is working in the background or not...
Taifun
Thanks !
Oh I see, thank you, I was following an example from a different discussion. If I may ask as well, can itoo fetch a local variable in other procedures from another procedure if it is stored in itoo? Thanks.
Use StoreProperty/FetchProperty methods
Taifun
1 Like
Because at the time you are creating the process you did not get a gps signal
Also what is localhost124?
Generally to get location data in the background requires background licatuon permission. The locationservice extension is able to do it App Inventor Extensions: Location Service | Pura Vida Apps
Taifun
Can you elaborate on this?
What would you expect to happen?
Status is always unknown because unknown is a static text in your procedure
EDIT: do you expect to get both evemts twice (one from the background, the other from the foreground?
what do you get if you deactivate the 2 phone call events (foreground)?
For a more useful test let me suggest to do a background test, close the app and use the Notifier Loginfo method for debgging and check the log using logcat
Taifun
Thank you for you helpful comments and questions - And I am sorry that I just noticed your post yesterday 
First of all, I apologize for this sloppy example/case. It was based on a test case that contained two Player components: one in the UI and another in the Itoo process. I suppose I was attempting to show that the UI Player PhoneCall events responded to a phone call but the Itoo events did not...
I would have expected the PhoneCall events that were registered in the Itoo process to respond to the call and not the UI built-in blocks...however because of how it actually behaved (the UI built-in events responded in place of the itoo registered events, it was confusing..
Yes - another sloppy job on my part... Because the text block "Join" would not accept the "status" variable, rather than solving that problem, I just put in the "constant" value... I have now decoded status using this procdure/function:
The version I am posting below is (hopefully) more useful and easier to understand.
ItooMusic_orig_PhoneCall_posted2.aia (4.2 MB)
...and the blocks:
I have done separate tests for both of these variations. In all tests the app was started, then the player started, then a phone call was made but not answered - caller hangs up. Here is a brief description and summary of results.:
- With both sets of events present in the code (as posted here), logcat was captured for two cases:
a) UI remained active/visible: the UI event blocks responded to the call/hang-up:
ItooMusic_orig_PhoneCall_posted2-UIactive-both.txt (490 Bytes)
b) UI was exited: no PhoneCall event was called:
ItooMusic_orig_PhoneCall_posted2-exitUI-both.txt (147 Bytes) - With the standard PhoneCall event blocks disabled in the UI/foreground code, logcat was captured for two cases but no PhoneCall events were called in either case:
a) One with the UI remaining active:
ItooMusic_orig_PhoneCall_posted2-UIactive-X.txt (228 Bytes)
and
b) the other having exited the UI:
ItooMusic_orig_PhoneCall_posted2-exitUI-X.txt (228 Bytes)
It appears that somehow the Itoo registered events are not being associated with the player running in the Itoo process - they are not called in any of the test...OR perhaps the player is not actually running in the Itoo process???
Are the process/thread ids from the logcat output of any use in determining this? Any test I can do to gather more information?
-Randal
the PhoneCall component was not written to be running while the app is in the background...
as you can see the phone state listener will be unregistered while closing the app, see the sources here appinventor-sources/appinventor/components/src/com/google/appinventor/components/runtime/PhoneCall.java at master · mit-cml/appinventor-sources · GitHub
@Override public void onDestroy() { unregisterCallStateMonitor(); }
let me invite you to test my new phone state listener extension which keeps running while the app is in the background... I will send you a PM soon...
Taifun
why doesnt the "notifictation" get called when i the clouddb data does change?, the process runs fine but the notification doesnt work
Did you ask for post notifications permission?
Taifun
Yes
TinyDB does not work with Itoo, please use Itoo's own Store/Fetch property blocks.
Why are you passing a random integer to code? It must be 2.
Try the example in the first post:
i did already try 2 before the random integer, but it still doesnt work
See here:
oh i found my error, i tested my app by building it to an apk and another i tried from companion. But when i tried it on another phone the notification now happens, thankyou
1 Like