Player Object Problem When App Wrapped for Mac Store

[lrieber]

I have created a cool little app to allow users to tag, comment, and organize the content of a video stored on their computer. I store all of the program files in the user's documents folder in a folder the app creates called "VAT Program Files." These are just a bunch of text files that store the various information for each video that is analyzed, such as the name of the project, and the path to the video on the user's computer, and all of the user-entered data about the video.

I submitted this to the Mac App Store and they found a bug and rejected it. I need some help resolving this bug. I am using LiveCode 8.01, though the problem occurs even when using LiveCode 8.0 or LiveCode 7.0.6. I used AppWrapper 3 to wrap it with the necessary Apple certificates.

Before I describe the bug, it's important to know first that the app works just fine as a stand-alone. It also works fine if I wrap it for web site deployment. The problem only occurs if I wrap it for Mac App Store deployment. The key difference between these three scenarios is that only the Mac App Store deployment uses the Mac's sandbox area. That is, instead of putting the "VAT Program Files" folder in the typical user's documents folder, it puts it in the documents folder found in the app's sandbox (the path is "users > johnsmith > Library > Containers > com.nowhereroad.LloydVat"). (I'm using John Smith as a convenient alias.)

OK, here's the bug:

-I open the app and start a new project.
-The first thing I'm asked is to find a video to work on. I use the "answer file" command and it generates a path to the video stored on my computer, such as this:

/Users/johnsmith/Documents/Videos/beach.mp4

The path to this video is automatically stored and saved in one of the text files saved in the folder "VAT Program Files."

-All works great as I work on the Beach project during this initial session. The videos plays perfectly. I save everything and quit the program.
-I come back and work on the project again. I open the app and open the Beach project. The app finds the video (I have a script to check if it "is there," but nothing appears loaded into the player object. The duration of the movie is 0. I put in some script that asks the user to find the video again if the duration is 0. The user finds the exact same video again (using the same answer file strategy) and the exact same path to the video is generated as before. The video now plays fine. I store the newly found path (even though it is exactly the same as the previously stored path) and continue working on the Beach project. Again, the video plays fine for the duration of the session. I save all and quit the app.
-I come back to work on the project and I have the same problem.

Again, all during the above, the path to the video has remained the same:
/Users/johnsmith/Documents/Videos/beach.mp4
(I had this path update on the screen at every step as part of my troubleshooting.)

At first, I thought I had been using a relative path to the video that was thrown off by the fact that the Mac Store deployment version was using the documents folder in the sandbox, but that doesn't seem to be the case.

All of the symptoms seem to point to something going on with the Player object. It somehow needs to be "reset" with the path to the video.

In summary, I'm stuck while tantalizing close to getting this app into the Mac App Store.

Thanks in advance - Lloyd Rieber

[Klaus]

Hi Lloyd,

check the result after (trying to) set the filename of your player object.
Maybe that will give a hint on what is going wrong over there.
...
set the filename of player XYZ to the_saved_path
answer the result
## Will be empty on success or give an error description
...
Sorry, no other brilliant idea in the moment...


Best

Klaus

[lrieber]

Thanks, Klaus, for the suggestion. I added the "answer the result" and I get the message "could not create movie reference." So, that is a clue, which I am grateful for.

Here are two other clues...

1. I launch the app and work on a previous project. As already stated, the app can't run the video. If I then tell it where to find the video, it works. And, as long as I don't quit the app, it will continue to always find and play the video even if go and work on other video projects. But, if I quit the app and try accessing the video, I get the error "could not create movie reference."

2. I put a copy of the video file in the documents folder inside the container "com.nowhereroad.LloydVat." When I create a new project and choose the video stored there, everything works, even if I quit the app and restart it. So, there is definitely an interplay between the player object and the Mac sandbox.

Thanks - Lloyd

[lrieber]

I emailed the problem to the good folks at App Wrapper 3 and they provided an excellent explanation of what is going on (see below). Now, I don't have a clue how to implement any of these fixes, so if anyone can help me out with this, please let me know. I also think this information will be very helpful to anyone wanting to create an app with LiveCode for the Mac App Store. I also heartily recommend App Wrapper 3 - http://www.ohanaware.com/appwrapper/ - to all LiveCode developers. It's very easy to use and very affordable. (Yes, that was an unsolicited and unpaid endorsement.)

[indent]On 5/25/16, 10:38 PM, "Sam Rowlands" <sam@ohanaware.com> wrote:

Hi Lloyd,
My name is Sam Rowlands and I’m one of the developers here at Ohanaware. Thank you for your e-mail.

Yes, I know exactly what your problem is. It’s basically one of the ‘things’ with the App Sandbox.

Basically once an application has been Sandboxed your application only has access to those files for the duration of it’s life cycle. Once the application is quit, access is lost.

So when your application re-opens and reads the path from the text file, it has no access to that file.

I confess that I don’t use LiveCode so I don’t know how this would be done, but the Apple functionality you need is one, or all of the following.

* Apple’s Recent Items, if you can use Apple’s Recent Items system, it auto retains file access. Simple add the file to the recent items [[NSDocumentController sharedDocumentManager] noteNewRecentDocument: NSDocumentID]. It can be done with a NSURL, but for some unknown reason NSDocuments are more reliable.

As long as the file is in the Apple recent item menu (your own won’t cut it) you can re-open it.

* Apple’s Resume functionality, if you can use Apple’s Resume system, again it auto retains file access. The very basic of this process is to create a NSDocument and attach it to window. Then when your application re-opens it can access that file.

* Apple’s Security-Scoped Bookmarks, are special references uses for holding onto file access. These are the least recommended way of working with the Sandbox as they’re fragile and horrible to use. Every time you need to access the file, you must request permission first and relinquish it once completed, failed to release permission can actually prevent your application from working on the computer again and can lead to a complete system crash! These also do NOT work with many of Apple’s own frameworks, especially Core frameworks that use Lazy loading.

Hopefully someone in the LiveCode community has some code for you that will enable you to use one of the first two options.

The last option, is to move the file into your application’s container. Any file in your application’s container, your application can access any time.

~/Library/Containers/<bundleID>/Library/Application Support/<bundleID>/

When you first move the file into the container, you can then create a hard link at it’s original location. There is still only one copy on disk, but there’s two ‘links’ to it. One your application can access and the other is in the original location, so the user doesn’t phreak out when their file is missing.[/indent]

[jacque]

Right now we don't have access to either of the suggested methods. They'd make good libraries when the recent campaign goal is implemented, which allows us to wrap system APIs in LCB.

For now I think your only workaround is to put up an answer file dialog at every new session, with the file path set to the stored value for quick access.

Or alternately, copy the video to the app's sandbox, but that is going to use up a lot of disk space and may annoy users.

[lrieber]

Thank you, Jacque, for your information and your thoughts on this. I have been thinking as well about using the approach of having the person "confirm" the video for an existing project when they begin a work session as a reasonable fall-back position.

Using that line of thinking, I've been wondering about any way to mimic the "answer file" procedure without actually requiring (annoying) the user to click another button. Could the entire "answer file" interaction be scripted somehow?

Learning tons here...

Thanks - Lloyd

[jacque]

Answer file is intended only for user interaction, so no, you can't answer for them. And Apple's rules require a direct user request before an app can retrieve a file outside the sandbox, so I think you're stuck with that.

[lrieber]

Thank you for that clarification as it will save me time from going down a deadend.

Lloyd

[lrieber]

Well, I'm happy to report that my app - Lloyd's Video Analysis Tool - is now in the Mac App Store. Here's the link:
https://itunes.apple.com/us/app/lloyds- ... ls=1&mt=12

Thanks to Klaus, Jacque, and Sam (of Ohanaware) who helped me get through that last quarter mile. As always I learned a lot along the way, some of which I've described in a blog post on my learninglivecode blog:

http://learninglivecode.blogspot.com/20 ... n-mac.html

I hope this forum thread and my blog post capture the most important issues and information about the problem I encountered so that other LiveCode developers can benefit.

Developing this app was slow, but enjoyable. It's obviously very satisfying to have it now published in the Mac App Store.

On to my next LiveCode project...

Lloyd Rieber

[kurt]

Thanks for posting the link to the summary of your "journey"; it's especially interesting to read how you arrived at a compromise which allows your app to fully function with a minimum of user inconvenience. It's also good to hear that your experience in working with Apple software testers was largely positive.