I look forward to putting it to use very soon. I have a procedure that I have detected is being called from the UI but is required to be called from the background! This should tell the tale.
I am very happy to have this call trace facility at my disposal! The Flow.Caller provides just what I had imagined and then some - the name of the type of entity.
All I had thought about was tracing procedures. I had not thought about the need/fact of tracing different calling entities that come paired with the name of the entity.
But I am having a little trouble with the Flow.ListTraces method. Perhaps I am not using it properly.
I have attached a test case that illustrates my apparent error. The UI presents a Reset (to be done prior to each test) and two test buttons. Both tests use Flow.Caller to represent the caller (Test1) or calling location (Test2) in the first label space. And below the separator, each test attempts to use Flow.ListTraces to list the last several traces.
In Test1 (CallerA-->CallerB-->Called_C) performs as expected: it reports theCaller as callerB and listTraces shows two calls to initTest (one in Screen1.Initialze and another from the Reset button) followed by CallerA-->CallerB-->Called_C.
However, while Test2 correctly reports called_E as the last calling procedure, listTraces does not show the correct prior callers: function1-->callerD-->called_E, but instead reports the same as for Test1.
Further, if you UNINSTALL and REINSTALL the app and execute Test2 first, you get the expected listTraces results for Test2, but then Test1 yields unexpected results (same as those for Test2 - not shown).
Hello @Randal_Andress, thank you for testing, I have identified the problem: The extension was returning first n elements and not last n elements as claimed, I have fixed the error.
I have fixed the error, hopefully this should work.
Sorry for the delay ... it indeed does work for me! Thanks again.
I have, however, encountered another issue.
The inclusion of the Flow extension, though unreferenced beyond its declaration as Flow1, seems to interfere with a ui_xxx call from the Itoo service. I have created a small test case that I hope will demonstrate the problem for you. Here are the blocks:
The message is received by the registered procedure "stopService" which is executed in the service. But before making the stop service call, the stopService procedure makes a ui_lblInfo call which fails...
Here is an excerpt from the logcat data:
06-08 23:56:09.199 18552 18552 D Flow : Procedure(ui_lblInfo, [%INFO - service is not running.])
06-08 23:56:09.202 18552 18552 D Flow : Property(lblInfo, Text, [%INFO - service is not running.])
06-08 23:56:12.069 18552 18552 D Flow : Procedure(ui_lblInfo, [%INFO - service started])
06-08 23:56:12.072 18552 18552 D Flow : Property(lblInfo, Text, [%INFO - service started])
06-08 23:56:17.183 18552 18552 D Flow : Procedure(ui_lblInfo, [%INFO - stop service requested...waiting...])
06-08 23:56:17.185 18552 18552 D Flow : Property(lblInfo, Text, [%INFO - stop service requested...waiting...])
06-08 23:56:17.197 18552 18552 D ItooXUI : UI Procedure Req: ui_lblInfo, args: [%INFO - service being stopped...]
06-08 23:56:17.200 18552 18552 E AndroidRuntime: FATAL EXCEPTION: main
06-08 23:56:17.200 18552 18552 E AndroidRuntime: java.lang.RuntimeException: Error receiving broadcast Intent { act=UI_ITOO_X_RECEIVER flg=0x10 pkg=appinventor.ai_randal_andress.Itoo_Flow11_lblInfo_Err (has extras) } in xyz.kumaraswamy.itoox.UIProcedureInvocation$1@2cbd583
06-08 23:56:17.200 18552 18552 E AndroidRuntime: Caused by: java.lang.RuntimeException: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
06-08 23:56:17.200 18552 18552 E Form : Uncaught Exception
06-08 23:56:17.200 18552 18552 E Form : java.lang.RuntimeException: Error receiving broadcast Intent { act=UI_ITOO_X_RECEIVER flg=0x10 pkg=appinventor.ai_randal_andress.Itoo_Flow11_lblInfo_Err (has extras) } in xyz.kumaraswamy.itoox.UIProcedureInvocation$1@2cbd583
06-08 23:56:17.200 18552 18552 E Form : Caused by: java.lang.RuntimeException: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
06-08 23:56:17.201 18552 18552 E Form : Form Screen1 ErrorOccurred, errorNumber = 909, componentType = Screen1, functionName = <unknown>, messages = java.lang.RuntimeException: Error receiving broadcast Intent { act=UI_ITOO_X_RECEIVER flg=0x10 pkg=appinventor.ai_randal_andress.Itoo_Flow11_lblInfo_Err (has extras) } in xyz.kumaraswamy.itoox.UIProcedureInvocation$1@2cbd583
As I continue to test Flow 1.1, I have something else for you to look at when you get to it. I suppose it could be just another problem with the same cause as the previous one (itoo-flow_lblInfo_Err), but it seems to have very different symptoms.
I have tried to construct a helpful test case with 4 tests - two of which (Test2 and Test3) seem to work as expected, but the other two (Test1 and Test4) raise runtime errors having to do with indexing.
The UI is similar to the last case but with 5 buttons - Reset, Test1, Test2, Test3, and Test4 - and two label fields for output:
The relevant difference between the tests is which number is passed as the "list" argument in Flow.listTraces: -1, 0, 5, or 1000. 0 and 5 seem to give expected results (as best I understand it), but -1 (which would output the entire list) and 1000 (which would request more than there are in the list) fail with the indicated runtime errors.
The Test1 error is: "fromIndex(6) > toIndex(5)" (edit)
I should add that one of the tests (Test2) involves a function (procedure with a return value - function1) and outputs the name of the "leaf" procedure (the one at the greatest nesting depth), while the other tests output the caller of the leaf and involve only nested procedures...
This is drastically a different year for me. I'm getting back to filling my academic knowledge gaps, since I have to write multiple exams this year. I'm just trying my best to go through... It's a miracle I've survived last 5 years of my schooling while keeping my passion alive. It burnt me to exhaustion multiple times.
Now addressing the above problems
The first case (a total app crash) is being caused in the Itoo-X framework which incorrectly assumes a higher data structure that is tampered by the Flow extension.
I've done a few adjustments in the Flow extension, I rely on my theory (I could'nt test it practically)
The second case, well actually you shoud'nt be inputting negative values... Well anyways I've done a few corrections to the function.
if last == -1 it'll return the whole list
I've added a safety min(0, x) function
val from = if (last == -1) 0 else min(0, stringTraces.size - last)
...stringTraces.subList(from, stringTraces.size)
Well, @Kumaraswamy, let us be thankful for miracles! I know this must be a difficult time - one that requires much discipline - to avoid having your education "derailed" or your health/wellbeing affected by other valuable and rewarding endeavors such as you are involved in with AI. I wish you the best in working it out.
Sorry, I must have misunderstood - I thuoght the "-1" was a request to dump the whole list. Thanks for making it work.
I can re-test and exercise it (Flow) a bit and let you know how it goes.
I say again, I think this is a very important/helpful AI debug tool. I am surprised that such a capability has been missing from AI.
Kind regards and continued success with school,
Randal
This seems to work nicely: Test1 returns the entire list.
However, (and please excuse my possible misunderstanding), I think you may have intended this conditional assignment to include:
max(0,x) rather than
min(0,x)
val from = if (last == -1) 0 else max(0, stringTraces.size - last)
...so that "from" would never be less than 0 and if "last" were greater than the array size the negative sum (stringTraces.size - last) would never be assigned.
This would explain the Test3 result - all levels are returned. It also would explain Test4 result which fails attempting to index stringTraces with a value < 0.
But, upon more careful examination, I did find something unexpected. On the initial execution of the app, all 4 tests seem correct, but subsequent execution (after closing the UI is problematic.
If I run the following test app and then exit the UI by pressing the "Back" button, when I start it again, the results become incorrect/unreliable (see example screen shots below).
However, if I "Force Stop" the app after exiting (using the app info settings screen) before the second execution, all is well.
Also, if the app is modified to explicitly close on exit by placing the "close application" block inside a Screen1.BackPressed event, then on restarting, the app repeatedly performs all 4 tests as expected.
Here is what the screens show on first start when executing Test1 and then Test3 (Reset before each test)
I understand that working on this is a "back burner" task, but still I want to continue to provide feedback that might help smooth out the rough edges when you do find the time.
Kind regards and good success with your studies,
Randal
Hey, I'm a bit overwhelmed with the screenshots. I get that the Caller block is misbehaving, here's my attempt to smartly solve it using the List Traces block.
I defined a procedure whoCalledMe, a helper procedure meant to be used as an alternative to the Caller block:
... sorry about that. I guess I got carried away. TMI (Too Much Information).
So only two screen shots this time
As you suggested I replaced all calls to Flow.Caller with whoCalledMe.
But still, after the initial invocation of the app (which seems to work perfectly), the second (and sequent) invocations err in such a way as to retaining the same Flow.listTraces result as the last test of the initial invocation.
For example, if, on initial invocation, one executes Test1, then Test3, and then Test4, the following is displayed:
listTraces seems to be the same as in the last test of the first invocation, which would then make "theCaller" incorrect since whoCalledMe is derived from listTraces, correct?
So I am guessing that Flow.Caller is misbehaving because listTraces is incorrect (persists between invocations of the app?).
Since Itoo-X is being used, could listTraces and/or other some data be in a persistent data structure (such as by using Itoo.StoreProperty)?
And, if that is correct, then could that possibly be the cause of the problem with using Flow with Itoo, such as in the itoo_Flow... test posted earlier?
I do hope we can work this out so that Flow will work with Itoo...that is the environment in which I have need for a "whoCalledMe" function.
Or tablets or whatever they use nowAdays 
... sorry about that. I guess I got carried away. TMI (Too Much Information).
