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

This is actually a device specific issue and there isnt a solution to it. You can guide your users to manually turn of any optimisations:


🧩 Itoo 4.1 Sky

(Please look into the first post for detailed documentation)
  • Added support for Firebase and Cloud DB through ExecuteInternalScript block
    Look into the resources attached in first post.

  • Enhanced existing notification icon block (req. from @Randal_Andress)

  • Added ability to turn off debug mode β€” thus reducing logs produced (req. from @aeozyalcin)

  • Added Capture and Release properties block to save property state of components & reapply it in the background.

  • Added simple property block InBackground to check if the app is currently in background.

  • Internal enhancements have been made.

I've also rewritten the documentation with a lot of resources and examples attached, please look into it!

xyz.kumaraswamy.itoo.aix (79.7 KB)

:star2: I'm a high school student, this is not an easy extension to maintain. Only possible with incredible hardwork and months of research for perfection put into it.

Please consider donating: PayPal.Me

Kumaraswamy B G


Could you provide any other method to donate except PayPal?

Hi Sure, you can Stripe me: Stripe Checkout


your the best, the cloud is now connecting thankyou very much @Kumaraswamy


Thank you for the code AND documentation updates! I look forward to using and learning about them.

Kind regards,

1 Like

Thank you for the enhancements and additional documentation :slight_smile:

I have a question about communication between the user interface and a foreground service started using Itoo.CreateProcess.

I have included the blocks photo as well as a test app to illustrate the following example:

The user interface starts a foreground service which registers a Clock Timer event whose processing reads (FetchProperty) and displays (using NotificationStyle) an item of data that has been initialized using StoreProperty...

The user interface may then be restarted and the contents of a textBox may be saved (StoreProperty) by clicking a btn.

When run on a Moto e5play (ApiLevel 26), the subsequent executions of the Timer processing successfully read and display the updated data item.

Is this a legitimate way to pass data from user interface to the foreground service? Or is the only reliable means of passing data from the user interface to the foreground service to use the Broadcast feature?

Kind regards,
[Sorry :frowning: I completely forgot to upload the blocks .png and the example .aia]

itoo_sandbox.aia (880.1 KB)




1 Like

Broadcast feature is the best way to communicate live data.

Edit: @Randal_Andress If the Itoo's Store/Fetch property really works fine, then you can use it too :slight_smile:

No where! But I just edited the post to add them. Thanks for responding even though it was an incomplete post. Hope this helps explain my question.


You are calling the NotifyUser procedure from the background... inside that procedure you are using the notifier component and a toast extension to display something... this will not work, because there is no user interface available in the background... use the notification style extension instead


Taifun, thanks for taking a look at the code!

While I am developing and learning I have taken a "belt and suspenders" plus duct tape approach - trying out three methods of user notification. In addition to the Notifier and SimpleToast (which I now understand cannot be relied upon) I also am calling the NofiticationStyle which, you may have noticed, is called by LargeIconNotificationWithOptions. In the application I am working on, it is the NofificationStyle (with 3 callback buttons) that I really need. It provides feedback into the service (using itooStoreProperty). I can ditch the Notifier and toast methods which for some reason seem to be working on ApiLevel 26...

To clarify, now that you have seen the code, is what I am doing OK - updating data items from user interface using itoo.StoreProperty? I have to ask because I now understand that just because something seems to be working does not mean that it is reliable.


So what I am doing may not be the "best" way, but it will work, correct?


I'm confident that since it works correctly, it can be relied upon.
Store/Fetch property blocks directly write/reads data to files in the app's private files directory.

Yes, I'm also doing that

Thank you for the clear answer and for sharing a bit of the implementation details :slight_smile:

1 Like

Thank you for clarifying.

I think I am beginning to understand at least some of what is involved in dealing with these service processes created by itoo. The additional documentation that Kumaraswamy provided with this release has helped.

Kind regards,

1 Like

@Kumaraswamy thank you for taking my suggestion to add the ability to enable/disable logging! I gave the latest 4.1 Itoo in my application, that uses BLE in a background process, and I am seeing what might possibly be a regression with Itoo 4.1?

First thing I observed when I switched to Itoo 4.1 is that all FetchProperty blocks got disowned because of the newly added argument. After I fixed that in my code, and redeployed my application, I saw that Itoo no longer seems to be able to correctly register to the events :thinking:

I use Itoo to launch a process automatically on boot, and I see that it's only correctly registering to 1 out of the 12 or so events I am telling it to register to.

Here is the process that gets called upon boot. Out of all the registers there, the only one that appears to be working is "reconnect_clk.Timer".

Here is how I know that's the only successful one:

PS C:\Users\aeozy\Downloads\platform-tools_r34.0.4-windows\platform-tools> .\adb.exe wait-for-device; .\adb.exe shell "logcat | grep itoo"
02-16 02:46:25.457   556   583 I ActivityManager: Start proc 2009:appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE/u0a148 for broadcast {appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE/xyz.kumaraswamy.itoo.receivers.BootReceiver}
03-23 14:05:07.278   556   738 I ActivityManager: Background started FGS: Allowed [callingPackage: appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE; callingUid: 10148; uidState: RCVR; uidBFSL: n/a; intent: Intent { cmp=appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE/xyz.kumaraswamy.itoo.ItooService }; code:BOOT_COMPLETED; tempAllowListReason:<6975dff android.intent.action.BOOT_COMPLETED/u0,reasonCode:BOOT_COMPLETED,duration:20000,callingUid:1000>; targetSdkVersion:33; callerTargetSdkVersion:33; startForegroundCount:0; bindFromPackage:null: isBindService:false]
03-23 14:05:07.291   556   583 I ActivityManager: Start proc 2065:appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE:doraemon/u0a148 for service {appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE/xyz.kumaraswamy.itoo.ItooService}
03-23 14:05:07.563   556   798 W ActivityManager: Foreground service started from background can not have location/camera/microphone access: service appinventor.ai_aeozyalcin.ltoo_test_2_minimal_checkpoint1_A14_myBLE/xyz.kumaraswamy.itoo.ItooService
03-23 14:05:07.721  2065  2065 I ItooCreator: applySlex: #<procedure xyz.kumaraswamy.itoox.ItooCreator$IntBody> [0]
03-23 14:05:07.730  2065  2065 I ItooCreator: Create component = Itoo1 = xyz.kumaraswamy.itoo.Itoo
03-23 14:05:10.811  2065  2065 I System.out: xyz.kumaraswamy.itoo.Itoo$1@58b2d30
03-23 14:05:10.811  2065  2065 I ItooCreator: AEvent(Timer=reconnect_clk) args [] listener = xyz.kumaraswamy.itoo.Itoo$1@58b2d30
03-23 14:05:10.812  2065  2065 I ItooCreator: applySlex: #<procedure xyz.kumaraswamy.itoox.ItooCreator$IntBody> []

I am also attaching my project in case this is helpful.
ltoo_test_2_minimal_checkpoint1_A14_myBLE.aia (364.7 KB)

That's weird... Since there weren't any core changes done to the event handling.

Does this have anything to do with Bluetooth? Could these be permission issues, can you please check them?

Also if you downgrade the extension to the previous version, do they all again work alright?

I will go through it once again this evening. Meanwhile can you please prepare a separate demo project demonstrating use of multiple events to reproduce the issue without the Bluetooth component for testing?


1 Like

Is that simply because you have disabled all other register blocks?

1 Like