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]
AND
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
mobileControlCreate "player",pPlayerName
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
end if
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
end if
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
end if
if mobileIdleTimerLocked() is false then mobileLockIdleTimer --jg: disallow
screen lock
end createMobileAudioPlayer
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"
end if
end playerPropertyAvailable
is TSNet any part of these operations?
-------------------
• queued: on hold until a previous request to the same site is
completed
• contacted: the site has been contacted but no data has been sent or
received yet
• 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
information
• 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
URL
• (empty): the URL was not loaded, or has been unloaded
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
