A post was split to a new topic: Trying to download some pictures
Ahh, hmm, I'm sorry, I dont understand you very well.
Could you please simplify the explanation of this problem with a simple demonstration if possible? That would be great for understanding what limits you.
Could you help me in some way how to change the icon by default, since one assigns a bell to it but if for some reason the service is closed and it opens automatically it puts the microphone back, as if from the root it has the microphone by default
I will put something together and try to get it to "mis-behave" 
If I am successful, I will post it.
-Randal
1 Like
Hi, I will do that by this evening.
Hi
I have tried to use itoo to autorun an app when restart phone.
At first on installing apk and running app, it plays the voice and runs the assigned app to run: facebook
On restart of phone, it just plays the voice and does not run the app: facebook.
Is it possible to use itoo to autorun apps?
Here is my blocks:
Can you please take another screenshot so we also can see these blocks in white?
What is the purpose of the packagemanager extension in this case?
Did you try the activity starter to start Facebook?
Use logcat to find out if any error occurs
Taifun
Hello, check the settings of the mobile phone on battery and others so that I can set it to start manually, that helped me.
This is generally a good advice, see also dontkillmyapp.com
In this case however something happens on restart of the device, but only partially
Taifun
1 Like
It's a shame that at the code level you can't do anything to avoid many of these things.
Hi
The white blocks are actually disabled and not in use.
The taifun package manager was originally used to launch an app but its disabled and not used, instead using package utilities to run app.
But both does not launch an app.
Will try out using activity starter.
I'm not sure if this is possible, when you reboot your phone, a lot of activities or functions are restricted. This could also be imposed for starting external apps.
This is generly done by the Android system to prevent overload after the phone starts.
Though I would recommend you to stil experiment with different methods and by also disabling device specific optimization if any (dontkillmyapp.com)
Here is an illustration of the kind of "parallel/concurrent" access that I want to be able to do - without collision between the user interface and the service.
Two timers: one running in the visible user interface and another in the itto service. Each is incrementing its own count as well as a shared count.
If there were no shared count interference - i.e., if each reads, increments, and writes the shared count without the other intervening with its identical operations, then the sum of the individual counts would be equal to the shared count...which it is initially. However, eventually, it is not.
Open the app, then press start. Open the app again and use the button to check the counts periodically.
I know this is only a toy - with no useful function - except to illustrate the kind of exclusive access I am speaking of.
itoo_sandbox_async.aia (879.7 KB)
-Randal
1 Like
Hi
Okay thanks.
Will try and experiment other methods.
1 Like
Hmm, I took a look into that. This is a race condition, which leads to inconsistent data outcomes.
Itoo's Service runs on a different process than that of the app, so they will always remain non-synced.
From what I understand, you need a mechanism where the write/read is done safely. Meaning when the data is being read/write, no other process should do the same. Thus avoiding data inconsistency.
This would require us to create a "lock" mechanism, similar to that offered by Java, where a particular block of code, even called by many different processes, execute in order-of-call.
Did I understand that correctly, what you were trying to convey me? Then please reply yes.
Also, if you are interested, you can sponsor a new extension for $15 (I'll try to solve this race condition issue)
Yes. Exactly!
This could be as simple (though potentially inefficient) as a semaphore - where each thread requests the "lock" asynchronously until it is acquired and release it when done.
Or it could be more sophisticated and, for example, queue access requests and grant them in order of request, granting each subsequent request when access is released.
If none exists in appinventor, then this could be a very useful extension.
I am a little surprised that I find little/no mention of this in the forum (maybe I missed it). It makes me wonder if, for some reason, such a lock was not needed or would not be useful or practical or maybe even not possible.
-Randal
1 Like
You didnt miss it, in App Inventor, there wasant such a complexity to deal with before. App Inventor apps' blocks are single threaded, everything runs on a single thread.
Meaning internally the components may utilize multi threading capabilities, but with a block coder's perspective, there really isnt a way to multi thread on App Inventor.
Race conditions often occur when two different processes/threads try to read and change the same data on the same location. (This issue never arose in App Inventor).
(I am using the word "thread' and "process" inter-changeably here)
Hi
Did some experiments using Ullis Roboter AI2 App Launcher Extension
The extension has a block to check for permission: CanLaunchFromBackground
It seems to work.
It will run the app packages on restart/boot
Here is my blocks
(app packagename blanked out here in this image)
1 Like
That's great if it works.
"Thinking out-loud" ...
It would seem that the basic test-and-set (semaphore) lock functionality could implemented using the:
int getAndSet(int newValue)
method from the AtomicInteger class
[(https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicInteger.html)
... which atomically sets to the given value and returns the old value.
public AtomicInteger()
Creates a new AtomicInteger with initial value 0.
see: (https://stackoverflow.com/questions/57832471/which-atomicinteger-methods-are-test-and-set-fetch-and-add-and-compare-and-swap)
Each process/thread wanting access calls getAndSet (1) until it returns a '0'...every subsequent call from a process/thread will be returned a '1'.
Then after performing the protected operation(s), the '1' is reset to a '0' by the process with access by calling getAndSet(0), making it (the '0') available to other process(es)/thread(s).
The '0' is the permission token. It only exists in one place - either in the integer object (as when it is first created) or in a process which obtained it by getAndSet(1), replacing the '0' with a '1' in the object.
In cases where a collision is unlikely and/or the processing to be protected is of short duration (I believe this is true in my use case), the getAndSet(1) maybe done repeatedly ("spin on the lock") since access would likely be granted quickly.
The extension could simply be an "AccessToken" with GetAccess and ReleaseAccess methods which would do the underlying getAndSet calls. Or it could possibly be incorporated into the itoo extension(?).
One problem I see is that a thread/process could not be allowed to die/crash/exit while in possession of the '0', thereby causing any other process/thread calling getAndSet(1) to "hang"... perhaps some sort of timeout could be implemented...
... just "thinking out loud"... "for what it's worth" (excuse the English idioms 
)
-Kind regards,
Randal