Re: ksoap + RIM + in a separate thread

Steve Porter wrote:

> What do people think of adding this functionality to KSOAP itself?  
 > It would seem the HTTP transport class is sort of begging for this,
 > and seeing as KSOAP is (at least in my, very possibly wrong, 
understanding)
 > targetted at J2ME devices.

Hi Steve,

targetting J2ME also means tho keep things minimal. The approach 
described by Nathanial is one option, but not the only one. In the newer 
version of the stock quote example, the solution is to start a thread 
when the user issues a request, returning control for the event thread 
to the operating system immediately. The new thread then requests the 
information via soap, waits for the response, and displays the result.

Support for a more sophisticated queuing mechanism as described by 
Nathanial would probably make a great addition to kSOAP, but it needs to 
be optional, and of course someone needs to step forward and do the 
implementation work :)

Best regards,
Stefan Haustein





>  
> I mean it would be great to remove this headache and mental roadblock for other developers, and I certainly think it's doable.
>  
> Regards,
> Steve
> 
> -----Original Message-----
> From: Nathanial Freitas [mailto:[email protected]]
> Sent: Monday, March 22, 2004 3:16 PM
> To: [email protected]
> Subject: RE: Ksoap: ksoap + RIM + in a separate thread
> 
> 
> You essentially need to design your application so that its not a sync send/receive web-style model. Think of how the rest of a Blackberry works and then model that. This is a good approach for J2ME on *any* device, because if you put HTTP in the main thread, you'll block all UI interaction.
> 
> 
> A quick recommendation is to create a class to store SOAP messages and their responses, and a reference to a callback interface to return the response object to once its processed. Then create instances of that object and place them into a FIFO queue (Vector, Hashtable, Stack, etc). Write a handler running in a seperate thread, which sleeps until you notify it to wakeup and process whatever it finds in the queue in a serial manner. When it has its response (or error), then pass it back to the callback interface (which would then present some UI to the user).
>  
> It's a pretty common design, and one that I've had a lot of success with. You just have to break the sync/web mentality of both you and your users. The good news is that this is a cheap way to handle on/offline modes, as well.
>  
> Regards,
>    Nathan
> 
> -----Original Message-----
> From: Steve Porter [mailto:[email protected]] 
> Sent: Monday, March 22, 2004 4:26 AM
> To: [email protected]
> Subject: Ksoap: ksoap + RIM + in a separate thread
> 
> 
> Ok.. got KSOAP2 talking to .net webservices.. I figured that would be the hard part, but not too bad. 
>  
> My problem is this.  On the RIM Blackberry units, I've been told all HTTP fetch requests must be on a separate thread.  Anyone here have any ideas how to partition KSOAP in such a way as to put the data fetcher on a separate thread.  I access a *lot* of web services from my application (currently over 25 comprise the application, and no it's not poor design, it's a HUGE scope application).
>  
> Any help (or even better code) would be appreciated.
>  
> Steve
> 
>