Thanks for the replies. They've been really helpful. I decided to
make try the background download. Been working on it for a week now
(without total success).
I'm using the Palm 5.4 HTTP Library, and I used the HTTP/peer files from
the _HTTPLibTest sample applications as my basis.
For the current download state, I'm using the DownloadInfo struct (as
defined in HTTP.h)
My basic app is as follows --
pilot main
{
if(sysAppLaunchCmdNormalLaunch)
{
register for sysNotifyEventDequeuedEvent
}
if(sysNotifyEventDequeuedEvent && event = nil event)
{
if(no saved download state)
{
open/initialize the http library
- SysLibLoad(http library)
- HS_HTTPLibOpen
- HS_HTTPLibInitialize
create the http request stream
- HS_HTTPLibStreamNew
- HS_HTTPLibStreamCreateRequest
}
else if(has saved download state)
{
load current download state from persistent storage
}
update the download progress
- call HTTP.c::DownloadInfoProgress()
- if bytes came off the wire, write those to disk
if(download complete)
{
close the HTTP library
- HS_HTTPLibFinalize()
free the download state structure
- HS_HTTPLibStreamClose
- HS_HTTPLibStreamDelete
}
}
If my application is in the foreground, my code is correctly downloading
files (and the UI remains responsive).
Once my app is out of the foreground, the phone crashes & restarts
(makes debugging more difficult).
The things I'm persisting that I suspect are not valid the next time
thru are...
- a pointer to the HTTP Stream (HS_HTTPLibStream fHTTPStream)
- library reference number (UInt16 gRefNum)
- a pointer to the HTTP Library (HS_HTTPLibHandle gLibHandle)
If anyone is interested, I can throw up my code somewhere publicly
accessible.
Questions I have.
1. Obviously, saving these pointers aren't working. Is there another
way to get a handle to the HTTP library, HTTP Stream?
2. Is there any other work I have to do prior to exiting pilot main to
ensure that the HTTP library/stream is accessible the next time thru?
3. Is using the HTTP Library the wrong way to go, and should I try using
the lower level NetLib instead (I presume this would mean I'd also have
to add HTTP code on top of it)?
4. I heard mention of creating & abandoning a shared library to do the
download (in a previous thread). Should I put my download code in a
shared library. Have that library maintain the HTTP library/stream
pointer in memory. Then every nil event, tell that library to update
itself. Is this even possible? Can you create a shared library that
stays in memory after your app is terminated; and that can be referenced
again during the next event call (or instead of telling it to update
should I sign up for HTTP callbacks -- if they even exist -- and use
those instead of the nilevents to drive this)?
Thanks!
Ravi
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/