As a matter of fact, it looks more like what I would expect than the one you obtain.
In the above listTraces there appear only those procedures that have been executed on the second invocation, while those from your second invocation (Reset+Test3, quoted below) show the remnants of the FIRST invocation in listTraces in addition to those of the second/current invocation (as does my Moto result):
I
Any idea what is going on? We have 3 different devices with different results.
On two of them it seems that the listTraces contains remnants of the first execution of the app.
This case is (as you no doubt know) started out as your Itoo Music player example. In the earlier case (itoo-flow_lblInfo_Err) it seemed to me that the failure was ass0ciated with the attempted execution of the ui_lblinfo procedure which is called implicitly by your "ui_xxx magic". ui_lblinfo is invoked from within procedure stopService which is invoked using the the broadcast mechanism from btnStop.Click event.
I have created another case that simply gets stopService invoked another way: Itoo CallBackgroundProcedure invoked from the btnStop.Click event.
This second method generates different logcat messages, including
My best guess is that the devices are handling the "back" action differently. Some devices are simply pausing the app while some others are instantly killing the app to save resources (from my experience from my previous phone).
That one is weird... I have not seen this type of error before. In case of Itoo...
We seem to be going down a rabbit hole here. We are not reaching any destination. From what I understand you would want to use this "whoCalledMe" in an Itoo process (in the background), am I right?
Is there any other way we can supplement your need? I've tried a lot of ways at my disposal... They seem to be not working...
That makes sense. So it seems that whoCalledMe can be relied upon (itoo excepted), in both cases 1) fresh invocation or 2) resumption of a "paused" process...and so also probably a whoAmI function.
Yes (and no ) Yes, in an itoo environment, but, no, not actually from the itoo process itself.
I want to guard each procedure in my app that MUST be called in the background (Itoo service) so that if it is called from the UI/foreground, I can log whoCalledMe, which call would be not from the background but from the UI
So I place code at the top of every procedure that must be called from the b/g:
If not itoo.InBackground then
log (whoAmI " was called by " whoCalledMe);
endif
But the problem seems to be that even declaring a Flow component in an Itoo environment seems to "interfere" with the ui_logInfo call from the itoo service. While this call (ui_logInfo) is not a part of the guarding code that I would add, it is a functionality that I depend on for the app to work (i.e., from the bg calling a procedure in the foreground).
Perhaps I can refine the test case to hone in on what is causing the problem...maybe calling a procedure without any parameters that does no attempt to call a Notifier method.
Thanks for persisting in helping me with this,
-Randal
[Added about 19:00 GMT]
Here are some excerpts from logcat.
06-27 13:41:30.005 25759 25759 E AndroidRuntime: FATAL EXCEPTION: main
06-27 13:41:30.005 25759 25759 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{appinventor.ai_randal_andress.Flow_with_Itoo/appinventor.ai_randal_andress.Flow_with_Itoo.Screen1}: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
06-27 13:41:30.005 25759 25759 E AndroidRuntime: Caused by: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
06-27 13:41:30.005 25759 25759 E Form : Uncaught Exception
06-27 13:41:30.005 25759 25759 E Form : java.lang.RuntimeException: Unable to start activity ComponentInfo{appinventor.ai_randal_andress.Flow_with_Itoo/appinventor.ai_randal_andress.Flow_with_Itoo.Screen1}: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
06-27 13:41:30.005 25759 25759 E Form : Caused by: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
06-27 13:41:30.006 25759 25759 E Form : Form Screen1 ErrorOccurred, errorNumber = 909, componentType = Screen1, functionName = <unknown>, messages = java.lang.RuntimeException: Unable to start activity ComponentInfo{appinventor.ai_randal_andress.Flow_with_Itoo/appinventor.ai_randal_andress.Flow_with_Itoo.Screen1}: java.lang.ClassCastException: me.ekita.FlowContext$hookProcedures$1 cannot be cast to gnu.expr.ModuleMethod
[Added about 22:20 GMT]
From a cursory search of several logcat files, it looks like the java.lang.ClassCastException:
me.ekita.FlowContext$hookProcedures$1 to
gnu.expr.ModuleMethod
is common to several of the Itoo/Flow failure cases.
As you likely realized, I was not paying close attention to the static content of listTraces on resumption of the app ... Looks like unless the UI/app is "closed" before resumption, listTraces does not get updated and therefore, whoCalledMe does not change
So to assure that listTraces is updated upon resumption, I would have to put a "close application" block in the backPressed event.
) Yes, in an itoo environment, but, no, not actually from the itoo process itself.
