Open Source • Background Tasks: Itoo 🚀

[Randal_Andress]

Taifun,

Thanks for your thoughtful replies... this helps.

I do not want to make CallBackgroundProcedure or ui_wrapper calls unnecessarily to call between UI and itoo service, if I can just reference the one Clock from both.

@Taifun

@Randal_Andress

can I enable that timer from Screen1.Initialize by:
clkDelayStart.Timer_Enabled = false?

First set the time interval and to enable the clock set TimerEnabled to true

The general question is "can I set/get properties from a single Clock both from the UI and the itoo service (so long as I reference the Clock in the CreateProcess procedure)?"

@Taifun

Only one event will get processed depending on the app being in the foreground or background
I'm not sure, if both will be executed in the foreground... better to test this or wait for an answer from @Kumaraswamy

I do not think this is something I would ever want to depend on, but it would help (at least help my understandind ) to know. I can imagine that if the UI is in the foreground/active when the timer fires that there may be no way to predict which "event" is ahead in some queue. So @Kumaraswamy, if there is no answer , I understand.

Thanks again,
Randal

[Randal_Andress]

@Kumaraswamy

Principles of design and usage

To run blocks in the background, you code the blocks normally then use Itoo to execute them.
There are a few things you need to follow while you are using Itoo:

Usage

• Before you try to do something with Itoo, first get it working normally.
• Do not use global variables, or try to access/set them.
• Do not use user interface components such as Label, TextBox or even Notifier since there is no interface in background.
• You cannot use Tiny DB, alternatively you are supposed to make use of the similar storage features Store/Fetch property blocks offered by this extension.
• For the main background procedure, you need to include an argument "x".
• You cannot use normal Event blocks in background, use RegisterEvent block to listen to component events.
• You cannot run more than one foreground or background service.
• A component does not get created until you touch any of its block.

Are these usage rules meant only for components, blocks, and procedures accessed and executing from/in the itoo service?

[I ask because, while I am making extensive use of the itoo store/fetch property facility, I am also using TinyDB but from/in the UI only.]

If that is the case, is it permissible to use global variables if they are only accessed from/in the UI?

-Randal

[Taifun]

Yes of course
Taifun

[Randal_Andress]

Good! I had misunderstood this...
Thanks,
Randal

[Randal_Andress]

@Taifun

@Randal_Andress

If I have a clock named clkWallClockTime is it proper to reference it both from the UI or the itoo service by the following?

Yes you can
You could take the the current time from any clock, no separate clock necessary

@Randal_Andress

The general question is "can I set/get properties from a single Clock both from the UI and the itoo service (so long as I reference the Clock in the CreateProcess procedure)?"

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

[Taifun]

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

[Randal_Andress]

@Taifun

To understand what is happening it is advisable to create a test project... I did it for you below

Well, how very kind of you to do this for me!!...

Let me study and play with it for a bit...

THANK-YOU,
Randal

[Randal_Andress]

@Taifun

There is a Clock1 running in the foreground and a Clock1 running in the background running independently from each other

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

[Unk_Beats]

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

[TIMAI2]

You need to add a variable x to your doBackgroundWork procedure.

[Unk_Beats]

just adding it will make it work ? i will try and see

[Unk_Beats]

And yes it worked thanks for the help mate

[Randal_Andress]

@Kumaraswamy,

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

[Kumaraswamy]

Yes, it is the latest version (built on march 2nd). I have likely forget to bump the extension version.

[Randal_Andress]

@Kumaraswamy

Yes, it is the latest version

Thanks,
-Randal

[Randal_Andress]

[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

[Kumaraswamy]

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.

[Randal_Andress]

@Kumaraswamy

Hi Randal, there is a fundamental mistake that happens while calling the ui_DumpItooProperties from the Itoo Service.

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

[Kumaraswamy]

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.

[Randal_Andress]

@Kumaraswamy

The problem is that you are trying to pass a component to a procedure starting with ui_xxx

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