Why the hassle? You can just rename SetVolume
to ui_SetVolume
and call it normally from the background.
Well, I have my player component running in the background process ... so I am making calls from UI to the player (in the itoo service)...
The app that I am converting is specialized URL player (it has an adjustable delay). I am moving the player into the background so it will keep running when UI closes.
I assumed that if I made calls from UI to a player it would go to the player component created in the UI process (which I never intend to use) and not in the one created in itoo via "run x".
Does that make sense? What am I missing?
-Randal
That is the best choice for now, things will get eventually more better in the future.
Hi Michal,
Here's what I have done (simplified it for you). I haven't actually used the "evaluate" for mqqt in my function like Kumaraswamy says but it works.
Hi Jimis, you didnt need to use the evaluate block because later in the procedure you are using the Connect block.
Here you go Jimis, an extension with native Itoo Integration
Hi Michal,
I need you to be more specific, what kind of instability you are experiencing?
Nice! Thanks !
I'm checking it out
Hi, Is there a way use this extension to make an event block like CloudDB1.DataChanged
kept alive in the background and even get the parameter values and use/send them in some other block(ex. TaifunNotification1.Send block)?
My goal is to make an app that retrieves the data that has been changed in a specific CloudDB and then checks if the tag is equal to the current logged in user's account ID(which starts with u-
and the rest is encrypted in AES256), and if it returns true, then send a notification to the user that lasts until the user interacts(click or deletes) it.
Hello @cnitll311, please check this similar tutorial by @TIMAI2 where he demonstrates the use of CloudDB
Here is what I came up with for the UI to determine whether or not the audio Player running in the itoo background service is playing:
Procedure AudioPlayerIsPlaying (returning true or false) is called from the UI which:
- Sets itoo property PlayingStatus to "Unknown"
- Calls SetAudioPlayerStatus to run in background [ [which calls Player.IsPlaying and sets PlayingStatus accordingly ("Playing" or "NotPlaying)].
- Waits (loops) until property PlayingStatus has changed from "Unknown".
- Returns true/false based on new value being "Playing" or "NotPlaying"
Here is AudioPlayerIsPlaying called withing the UI:
...and here is the procedure that runs in the BG:
I have a couple of questions/clarifications:
-
Will this work as I intend it to, returning to the UI caller the current state of the BG player? I am counting on the BG process/service/thread being able to execute SetAudioPlayerStatus while the UI is executing the wait loop. (UI - BG concurrency)
-
I think I have already been told "no", but I ask anyway: is here not some call that could be made within the spin-to-wait loop which would allow other processes to execute, hence be more efficient?
-
Is there a better way to implement this itoo Player.IsPlaying function from the UI?
Kind regards,
Randal
It looks like it should work, you should try it.
There arent many solutions, you may also look into broadcast mechanism, the echo technique. There will be further efforts in the future to solve these specific problems.
Ok. I have attempted to implement a ui IsPlaying function within the itooMusic demo app.
ItooMusic_IsPlaying.aia (4.2 MB)
I added a button to call the ui_ function which sets a temp value in the itoo property, PlayerStatus, and then calls a procedure from the background that checks Player1.IsPlaying and stores a result in the itoo property PlayerStatus (set to Playing or NotPlaying).
The ui_ function then waits, repeatedly checking the itoo property - PlayerStatus, until it is updated and then returns the updated value to the ui caller. The result is displayed in a label.
Note that on occasion, when the ui_ procedure fetches the PlayerStatus, it finds nothing there (value TagNotThere).
Any ideas? What have I done / not done?
-Randal
I have found that by changing the wait looping condition from:
to:
... the value "TagNotThere" does not terminate the wait, and the problem does disappear.
But I wonder, is there reason to believe that this is a valid fix or is it just an "apparent" fix that is not valid?
-Randal
It seems you are over complicating a very simple problem.
If I were you, I would start a clock in background that times every 5 secs and queries properties/states of all the important components in background and write it to Itoo storage. You may also update the UI from this clock event. And if the clock does not update the storage values, you can deem that the background is not operational.
But wouldn't the read from the UI of these itoo variables also be subject to the same occasional "valueIfTagNotThere" return as the test case (ItooMusic_IsPlaying)?
Does the test case not show that when the UI reads (Itoo.FetchProperty) from itoo storage, that if the background service is modifying the value, that neither the value being updated from nor the value being updated to is guaranteed be returned - but instead, sometimes, valueIfTagNotThere is returned as if the property/variable had never been written (never existed)?
If this is the case, then wouldn't the same thing happen (UI read sometimes getting valueIfTagNotThere returned) if the storage was being updated by the background clock and read by the UI?
???,
-Randal
PS Please excuse my long sentences. I hope they are punctuated well enough to make sense
That's just a whole lot of complication my friend. There are more than enough functionality offered by the extension to solve this problem, but you seem to be wanting the best-in-class-sophisticated solution.
What's the problem in simply writing a log property? Why would there be valueIfTagNotThere? This dosent make sense.
Just do these things and you should be super fine:
- Start the background
- Start a timer clock for every x seconds
- When timer, save a list to Itoo storage, a list comprising of all the properties of all the components.
list = [list_update_time, element1_timer_playing, element2_timer.... ] - Now query this in the user interface, if last update time greater than y time, that means background stopped.
Ah. I like the idea of storing a single element which is a list which contains a time ....
So, if the tag is present, a list will be returned - the validity of the content can be assessed by looking at the list's time component.
It still seems to me (perhaps you can explain to me otherwise ) that there is a possibility, demonstrated by the test case, that the UI will FetchProperty and nothing will be there, thus the valueIfTagNotThere value will be returned...
But I can watch for that and ignore it if it happens, continuing to FetchProperty until a list is returned with a time is later than the time of the first UI request (the first FetchProperty of the list). If it is then use the values stored in the list, if not keep fetching. If the time on the list does not advance with the passage of "x" seconds (the timer interval), then the timer has stopped for one reason or the other (no process or timer not enabled).
Does that sound good? or am I still on the wrong track?
A time-tagged list generated by a clock/timer is a great idea!
Thanks,
Randal
Yes you can do that
However you should not use a while loop for that...
Aa far as I understand you just could just use an if statement ...
If it is a list
Then do something
What about considering all the suggestions from @Kumaraswamy and providing an updated screenshot?
Taifun