libUrl tsNet and socketTimeoutInterval
brahma at hindu.org
Fri Dec 8 14:32:35 EST 2017
Charles Warwick wrote:
Sorry for the confusion, tsNet does handle the ‘load’ function, effectively using its own asynchronous functions to replicate standard libUrl behaviour.
BR: wow. That's magic! so this means we can just proceed "as usual" with using
load [URL] url [with message callbackMessage]
the URLStatus of url
with results as expected: (see below) where the timeout will occur based on
tsNetSetTimeouts 60, 3000, 3000 , 3, 3, 12000
… and TSNet will return URLStatus value as already described in the dictionary just as it always has (see below.)
OK, suddenly this becomes easy. But the we still have a "murky outback" in the mobile space:
How to mix this into the stew along with dynamic control creation on mobile? And what exactly is happening…
where we call something like this:
command createMobileAudioPlayer pURL, pPlayerName,tRect
if pPlayerName is among the lines of mobileControls() then mobileControlDelete pPlayerName -- init
put the result into sPlayerId
-- adjust location for mobile:--### FIND OUT IF THIS IS NEEDED ON iOS
if tRect is empty then
put the rect of player pPlayerName into tRect
if the platform is "android" then -- android player controls appear above the player; adjust
-- with controller it's about 4x rect of cd player so align the bottom edges:
# this his hard wired to the bottom of the card for now.
put (the height of this card) -70 into item 4 of tRect
put item 4 of tRect - item 2 of tRect into tHeight
subtract tHeight from item 2 of tRect
mobileControlSet pPlayerName, "visible", true
mobileControlSet pPlayerName, "rect", tRect
mobileControlSet pPlayerName, "showController", true
mobileControlSet pPlayerName, "filename", pURL
if pURL begins with "https" then
showBusyIndicator true, "Loading audio..." -- add loading indicator until duration is available
if mobileIdleTimerLocked() is false then mobileLockIdleTimer --jg: disallow screen lock
So…in this context, the player is created, and the audio is called and the player starts playing. Is TSNet invoked in the background if we start the player?
the dictionary says: URLStatus
"Returns the status of uploads and downloads
that were started with the load, libURLDownloadToFile,
libURLftpUpload, and libURLftpUploadFile commands."
1) what about a URL called by a mobile control? set to a Browser Widget?
2) if we use "load" and cache the URL then set the mobile player to that URL, is it no longer streaming but playing the cached audio.mp3 file?
3) the player has it's own methods: if it's duration property becomes available then we can start playing
on playerPropertyAvailable theProperty -- msg sent when enough has content is loaded
if theProperty is "duration" then
showBusyIndicator false -- Remove the "Loading..." indicator and start playing
mobileControlDo pPlayerName, "play"
is TSNet any part of these operations?
• queued: on hold until a previous request to the same site is
• contacted: the site has been contacted but no data has been sent or
• requested: the URL has been requested
• loading,bytesReceived,bytesTotal: the URL data is being
received; items 2 and 3 of the return value provide progress
• uploading,bytesReceived,bytesTotal: the file is being
uploaded to the URL; items 2 and 3 of the return value
provide progress information
• cached: the URL is in the cache and the download is complete
• uploaded: the application has finished uploading the file to the URL
• error: an error occurred and the URL was not transferred
• timeout: the application timed out when attempting to transfer the
• (empty): the URL was not loaded, or has been unloaded
More information about the Use-livecode