recently I’ve been running into an issue getting file downloading working on iOS. It seems like specially for Chrome/Firefox on iOS, the device requests the download route twice, once before the user clicks the ‘download’ prompt, and once again after the user presses it. This is not a problem on Safari for iOS, and it breaks the authentication for my download routes.
I did make a demo: https://github.com/subnub/ios-chrome-download-example
You’ll notice in the demo that if you use Chrome or Firefox on iOS it requests the download route twice, not only that it will serve up all the bytes of the first request, and just discard all of them. But, if you use Safari, it will only make the download request once like it should.
Any advice would be greatly appreciated, I’ve been stuck on this for some time now.
Related
I have universal links working correctly, when the app is installed I see how the link opens the app, and when it's not installed opens the url in safari.
Actually what I would like to do is to redirect and go to the app store, so users can download the app directly.
Im going to include a redirect on the html file, because I know universal links don't support redirects a the http server config level (anyway I think this is for the manifest file only, apple-apps-site-association)
Anyone can confirm if this is the right way to do it, or the only way to do it? I don't like the idea to open safari first, load my html (with the redirect only) and then go to the store. Looks like there's no easier way to do it.
You're right: server-side redirects aren't allowed for the apple-app-site-association file. However, I believe once the user opens a Universal Link and (assuming the app is not installed) lands on the URL, all options are on the table (server-side, or otherwise).
If the page on the other end of your Universal Links URL contains an instant JS redirection to your app's App Store page, that should work just fine. Something like this:
window.location = 'itms-apps://itunes.apple.com/us/app/imdb-movies-tv/id342792525'
But yes, no matter how you do it, Safari is still going to open. It'll flash past so quickly that the user likely won't even notice. Here's a real-time recording I just made of the Branch.io deep linking service's demo app doing exactly this process:
From here: https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html
"When you support universal links, iOS 9 users can tap a link to your website and get seamlessly redirected to your installed app without going through Safari. If your app isn’t installed, tapping a link to your website opens your website in Safari."
You're not doing it wrong, that's just how they work.
My problem
I'm working on a project where Cordova is being used to display a remote website within the app. Cordova.js is being run from the remote server, etc., and this works pretty well.
I do have one issue though, especially on iOS devices.
If the device lose connection at the same time as I press a link on the website, the page will turn blank, as if to load the next page - but since the connection is lost nothing will be loaded into this blank page. Given iOS devices lack of back-buttons or such there's no way to navigate from this blank page except by closing the app and re-opening it.
My attempted, and failed, sollution
So, given that I can use Cordova.js to check for connection issues, I figured that I could use an iframe to display the remote website. If the connection goes bye-bye I'd just display a simple error message inside the iframe.
And well, this does work.
BUT. And this is a big but. InAppBrowser will not run from an iframe. And I can't live without the InAppBrowser, since it's used to display quite a few important features within the app.
So
Does anyone know a way to either:
a) Handle connection issues when running only remote content in the Cordova app?
b) Run the InAppBrowser from within an iframe? (I suppose I could use PostMessage etc. between the frames, but since I'm already sending/receiving data from the InAppBrowser I would love to avoid this in order to limit complexity).
c) Solve this issue in another fancy manner?
We have link functionality in our web application that when clicked, browses to a page on our server that performs the following:
Tries to open the custom url to our ios application
If this fails, it redirects the user to our ios app store to download the app.
This actually all works perfectly well.
However, it creates a weird corner case, where after a user has done this and finished, if they come back sometime later and open their safari on the same phone, if our web link is still the active tab, it will redirect them again to our application.
The cause of this is fairly obvious, but we are struggling to come up with a solution for it. Is there any known to rectify this behavior, either through a different mechanism then I described for opening the application or through somehow killing the page simultaneously?
I have a HTML page with a Download app button. When clicked by an iOS user, it redirect the users to the App Store via itms-services. The link I used here is:
window.location.replace("itms-apps://itunes.apple.com/app/id578505616");
It looks like so on a mobile browser:
Facebook/Pinterest has an in-app browser which asks for the user's consent before redirect the user out of their app in the form of an Alert box with Cancel or Open app, which Open app opens the external link. It looks like this:
It looks like this with the Alert box:
Assuming the user is using an iOS device. The expected behavior here is when the Open app button is clicked, the user gets redirected to the App Store app. However, we are seeing about a 10 seconds delay before the actual redirection happens.
See videos below:
https://www.youtube.com/watch?v=_dgh7v-IsK8
https://www.youtube.com/watch?v=_LFHeRnBFgg
https://www.youtube.com/watch?v=82Y-kj-pMyw
Notes:
I can't seem to reproduce this at all times. It is only reproducible sometimes. Sorry!
Once a device is delayed for the first time, all subsequent links to AppStores will be fast, until roughly 1 day late. Rebooting the phone and/or clearing the browser cache and/or reinstall Facebook/Pinterest does not help reproducing this.
I tried to replace the itms-apps:// link with https://itunes.apple.com/us/app/trusper-tips-tutorials-how/id578505616?mt=8, but we were still experiencing the delay from time to time.
The delay seems to be exactly 10 seconds.
Why does this delay occur? This seems like a bad user experience.
My current theory is that the problem is on the Apple side. The reason being, once the Open app button is clicked, it is out of the hand of our website, as well as Facebook/Pinterest app. I presume, once the button is clicked, iOS is handling the actual context switch from one app to another. Therefore, it suggests that either the system call actually opening the URL is hanging, or the system call opening the App Store app is?? However, I haven't been able to prove either one to be true or false. Does anyone have a better explanation?
[Edit 04/02/2015]
I can confirm this problem still exists as of today on my phone (iPhone 5S w/ iOS 8.2).
I did some further research and found this article which I think is suggesting that this is a iOS system-related bug: OpenUrl freezes app for over 10 seconds
As there is no proper documentation on how it works, it is hard to pinpoint the cause of it.
Let me advance a theory.
Opening an app from browser causes a context switch; indeed from browser to App Store. So for the very first time it'd cost some time, while in subsequent times it will open faster as it will get opened from cache.
If you consider AppStore uses Keep-alive connection between iOS AppStore in device and iOS AppStore Server for the first time socket opening in server would seem higher than the subsequent times as subsequent request would reuse the same connection.
If the app is removed from the cache then it'd again take some time for the app to open and there would be a little network delay as the app would have lost the cookie for keep-alive connection then the app would have to endure the socketing opening cost.
There are also other factors like Safari hanging, resulting in some delay. You can read how Safari can be messed up here.
iOS doesn't have garbage collection, only things like ARC (Automatic Reference Counting). Each has its own advantages and drawbacks. Sometimes these drawbacks can surface and cause some problem; nothing is to be ruled out. For example a memory leak or app-crash might leave dangling pointers.
Technically, using itms-apps should give a little advantage over plain iTunes url because itms-apps should narrow down the search; itms-apps mean iTunes Music Store-apps.
A plain iTunes URL may be a Book (iBook), Music (iTunes), App (Appstore), etc ... so iOS might have to decide which app to launch.
I hope this helps.
I am trying to create an application on BlackBerry 9930 simulator that authenticate the user with Facebook, using the BlackBerry Facebook API. It connects to the login page fine, but after that the entire application crashes, either when asking to review the permission or when the login has succeeded.
I noticed that the authentication process went well since I get a message from Facebook that there is a login, so I am suspecting either the problem with the browserField and/or the simulator. (I tried 3 different BB 7 simulators, all the same though).
Anyone has a way to resolve this? Thank you so much.
It seems that no one has any solution for me :(. But, after messing around with it, I have found an explanation and a solution for it and I think I should share this with you. Sorry for the lateness in the response, though.
Here is the story.
As you probably already know, after supplying the credentials, Facebook returns the access token in the URI which is followed by the # symbol. Now, the BlackBerry Facebook API overrides the handleNavigation() method to ensure that, if the URL contains the access token, it will not be processed. This used to work in earlier versions (prior to BB 7) but somehow, it seems that URL redirection in BrowserField are no longer calling handleNavigation(), but rather handleResource() directly (I don't know why and, to my knowledge, there is no documentation for this change anywhere). The result? It always tries to process the URL that contains the #access_token in it.
Worst, the BB BrowserField thinks that # means a jump to a portion of the page (which doesn't exist). Other browsers (including the BlackBerry Browser) seems to understand that already and print only "Success" on the screen, while the BrowserField does not. And when that happened, the application just stopped working and crashed, sending me back to the home screen.
So what I did was I changed the source code of the BlackBerry Facebook API so that handleResource() now checks by itself whether the access_token is in the URL. Then, the application works fine.