IWeb - persistent for life of application? | developer.brewmp.com IWeb - persistent for life of application? | developer.brewmp.com

Developer

IWeb - persistent for life of application?

Forums:

Quoth the API reference:

An IWeb interface pointer is designed to be created at application startup, initialized, and used until application shutdown.

However, I've found it necessary to destroy and create a new IWeb interface before every connection. Otherwise, the second call to GetResponse() never does anything--never even makes it to my status handler. Releasing and re-creating works fine.

Looking closely at the RoadWarrior example, the author did the same thing.

I have tried -just- deallocating the WebResp, cancelling the callback, etc., but aside from avoiding memory leaks, none of that solves the underlying problem unless I also release my IWeb interface.

This line is repeated in the 2.1.0 API docs, too. Is it true? Is there a catch, or a common trap? I just would like to have to allocate and deallocate as few times as possible during the course of my application, to give it fewer opportunities to fail. I can eliminate a lot of my runtime memory allocation (with some drawbacks, of course), but this sticks out like a mule in an ice cream parlor.

Despite the wording, I always interpreted that to mean that you should never use more than one IWeb interface pointer; that way, there's no danger of having more than one concurrent IWeb interfaces.

Despite the wording, I always interpreted that to mean that you should never use more than one IWeb interface pointer; that way, there's no danger of having more than one concurrent IWeb interfaces.

Now that you point it out, I can see that that is probably the intended meaning. D'oh!
I feel so silly now. I mean, their wording never had you stumped? Even for a minute?
Ah, well, back to development...

Now that you point it out, I can see that that is probably the intended meaning. D'oh!
I feel so silly now. I mean, their wording never had you stumped? Even for a minute?
Ah, well, back to development...

Nope, never had me stumped. But I can fake it for ya if you like....

Nope, never had me stumped. But I can fake it for ya if you like....

I also thought that it was basically recommended to have one IWeb pointer persistent for the life of the application, but that there would be no harm in releasing and reacquiring the pointer, which I guess needs to be done during Suspend/Resume anyway.
However, I didn't seem to have any problems with having a single IWeb pointer in my application. Multiple calls to GetResponse seemed to work fine. I say"seemed" because I dont have network service here and am having the application tested by someone else and his test reports suggest that everything went fine.
Regards,
Roshan

I also thought that it was basically recommended to have one IWeb pointer persistent for the life of the application, but that there would be no harm in releasing and reacquiring the pointer, which I guess needs to be done during Suspend/Resume anyway.
However, I didn't seem to have any problems with having a single IWeb pointer in my application. Multiple calls to GetResponse seemed to work fine. I say"seemed" because I dont have network service here and am having the application tested by someone else and his test reports suggest that everything went fine.
Regards,
Roshan