Open Source β€’ Background Tasks: Itoo πŸš€

Debug your logic using Logcat. To find possible errors of your blocks in the background, let me suggest to filter the logcat output for the tags, Notifier , ItooCreator and System.err


I think I have done about all I can to sort this one. I may have one more idea in me :-), but I am not hopeful :frowning:

Below find the updated the test case code and blocks image.

I have also included an annotated logcat output filtered on several character strings grep -e %%% -e TimerInterval -e Notifi -e System.err -e CallbackButtonAction .

The notations in the logcat files (included below) trace the following behavior:

  1. App "Start" pressed
  2. "> adb logcat" begun
  3. Timer fires after initial "Start" interval of 20 secs (reschedules for 20 secs)
  4. User selects Notification "Half" (next inerval = 10 secs)
  5. Timer fires after another 20 secs (reschedules for 10 secs)
  6. User selects Notification "Half" (next interval = 5 secs)
  7. Timer fires after 10 secs (reschedules for 5 secs)
  8. [no user input to Notification]
  9. Timer fires after 5 secs (reschedules for 5 secs)
  10. [no user input to Notification]
  11. Timer fires after 5 secs (reschedules for 5 secs)
  12. User selects Notification "Double" (next interval = 10 secs)
  13. [With no further user input, within ~30 ms Calback processing executes doubling the interval twice (10s ecs x 2 x 2 = 40 secs)
  14. Timer fires after 5 secs (reschedules for 40 secs)
  15. App "Stop"
  16. adb.exe logcat - stopped

See attached -hidden.pdf file.
DataMinder-wlogs3_20240210-%TimerNotSysCallonly-hidden.pdf (82.4 KB)

To see intermediate/additional filtered logcat entries, see un-hidden rows via:
DataMinder-wlogs3_20240210-%TimerNotSysCallonly.pdf (97.7 KB)

Unfiltered logcat entries are hare:
DataMinder-wlogs3-51-53.txt (71.2 KB)

What I cannot fathom is #13, above: why does the ButtonCallback execute two additional times when there is/was no further user input to the NotificationAction window.

It is as if, when no user input was made (items #8 and #10) that these CallBack "events" were held and then were executed immediately after the expected one (#12), with the last user selected action Button (Double) being used. I have tried many ways to cancel the NotificationAlerts that were "stale" not responded to (see blocks). But they seem to stick around and then mis-behave.

Any help would be appreciated,

DataMinder_ButtonCase.aia (903.6 KB)

I would advise you to not use the CallBackButtonAction feature for now, we are not sure how it behaves in the background.


PS: I'm sorry I'm preparing for my exams right now and cannot reply you.

What would be the "normal" way to communicate a change in parameters to a background process that requires periodic user input ?

The blocks below show what I did that seems to avoid the multiple-queuing of unwanted Button-actions. Note the use of itoo1 database item "ActionNotificationQueued" as a flag in the notification sending procedure (LargeIconNotificationWithOptions), and in the button callback processing procedure (NotityStyleCbButtonProcessing) .

It allows only one outstanding notification to be "queued" (flag set by b/g timer processing). If it does not get cleared before the next periodic cycle (via ButtonCallback processing) , the notification is canceled, and the flag is cleared. Then on the following periodic cycle a new notification is issued.

Since I do not understand how all this works :slight_smile: I suppose this may not be bullet proof. But I am hoping that by allowing an entire period/cycle to pass with no new outstanding notification, there will be time for any CallBack processing already started to complete, awaiting the next cycle.

Another approach (that I have not tried) is to post the same notification for user input when the b/g process is started, setting the "queued" flag. Then use Notifer (not reliable?) and SimpleToast to periodically notify the user when input is suggested (e.g., "Stop sending these notices for 2 hours!!").

At any point the user could navigate to the notification that was posted on Start and supply what is needed. This would be processed by ButtonCallback clearing the flag when done. The next periodic cycle that detects a cleared flag would post another notification and set the flag.

Thanks for any comments and help you might offer, kind regards,

Thanks for the message and I wish you very good success on exams!!!

1 Like

Hi Randal, rather than the explanation (what you have done so far), it would also help to know what you are trying to do so far.

Also since I assume you are touching the callback button features of the notification style component, it's not guaranteed to work in the background (that's why dont use it for now).

I'll be able to take a look into this thoroughly next month.

Hello Kumaraswamy,

I know you are especially busy, so thanks for the reply.

You asked:

what you are trying to do

I want to periodically check the data transport mechanism. If it is cellular, I want to notify the user and give him the opportunity to increase the time between checks or to stop checking ("snooze the app") for a certain period of time. This could help those without unlimited data plans to be more aware of their data use.

I want it to start when the phone is started.

Eventually, I want the user to be able to set various parameters that determine 1) how frequently to be notified, 2) for what reason (under what conditions) to be notified besides simply that data is in use, and 2) how to be notified (a notification, toast, notifier, other?).

Again, I wish you good success in your academic achievements and upcoming exams.



1 Like

You could have the user do this kind of configuration before starting the background service and store these choices using the StoreProperty method. Like this you do not have to use the CallBackButtonAction feature


Hi Taufun,

Thanks for helping me think through this one.

I am thinking about your suggestion, which is a good one. Except I do not think I can design a configurable set of parameters that would be sufficient without requiring user input in real time.

The main challenge is different (even changing) user circumstance, preference, and intent. In one instance, the user might be intentionally using cell data for what he anticipates to be a very short time and does not want to forget to turn it off when he resumes watching his movie or listening to his "tunes" which he "thinks" are downloaded onto his phone... so for that situation, he would not want to "snooze" the monitor but be willing to put up with repeated reminders (a minute or two apart).

In another instance, the user may intend to use cell data for an extended period since he realizes he may not be near wifi for he would want to "snooze" the monitor for those number of hours (or hour by hour until wifi is available - which the monitor could communicate).

Another example is whether or not to include a sound in the notice - preference might vary depending on the circumstance.

I suppose, when the user wanted to make these changes in monitor "parameters", he could simply restart the app, make changes, and then close it (without stopping the b/g task)... this might work well enough. Perhaps this is what you had in mind.

In an earlier approach, I experimented with your alarmmanager facility. Frankly, I forget what problems I ran into (perhaps of my own making and ignorance), but the itoo background approach seemed more of a fit - until I started using the NotificationStyle callback events :slight_smile:

BTW, is there a proper way to communicate reliably between the user and a background task?

Thanks for your thoughts and suggestions,

Notification Style extension's callbacks just isnt able to properly work in background. I'll write a new notifications extension if possible next month.

You mean live communication or communication by constantly reading/writing? Both are possible.

Check the RegisterBroadcast, Broadcast, UnregisterBroadcast blocks for live communication or FetchProperty and StoreProperty for storing/retrieving data.

I think that would be quite nice ... and I know you'd rather work on that than prep for exams :slight_smile: but "nose to the grindstone" (pardon the English idiom)

I have employed FetchProperty and StoreProperty successfully....What I am stumbling on is the "live communication".

Yes, I must investigate this.

My concern is that, while the blocking behavior would guarantee synchronization of communication, I would expect to need a "timeout" parameter, so that user inattention could not indefinitely hang the cyclical monitor (Timer). But I need to use these to see how they work. Thanks for the suggestion.

I think I have found an example here that uses Broadcast:

I'll see what I can come up with ...

Kind regards,

1 Like

How could I replace the /!\ (exclamation point circumscribed by a triangle) notification icon in the following with one of my own choosing?


The blocks used in the app are substantially the same as those shown earlier in this thread.


Well, I'm sorry I had to remove that feature in the previous update due to some reasons. I'll re-add it back in the next version (just few weeks more until my exams end)

1 Like

No problem - I'm quite happy at the prospect that it may be possible :slight_smile:

Thanks for taking time to reply .... Hang in there!

Kind regards,

1 Like

Hello @Kumaraswamy! I am trying to reduce the amount of logging my app is creating in logcat, in order to improve the app performance.

The lines I am trying to get rid of in logcat look like this:

03-09 15:45:38.879 2128 2128 D ItooCreator: AEvent(BytesReceived=BluetoothLE1) args [0000ff01-0000-1000-8000-00805f9b34fb, 0000ff02-0000-1000-8000-00805f9b34fb, (153 19 0 32 192 224 176 200 7 219 ...)] listener = xyz.kumaraswamy.itoo.Itoo$1@294738c

03-09 15:38:27.522 2038 2038 D ItooCreator: AEvent(RssiChanged=BluetoothLE1) args [-28] listener = xyz.kumaraswamy.itoo.Itoo$1@b27b2c7

Do you have any hints/guidance on how I can achieve this? So far, I looked into the source code to see where this line is logged, but wasn't able to. I am thinking maybe it's somewhere in the itoo-x repo.

Hi it is possible to reduce the logs produced by the app, but it may not be very nice for debugging. Will surely consider adding a feature to suppress logs in the next update <3

1 Like

Is there an option to remove the option to start applications automatically and set it to manual in the settings panel since otherwise the save boot process does not work

and also if some options were added so that the device's battery controller does not close the process

I'm not sure what you are saying, I guess you are requesting a feature to autostart the application?

Thanks for responding, that function already exists, but some phones do not do it when this option is activated