I am working on a simple app that initiates Skype calls.
It successfully initiates Skype audio call using apple's URI scheme
[NSURL URLWithString:#"skype:skype_id?call"]).
But when I try to make a video call using
[NSURL URLWithString:#"skype:skype_id?call&video=true"]
it still initiates audio call and launches Skype but nothing happens after that (no audio call or video call is made). I have seen some posts where people mentioned that they used similar URI for making video calls for Skype in iOS that worked fine before but now it doesn't work.
I should mention that Android version of the app our team is working on have no such issue. It successfully starts making video call using same URI.
Is this a problem of latest version of skype developed for iOS?
this seems to be totally bust in skype for iOS.
even skype://username?call comes up with a fairly unintuitive modal saying "Placing call with..." which does NOTHING unless you click "Voice Call"
All works fine in other systmes / browsers (windows, mac osx, android), though https is bust in chrome. which is just dandy.
maybe https://stackoverflow.com/users/1383154/allen-smith or someone from skypes side can comment??
according to http://handleopenurl.com/scheme/skype you can use skype://username?chat in an html link. Now that sort of works - as in it opens skype, but still doesnt initiate the call.
You can't use the &video=true - IOS doesn't like it. Just use the ?call and it will work the same way it should (as if you appended the &video=true to it) and place a video call if video is available.
The skype stuff is pretty flaky - and my only success has been to use the skype buttons (using the skype-uri.js file and associated javascript for creating the buttons under HTTP (NOT HTTPS). HTTPS tends to break things in Chrome, and a few others.
What I did was sniff for IOS and remove the video=true accordingly so it works fine for all the other browsers too. End of the day, Skype really needs to clean up their act.
Related
I'm using the RTCMulticonnection library for a webrtc video streaming platform. It functions pretty much like this: There's a list of users, each with a profile page that has a chat button. Upon clicking this chat button, the caller is taken into a chat room page (a new browser tab) where he issues a connection.open() to create the room.
Afterwards a chat request is send through the node server to the callee, which gets a confirmation popup. If he accepts he is taken in the chat room page (a new tab) where a connection.join(roomId) is called.
My problem is that on ipad/iphone both the audio AND video stream are added only on the first call, either if you are a caller or a callee. If you afterwards want to call someone else on the ipad only the audio stream is added to the chat view, but from the remote side you get the video stream just fine.
Is there a flag that gets set up somewhere, somehow that I'm missing?
Also there's some cases that causes iOS devices to freeze up pretty bad so that they need a hard reboot, but I haven't pinned down the culprit.
On desktops and android devices the flow seems to work fine... so far.
This is a bug in WebKit:
Safari on iOS11 Freezes when viewing a cropped remote video
Frequent situations where iOS device locks up, requiring a hard reboot when consuming webrtc streams on IOS
It's solved since iOS 11.2.
I am trying to debug my web based HLS player (with HTML5 tag) and would like to monitor the network request to fetch the segments of the stream. This works fine in all desktop browsers (safari, chrome, firefox), and works with the OSX Safari, as well.
But when I connect to a iOS Safari (Simulator or real iPhone), only the request of the m3u-file shows up in the network monitor, not the requests to the segments of the stream.
Is there a way to monitor those requests on iOS Safari?
The reason I want to do this is trying to avoid automatic loading of segments while the player is paused/stopped. This works fine with hls.js, but I am not sure how iOS Safari handles the preload=none attribute. Although here Apple says that "Safari on iOS never preloads", this does not seem to be true when pausing the player. (see https://developer.apple.com/documentation/webkitjs/htmlmediaelement/1633059-preload, too)
Thanks!
P.S.: I tried to get any information in Apple's forums before, unfortunately without any success (https://discussions.apple.com/message/32027089#32027089).
You can monitor these requests like any other. I recommend Fiddler... It works as a proxy server and can be used to monitor or edit traffic, even with HTTPS. For lower level debugging or cases where you can't use a proxy, use a packet sniffer like Wireshark.
I'm developing a site for a client and am stuck at this point, as both of us have been able to recreate this issue in Chrome on Android.
For whatever reason, when we load this page on Android in Chrome:
http://miso.gostppro.com
The video loader just keeps spinning and spinning and the video never plays.
And tapping it on it doesn't do anything either (doesn't start the play, doesn't open it in YouTube app, nothing).
It works just fine in other browsers (Firefox for Android loads it and plays it just fine), so I'm confused as to why this is happening.
What am I missing?
Is it some call in the API or something?
I'm lost.
In short, it won't work. Quoting the documentation:
The HTML5 element, in certain mobile browsers (such as Chrome
and Safari), only allows playback to take place if it's initiated by a
user interaction (such as tapping on the player). (...) Due to this
restriction, functions and parameters such as autoplay,
playVideo(), loadVideoById() won't work in all mobile environments.
You're calling event.target.playVideo(); in your onPlayerReady handler, which is not allowed in mobile environments and throws a warning in console (for future reference - I highly recommend using Remote Debugging in Chrome).
So, back to your problem - I'd just get rid of the onPlayerReady handler and use autoplay player variable instead. It should work on desktops and not break the player on mobile either.
I tested your webpage on my Nexus 5 running Android 5.1.1 and found a few issues:
First I was getting this error:
Failed to execute 'postMessage' on 'DOMWindow': https://www.youtube.com !== http://miso.gostppro.com
Which I thought was an http vs https error, but after I refreshed the page with error went away and I saw a new warning:
Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture.
As pointed out in jkondratowicz's answer, this is a byproduct of mobile browsers disallowing autoplay on HTML5 videos. The only think I can think of is remove any JavaScript related to the player and the autoplay parameter and allow the user to manually start video playback when they're ready.
I was also getting mixed results results with adding an listener to the page load event which calls play() on the iframe:
function callback () {
document.querySelector('ytplayer').play();
}
window.addEventListener("load", callback, false);
I'm writing an app for iOS 7 only that uses SoundCloud. But the problem here is that sometimes I fetch sounds that have the streamable property set to TRUE, the stream URL but I'm not able to play it. The player simply hangs. This also happens on OS X.
I know that a couple of sounds from SoundCloud are streamable only with Flash. But if you use the mobile version of the site, then all songs are streamable, even those that needed Flash to run on the desktop version.
What I want to know is how can I play those sounds since they are supposed to be streamable?
One of the sounds that shows this happening is this one:
http://api.soundcloud.com/tracks/99350098/stream?client_id=[YOUR CLIENT ID HERE]
Thanks,
Abras
From other posts it seems SoundCloud have changed/are in the process of changing the protocol they use for streaming between http and rtmp. The problem being that rtmp is flash, which obviously won’t work on iOS and possibly on osx (flash is not install by default).
You can check by going to /streams (not /stream)
A check (http://api.soundcloud.com/tracks/99350098/streams?client_id=YOUR_CLIENT_ID) of the track you gave above, this returns a rtmp url.
I need to view some local (saved somewhere in the iPad) html / js contents with mobile Safari. By reading some threads it seems that the file:// protocol is disabled. Right?
If so, the solution I see is to install an app which turns the iPad into an http server (no need for support of php or anything else), load my contents there and access somehow them within the same device by http://localhost/... or http://127.0.0.1/... with mobile safari.
Is that actually possible? Can someone please suggest me a good web server app which possibly does not require jailbrake or other hacking?
Thanks!
You probably can't do what you want because in order for your application to be serving up HTTP requests to Mobile Safari, it would have to be running in the background, and there's no permissible background mode that covers this.
If you only need a one-time-only response immediately after running your application, then you could possibly use beginBackgroundTaskWithExpirationHandler:, although this might not be approved by Apple - it's difficult to predict their response to that.
If you are sure that you don't need this to go into the App Store, then you can get your application running in the background permanently by abusing one of the other background modes, such as pretending to be a VOIP app or media player.
Once you're running in the background, you can use CocoaHTTPServer to actually serve the files.
If you describe what you are trying to achieve, somebody might be able to suggest an alternative approach to using local files / Mobile Safari.