Post not yet marked as solved
Instead of using buttons, use images:
app.images["cardMenu"].tap()
Post not yet marked as solved
Adding more info here as it's over the limit of a comment.
I used WireShark to capture the packets from the real device. Looks like when the upload task is in a foreground URLSession, the session establishes http/3 QUIC connection without trying / waiting Http/1.1 first. This is expected as I am using assumesHTTP3Capable = true. But in a background URLSession, looks like the system tries to talk to Http/1.1 first, and as the server only talks http/3, the task fails to start. Is this behavior expected? If yes, why the difference between a foreground session and a background session?
Post not yet marked as solved
I have found the root cause: I missed setting "Objective-C Bridging Header" for Release.
The reason that the build worked for both the simulator and the device is that both of them are running the app in Debug mode, not in Release mode. But Archive requires building in Release mode.
Now I've added the bridging header in the Build Setting for Release mode and the issue is gone.
Post not yet marked as solved
Finally I created a new AVPlayer for each item, i.e. no longer replacing an old item with a new item in the same AVPlayer and the issue is gone.
Post not yet marked as solved
I tried something different: instead of wrapping UIView using UIViewRepresentable, I changed to wrap AVPlayerViewController using UIViewControllerRepresentable, and then don't use my own video controls anymore. It seems like:
If I share the same AVPlayer for each video item (i.e. each AVPlayerViewController), then I still have the video track freezing problem when scrolling between video items.
If I create a new AVPlayer for each video item, then the video track freezing problem is gone. (I'm yet to find the best way to dismiss / stop AVPlayerViewController in wrapping swiftUI when it's scrolling off screen, any suggestions?)
Post not yet marked as solved
Never mind, I changed to a different approach to use AVPlayerLayer instead, and now it works.
Post not yet marked as solved
Here is the screen shot that shows Xcode disables the constraints setting for the image view inside the scroll view:
Post not yet marked as solved
Can I ask what version of XCode are you using? I'm thinking whether it's a bug in XCode. (I am using XCode 12.5.1 on macOS Big Sur, and using Objective-C).
Post not yet marked as solved
@Claude31 thanks for your response! My main problem is that XCode does not allow me to do the step in your "Create a UIView": "Define the constraints with respect to the scrollView (Superview)" .
I.e. I am able to set constraints for the scroll view, but cannot set any constraints for the image view inside the scroll view.
Please see attached screen shot of my current constraints list of the scroll view.
Post not yet marked as solved
Sorry about my late response. I am trying to use iPhone to communicate with other devices in the same WiFi LAN, and wondering if can use TDLS to reduce the load on the WiFi router. If not TDLS, is there any other thing I can use for iPhone to achieve the goal? Thanks.
The third-party framework (Cronet from chromium) I am using was not provided as xcframeworks. Its source code is available but has its own build script (not Xcode). I will look into it but not having high hope per my understanding.
Post not yet marked as solved
I found the problem. The reason is that AVPlayerItem (and AVAsset) cannot handle a URL for video if there is no known file extension, e.g. something like ".mp4".By observing the "status" key of AVPlayerItem, I found the error reason is "This media format is not supported" even though I have already set the content-type as "video/mp4" in ContentInformationRequest.Anyway, after manually adding ".mp4" in the URL, I was able to get additional loading requests after the 2nd request was cancelled. And the video playback works now 🙂 .Btw, this bug / behavior was reported on 2012, but it seems still not fixed. http://openradar.appspot.com/radar?id=1516408
Post not yet marked as solved
I compared the sequence of requests with a regular case when AVPlayer is created with a http URL without using delegate. I have two observations:1. In both cases, AVPlayer has first request asking for ContentInfo and range 0-1 (2 bytes) and 2nd request asking for the whole range (full length) of the video asset.2. In regular case, AVPlayer seems to "cancel" / "stop" the 2nd request as well, after receiving some (around 100k bytes) data.3. In regular caes, AVPlayer will continue to send 3rd request with requested offset following the 2nd request data received. But in the problematic delegate case, there was not 3rd request. So, now the question is, why didn't the delegate get a 3rd request from AVPlayer?
Post not yet marked as solved
I did not get further requests after the cancel.The cancel is still confusing to me as I'm testing locally using iOS simulator and local server, which has very low latency for the response. And it seems it was cancelled after 3 times of dataRequest respondWithData().
Post not yet marked as solved
Just to follow up, from my research elsewhere, looks like only if AVAsset has a custom URL scheme, AVAssetResourceLoaderDelegate will be called. In other words, known schemes like "http" or "https" will not trigger AVAssetResourceLoaderDelegate.
