Listen: Journal, Going to Listen, There is a Crash of Mobile

[Brahmanathaswami]

There is a crash, on Mobile

1) Journal -> Word Puzzle entry -> we can go there -> we get to go to Word Puzzle -- no crash

2) Journal -> go to a "Listen" entry -> we crash

this points to "journalResume" in behavior_Listen

for it only happens on moblie

      if isMobile() then
         createMobileAudioPlayer sDataA["url"], "audioPlayer",tAudioRect
      else
         set the filename of player "audioPlayer" to sDataA["url"]
      end if

---

on journalResume pDataA, pEntryA
   local tCard

   lock screen

   put pDataA["card"] into tCard

   go to card tCard

   if tCard= "listen-file"  then
      local tRect, tAudioRect, tItemID, tLineNum, tLineValue

      put the rect of graphic "audioRect" into tAudioRect

      put pDataA into sDataA

      fetchSingleMetadata sDataA["item_id"]
      put  getMediaItemMetadata() into  fld "audioDetails"   

      if isMobile() then
         createMobileAudioPlayer sDataA["url"], "audioPlayer",tAudioRect
      else
         set the filename of player "audioPlayer" to sDataA["url"]
      end if

      --      if sDataA["timestamp"] is empty then
      --         put 0 into sTimeStamp
      --      else
      --         put sDataA["timestamp"] into sTimeStamp
      --      end if
      --
      if not isMobile() then

         set the currenttime player "audioPlayer" to sDataA["timestamp"]
         start player "audioPlayer"
         --
         getPlaying true
         --
         get runningAudioIndicatorVis("true")
      else
         getPlaying true
         setMobileAudioPlayer "audioPlayer", "play", sDataA["timestamp"]
      end if

      put  sDataA["title"] into fld "currentTitleLabel"
      send "updateTimer" -- in 100 milliseconds
      set the iconPresetName of widget "PlayPause" to "pause"
   end if

end journalResume

[Brahmanathaswami]

it a case for timing. see

-- AAG: Needs a ton of work
on journalResume pDataA, pEntryA
   local tCard

   lock screen

   put pDataA["card"] into tCard

   go to card tCard

   if tCard= "listen-file"  then
      local tRect, tAudioRect, tItemID, tLineNum, tLineValue

      put the rect of graphic "audioRect" into tAudioRect

      put pDataA into sDataA

      fetchSingleMetadata sDataA["item_id"]
      put  getMediaItemMetadata() into  fld "audioDetails"   

      if isMobile() then
         local tURL, tAudioPlayer
         put sDataA["url"] into tURL
         put "audioPlayer" into tAudioPlayer

         send "createMobileAudioPlayer  tURL, tAudioPlayer, tAudioRect" to stack "lib_MobileControls" in 1 seconds
         --createMobileAudioPlayer  sDataA["url"], "audioPlayer",tAudioRect
      else
         set the filename of player "audioPlayer" to sDataA["url"]
      end if

      --      if sDataA["timestamp"] is empty then
      --         put 0 into sTimeStamp
      --      else
      --         put sDataA["timestamp"] into sTimeStamp
      --      end if
      --
      if not isMobile() then

         set the currenttime player "audioPlayer" to sDataA["timestamp"]
         start player "audioPlayer"
         --
         getPlaying true
         --

         get runningAudioIndicatorVis("true")
      else
         --getPlaying true
         --setMobileAudioPlayer "audioPlayer", "play", sDataA["timestamp"]
         local tPlay, tTimestamp
         put "play" into tPlay
         put sDataA["timestamp"] into tTimestamp
         send "getPlaying true" to stack "lib_MobileControls" in 1200 milliseconds
         send "setMobileAudioPlayer tAudioPlayer, tPlay, tTimestamp" to stack "lib_MobileControls" in 1500 milliseconds

      end if

      put  sDataA["title"] into fld "currentTitleLabel"
      send "updateTimer" 
      set the iconPresetName of widget "PlayPause" to "pause"
   end if

[soapdog]

This code is unsafe for many reasons. The most important is that send in time should not be used to tweak timings like that, LiveCode is not a real-time system and scheduled commands will be delayed if any other function blocks before their execution.

This code has bugs in it that might not be clear at first glance.

Unneeded delayed execution of setter command

As mentioned before getPlaying name is wrong. What that command actually do is set a flag in another script. It doesn't get anything, it sets something. Delaying the setting of a flag to a somewhat arbitrary time in the future is a side-effect. Other code will run before that flag is set and it is impossible to figure out when that execution will actually happen and which code will run before it..

Scheduling synchronous code, race conditions

This pattern will lead to subtle bugs called race conditions.

Given that the way the code is designed is as a gigantic state-machine in which flow is determined by wide-scoped variables, it is not really possible to guarantee the execution flow with delayed calls as crucial variables might change value between the scheduling and the actual execution of the delayed commands.

No guard clauses in the code

Commands such as setMobileAudioPlayer do not have guards in it to prevent it executing when it is not needed. If the user resumes the journal and immediately clicks any navigation icon in the bar thus moving the user away from the stack, that command will execute with the wrong stack in memory. Delayed calls need to verify they are still needed before executing.

[Brahmanathaswami]

I expected a commit....git pull does not get anything.

Anyway. I checkout a new branch "listenJournal"

Now,

sDataA["url"]

url | https://www.himalayanacademy.com/media/audio/songs/bhajan/ganesha/gananaatha-gananaatha_bp/gananaatha-gananaatha_bp.mp3

but it needs to be a downloaded file.

and this can come at end

   fetchSingleMetadata sDataA["item_id"]
   put  getMediaItemMetadata() into  fld "audioDetails"  

end journalResume

[Brahmanathaswami]

We have a solution to this problem. Cell phone take a moment to complete a process. 100 milliseconds does not allow the process to complete itself

createMobileAudioPlayer pURL, pPlayerName, pAudioRect

by waiting 300 milliseconds before subsequent calls can be processed. The following works

if not isMobile() then
         set the currenttime player "audioPlayer" to sDataA["timestamp"]
         start player "audioPlayer"
         --
         getPlaying true
         --
      else
         wait 300 milliseconds
         getPlaying true
         setMobileAudioPlayer "audioPlayer", "play", sDataA["timestamp"]
      end if

From the dictionary:

Description Use the wait command to delay a certain amount of time, or until something happens, before continuing a handler.

The wait command freezes execution for the specified amount of time, or until the specified condition has been met, or until a message has been sent

[Brahmanathaswami]

we Added

1. addJournalEntry put sTimeStamp into sDataA["timeStamp"] to journal enter. this way to start

  if not isMobile() then
         set the currenttime player "audioPlayer" to sDataA["timestamp"]
         start player "audioPlayer"
         --
         getPlaying true
         --
      else
         wait 300 milliseconds
         getPlaying true
         setMobileAudioPlayer "audioPlayer", "play", sDataA["timestamp"]
      end if

[Brahmanathaswami]

We added wait to journalResume

 if isMobile() then
      deleteAllMobileControls
      wait 100 milliseconds
   end if

behavior_ListenSelect, case "AudioList"

so that SivaSiva app we have sometime before/closing the player before booting the other songs.