Threading debug

[Eduard]

Hi,

When I run code in the background using the threading library I get errors when I select "Debug" in the toolbar of the B4A developer studio.

But when I run the same code in the foreground (without use of threading) in combination with "Debug" everything is fine.

Also, when I run the same code in the background using threading library with "Release" selected, everything is fine.

So I think its not really important, but does anyone else have the same experience?

error is most of the time:
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer

but app stops somewhere randomly in the code.

after that the app is killed by the os.

I'm not desperate for a fix, but would like to have any idea why this is.

 

[mc73]

Do you have many int variables? If not, you could try following each one declaration and check where the error occurs.

 

[Erel]

The debugger doesn't work properly with the Threading library (with background threads).
In the next version you will be able to exclude modules from the debugger so you will be able to debug the other parts of the application.

Why do you use a background thread?

 

[corwin42]

I have a similar problem in my weather app. I mainly use threads for database operations (getting weather data from the database etc.) which may take some time. I can't use the debugger for a long time now. Happy to hear, that it will be possible to exclude modules from the debugger in the next version.

 

[Erel]

One of the concepts behind Basic4android is that the developer always writes code in the main thread and the libraries are responsible for handling the background threads.

I can add an asynchronous query to SQL library, though in most cases optimized queries should be very fast. Are you using an index for your query?

 

[corwin42]

I can add an asynchronous query to SQL library, though in most cases optimized queries should be very fast. Are you using an index for your query?

Yes of course I use indexes. Asynchronous query functions would be very nice for the SQL library since Database access can be slow sometimes.

The queries I use are quite complex in some parts so a full request for weather data for a single location needs some time (up to 0.5 seconds on my galaxy nexus).

Another part where I use my own thread is parsing the XML response from the weather feed. On slow devices this can take up a few seconds and because the weatherdata is requested and parsed by a background service it made the UI of the app freeze for a few seconds. Moving the parsing code to its own thread solved the problem.

 

[Eduard]

The debugger doesn't work properly with the Threading library (with background threads).
In the next version you will be able to exclude modules from the debugger so you will be able to debug the other parts of the application.

Why do you use a background thread?

Thanks,

I'm using multiple background threads in a service for processing transactions to/from a server. Basically I have a pool of threads available and a que of transactions. As soon as a thread is available it will pick the next item from the que and create a package.When this is done a httpjob is started. When that's done the response from the server wil be processed again in the background. After that a callback will be done to the UID thread to refresh the particular data and thread becomes available for next item in the que.

For callback I created an class:

'Class module
Sub Class_Globals
   Private component1 As Object
   Private   sub1 As String
   Public start_even_if_activity_is_in_background As Boolean
   Public argument1 As Object
   Public argument2 As Object
End Sub

'Initializes the object. You can add parameters to this method if needed.
Public Sub Initialize(activity_or_component As Object,sub_to_call As String)
   component1=activity_or_component
   sub1=sub_to_call
   start_even_if_activity_is_in_background=True
   argument1=Null
   argument2=Null
End Sub


Public Sub start_call As Boolean
   l.DebugLog("start_call")
   Dim returnw=False
   If component1<>Null AND sub1<>Null Then
      If start_even_if_activity_is_in_background OR IsPaused(component1)=False Then
         If argument1<>Null Then
            If argument2<>Null Then
               l.DebugLog("CallSubDelayed3 " & sub1)
               CallSubDelayed3(component1,sub1,argument1,argument2)   
               returnw=True
            Else
               l.DebugLog("CallSubDelayed2 " & sub1)
               CallSubDelayed2(component1,sub1,argument1)
               returnw=True
            End If
         Else
            l.DebugLog("CallSubDelayed " & sub1)
            CallSubDelayed(component1,sub1)
            returnw=True
         End If
      End If
   End If
   Return returnw
End Sub

This is particular useful if I need more callbacks. Since an argument can be of callback to.

It just to speed up things. It was a bit of a puzzle, but It works flawless now and is fast.

If your planning to make multithreading easy in B4A, consider a function 'CallSubBackground("function to do in background","function to do in foreground after first is done") This would make multi-threading easy in services.

Cheers.

 

[Eduard]

I have a similar problem in my weather app. I mainly use threads for database operations (getting weather data from the database etc.) which may take some time. I can't use the debugger for a long time now. Happy to hear, that it will be possible to exclude modules from the debugger in the next version.

I added an global variable in my service module: "DO_BACKGROUND=true/false"

when true, then threadinlibrary is used to execute subs. When false "Callsub" is used to process in the main thread.

 

[corwin42]

I added an global variable in my service module: "DO_BACKGROUND=true/false"

when true, then threadinlibrary is used to execute subs. When false "Callsub" is used to process in the main thread.

Good idea.