Good! I had misunderstood this...
Thanks,
Randal
Does the same apply (direct access of a single component from UI and itoo service) for a Player component as it does for a Clock?
For some reason I have been under the impression that when a Player is referenced within the itoo CreateProcess procedure, that a distinct and different Player is "instantiated" - one which is separate and independent of the one which exists in the UI - which can must (and may only) be accessed from the itoo service.
So that, in order to interface with a single Player from both UI and the itoo service, one must call a ui_ prefixed procedure from the itoo service or call an itoo CallBackgroundProcedure from the UI (or use a messaging mechanism) in order to control a single Player, which exists only in either the UI or in the itoo service.
Is this correct? Or, for example, can a single UI Player component be referenced directly from the itoo service as well as being referenced from the UI (the way a Clock component can)?
-Randal
To understand what is happening it is advisable to create a test project... I did it for you below
There is a Clock1 running in the foreground and a Clock1 running in the background running independently from each other
The counter in the foreground works only if the app is in the foreground. Timer interval is 5 seconds. After closing the app it starts from 0 again.
The counter in the background starts after clicking Start button. It increments each 2 seconds being the app in the foreground or in the background. In case the app is in the foreground, the current background counter value will be displayed in a label.
randall.aia (94.1 KB)
Taifun
2 Likes
Well, how very kind of you to do this for me!!...
Let me study and play with it for a bit...
THANK-YOU,
Randal
1 Like
Indeed - two instances of Clock1, one in the UI space and the other in the itoo (background) service space.
Just to confirm the complete separation of the two clocks "address" space, I added reading and displaying the interval and enabled properties before they were set in both spaces.
What I found for the Itoo Clock1 was surprising. Before procedure "run" set the properties, they were not according to the initial values given in the "Designer" view which were 1500 msec and false, but were 1000 msecs and true.
Not a real problem, since initializing them in run is sensible and probably good practice, not counting on any design initial values. But it was surprising.
As far as the question about Player components, I realized that the app discussed in post #808 demonstrates the independence of Player components with the same name in both UI and Itoo service environments.
Thanks for your help me sort this out.
Kind regards,
Randal
1 Like
can anyone help please i don't know what's wrong but it does not work for me.
i get the itoo notification that the process is working on the background but i don't get any notification from Melon, when i click Button2 the notification appear. but with itoo not working when the app killed
You need to add a variable x to your doBackgroundWork procedure.
2 Likes
just adding it will make it work ? i will try and see
And yes it worked thanks for the help mate 
1 Like
I want to be sure I have the latest itoo version...
I downloaded it from the link at the end of this initial itoo post and installed it...I expected the info to show "Sky 4.4.1"
The file size on windows is 93,033 bytes.
Is this the latest version? (4.4.1?)
Kind regards,
Randal
Yes, it is the latest version (built on march 2nd). I have likely forget to bump the extension version.
Thanks,
-Randal
1 Like
[Note I edited this post to change the logcat excerpts and made other minor changes/corrections. @Randal_Andress ]
I am getting a java Uncaught exception that I cannot track down which seems to be from a call to Itoo.FetchProperty.
9004 9004 E Form : Uncaught Exception
9004 9004 E Form : java.lang.RuntimeException: Error receiving broadcast Intent { act=UI_ITOO_X_RECEIVER flg=0x10 pkg=appinventor.ai_randal_andress.DelayDio3_v0_4_badURLcase (has extras) } in xyz.kumaraswamy.itoox.UIProcedureInvocation$1@91afb98
9004 9004 E Form : Caused by: java.lang.RuntimeException: com.google.appinventor.components.runtime.errors.YailRuntimeError: The operation FetchProperty cannot accept the arguments: , [xyz.kumaraswamy.itoo.Itoo@3d8310b]
It would seem that FetchProperty is being called with bad/null arguments:
" , [xyz.kumaraswamy.itoo.Itoo@935a46]" but I cannot see where this is happening in my code 
Before I go any further, I want to apologize for the size of this case. If you have any problem spotting the problem, I will try to give you something smaller. I plan to be working on that while you are looking at it.
I have modified the app mostly by making some components invisible and by adding a toggle button which switches at runtime between a state which causes the error and another which does not cause the error (by not making the call to ui_DumpItooProperties)
The error occurs when procedure ui_DumpItooProperties is called from Screen1_ErrorOccurred.
The Screen1 error is caused intentionally by attempting to set a player source to an invalid URL. This is an error from which the app needs to be able to recover - and which it does as long as ui_DumpItooProperties is not called from the Screen1 error handler in the itoo service (background).
This recovery can be demonstrated by default in the test case by clicking
"Select a Station"
Then by selecting "WTWX ..."
After a few seconds the error is caught and presents two notification boxes to be dismissed.
To illicit the error, tap the button
"Dump=No"
which will then change to
"Dump=Yes"
and repeat: Select a Station, WTWX.
This time control is not returned to the user until a timeout generates a notice/choice to wait or terminate the app.
The "DumpItooProperties" button may be clicked at any time before selecting a bad URL, and if "Dump=Yes", it will display each itoo property=value in the space at the bottom of the screen.
I am attaching excerpts from the logcat output for each case. The "-1" named files contain only selected lines from the larger contiguous files.
the "Dump=No" case:
delaydio-badurlcase-nodump-1.txt (474 Bytes)
delaydio-badurlcase-nodump.txt (939.4 KB)
and the "Dump=Yes" case:
delaydio-badurlcase-dump-1.txt (2.6 KB)
delaydio-badurlcase-dump.txt (938.3 KB)
I believe the blocks file is too large (~5 Mbyte) to upload.
Here is the .aia
DelayDio3_v0_4_badURLcase.aia (199.5 KB)
Again, I plan to work on a smaller reproducer, but it may take a bit...
Thanks,
Randal
Hi Randal, there is a fundamental mistake that happens while calling the ui_DumpItooProperties from the Itoo Service.
I need to first explain you how the call is redirected from the Itoo thread to the application's UI thread.
Itoo looks for calls on the procedure names starting with ui_. If it intercepts such a call, it will begin JSON serialization process of the arguments provided. We use App Inventor's own JSON serialization methods that are fine tuned for App Inventor data types.
It is important to note that, during this step, a runtime object (like the ItooPlayerService) cannot be serialized for transportation. Instead what the Application UI thread receives is a string of the component (package_name.Itoo@xyzdata).
Think of it as attempting to store an App Inventor component in a TinyDB. It does store, but it's not the component. It's a value of the .String() method called on the component.
Hmmm... I do not think I understand: Does this mean that this serialization failure occurs on any ui_xxxxx procedure call from the Itoo service? surely not, because that is what the ui_ magic is for, correct? 
Or is there something about the ui_DumpItooProperties procedure itself OR the call site from within the Screen1_ErrorOccurred hander that causes this to happen?
Is this something that is likely to be changed/fixed?
Could I work around this by using a ItooPlayerService.Broadcast message from the Screen1_ErrorOccurred procedure that is picked up by the ItooPlayerService.BroadcastEvent which would then call ui_DumpItooProperties? Or would that cause a similar problem?
-Randal
Hi Randal, this is a technological limitation and cannot be fixed.
The problem is that you are trying to pass a component to a procedure starting with ui_xxx. That call is not a normal one, only the standard App Inventor data types are allowed.
Ahhh... Now I understand! It is the second argument/parameter to ui_DumpItooProperties that is the problem!
In my case then, since there is no need for the argument - there is only one itoo component - I only need to eliminate the parameter and simply "hard code" ItooPlayerService into the ui_DumpItooProperties procedure, correct?
-Randal
1 Like
Well... that was only part of the problem. I was also attempting to pass a label component, which (of course) failed for the same reason. Once I got that corrected it works just fine. Thanks for the help!
BTW, I did not find a way to remove an argument from a procedure without causing all its calls to have arguments removed throughout the app. Since there were several argments and several call sites, I just renamed the arguments and ignored them.
Any advice as to how to easily remove arguments from a procedure so as to cause minimum disruption at the call sites?
-Randal
1 Like
I asked this question on the general discussion forum:
Evidently there is not presently a better way...
I went ahead and submitted a feature request
-Randal
1 Like
MelonNotification • Various styled notifications + Itoo