I have a fairly standard ASP.Net web application which is used via mobile safari on the iPhone.
Some users who have a link to the web application placed on their desktop via profile are reporting that when navigating between pages (which I do on the server with Response.Redirect after specific events or via standard anchor tags in other cases (no target specified)) that Safari opens a new window instead of reusing the existing window.
Because of this, any login token/cookie etc (i'm using the built-in ASP.Net membership stuff), is now gone for that new browser window and the login prompt is shown.
The problem doesn't happen every time, and I can't seem to replicate it on my device (but i'm not deploying the shortcut via profile)
As you can probably imagine, it's quite frustrating for the users to have to log in every time, and you can't fix an issue you can't replicate.
My question is, has anyone heard of this issue and/or know a workaround?
The app is NOT iPhone specific, that is, it is used in a full desktop browser as well, and the logins stay like you'd expect there - and the same window is reused repeatedly.
I've considered a few possibilities, but have been drawing a blank as far as what might be causing this or how I can resolve it.
Do you have any iPhone meta tags set (to remove the url bar or the toolbar, for instance?) If you do, the phone will assume it's a native web app, and urls will open in a new safari window, like they would for any other native app.
If you are taking advantage of using the web app in full screen mode (where it is bookmarked to the launch screen next to native apps) you can prevent it from jumping out of fullscreen mode by and in to safari replacing type links with javascript.
location.href = '/yourPath';
This is a nifty trick which even works if you are linking to an outside URL, like doing an OAuth to Facebook and back.
I have a blog post on this here: http://www.aaroncoleman.net/post/2011/07/29/Keeping-iPhone-Web-App-in-Fullscreen-mode-from-Homescreen-Launcher.aspx
Related
I don't know if this is specific to the newest update of IOS 13, but I'm having some really strange PWA behavior. When I initially add it to my homescreen, links on the page open in safari rather than inline on the PWA (none of the links are set to __blank by the way), but when I sign in with oAuth on safari and then add it to my homescreen, it functions like it should and it works normally with links. (Currently using Passport with Node and Express for authentication) I don't know if there's some security infrastructure or something to do with packets, but it's really strange and I'd like to resolve this as soon as I can before my userbase gets frustrated.
I've tried looking through my manifest but everything is up to spec as far as PWA standards go. I have the display set to standalone, I have all my tags setup correctly, Lighthouse audit also says it should work. I've looked through the passport docs, traced my authentication code, but nothing seems to work.
It looks like Apple changed the home screen/standalone web app behavior in iOS 13, but I cannot find any official documentation on this. Now it seems that if you did not have a manifest.json setup before the web app was added to the home screen, it only treats the initial page as being in scope for the standalone view. Hence any other link/redirect opens in another window or the in-app browser.
We have a web app installed on our user's home screens that was written years ago and functioned just fine up until iOS 13 without a manifest.json file. I had to rewrite the WebSQL code in our app to use IndexedDB instead since they completely dropped WebSQL from home screen web apps in iOS 13, even with WebSQL re-enabled in the Safari advanced setting. When I started testing on an iPhone, any link or redirect, even using window.location.assign or any number of other methods would always open the next page in an in-app browser with a minimal UI. This also messed with the page geometry as what was a full height page with no scrolling, was now scrollable with our 'Next' button elements pushed off the bottom of the screen. Since we have some scrollable panels in the middle of some pages it wasn't obvious how to get to the end of the page (you have to scroll a fixed element to scroll the whole page) so that was not going to work for our users.
Long story short, adding a bare minimum manifest.json file to the web app (doesn't even need the scope setting) and deleting and re-adding the web app to the home screen then makes it behave as before with all pages showing in the standalone view. Adding a manifest.json to an already installed home screen app does not affect the behavior.
I'm looking to link to a sign up page on an external webapp via a chrome app. The simplest way to manage this seems to be to open a new tab in the chrome browser (not a new webview in a new window of the app).
Tabs seem deprecated and a webview appears very unofficial and unsafe. Basically, is there a way to effectively do this:
Sign up
And the bigger question of course: is there a better way to approach what seems like a simple problem?
Your conceptions, "Tabs seem deprecated and a webview appears very unofficial and unsafe", seem very strange. tabs is simply not enabled for Apps, and <webview> is alive and well.
But if you must open it in the browser, window.open will do the trick. See also this question.
Edit: Also, upcoming is the chrome.browser.openTab API. Leave your feedback if you have use cases for this feature.
This morning I had a look at my blog on my iPhone and noticed that when I view a specific page a Reader icon comes up next to the URL in the address bar:
When I press it, I get an interface like this:
This functionality was completely unintentional (I wasn't even previously aware of it) but I think really nice, so I want to try and implement it intentionally on a few other pages on my website (and other sites that I work on).
How do I work with and enable this feature?
You don't need any work on your site. This is build-in feature on iOS Safari.
Can we build an Application using UIWebView that will entirely mimic the Safari Browser?
Are there any cases where UIWebview can not do what that can be done in Safari?
For one thing, you have a separate cookie storage per app. So if a user has some preferences at site X within Safari, it won't have those preferences at site X within your browser, and vice versa. Apart from that a UIWebView is very much like the real thing.
You cannot easily build an application that mimics the Safari browser using the public API exposed by UIWebView component. For one thing, please look at the UIWebView delegate methods. When you have frames inside the page you want to load, you may have a hard time telling if a user has clicked inside an iframe/frame or clicked on a link in the main document.
Dealing with authentication to site with invalid certificates is also hard with the UIWebView component, especially when the site with invalid certificate is reached by clicking a link inside an iframe.
Rendering content in UIWebView will be much slower than it is in Safari.
Safari's Javascript engine uses a "just in time" compiler. It takes the incoming Javascript code and transforms it on the fly into machine code that can run directly on the iOS device's ARM CPU. This allows Javascript code to run at a speed similar to a native app's code.
The problem is that Apple doesn't trust third-party developers with this power. If a third-party app had the power to convert Javascript into machine code and run it, that app would also have the power to download and run other pieces of machine code—and Apple would never get the chance to review that code. Once App Review approved it, (developers/hackers) can change the downloaded code into something that logs your passwords or something. And there's no way to grant this power only to UIWebView and not to other parts of an app, because UIWebView runs in the same process as the developer's code.
So basically Apple forbids this because allowing it would break the security provided by the App Store and make iOS more vulnerable to attack. They can allow it for Safari because they control what Safari does, but they can't trust others not to abuse that ability.
Sorry for the long explanation. Thanks in advance to all who are taking their time.
I am an Ubuntu user who has set up Titanium Developer on a MacMini in order to build an app for the iPhone (and ultimately some other platforms).
Rather than having any local code built in, the app simply points to my website. To do that, all I needed to do was change Titanium's tiapp.xml file to include my website URL. I wrote no other code, nor did I need to include any other files. It simply compiled and ran in the emulator without a hitch.
I've got just one problem: I need to upload files to my website and Apple, as most of you know, has disabled the input field type=file. I've got it working in all other browsers. The action simply calls a php file and passes the file info.
If I didn't have an app, and someone was just manually navigating to my site with the iPhone's Safari browser, I could get around the problem by using CliqCliq, which is a very cool iPhone app. Basically, I use JavaScript window.open() to launch CliqCliq's QuickPic browser in a second Safari window. The user chooses a file; QuickPic uploads it; and the user is returned to the second Safari window that I launched with window.open(). The user closes the window and Safari returns them to the first window (i.e., my website).
The problem is that my website is being shown in my app. (By the way, I don't have my developer license yet, even though I signed up a few weeks ago, and I can't test this in the emulator because I can't install QuickPic into it, I assume.) I wanted to repeat the same steps, described in the previous paragraph, using an iFrame but that didn't seem to work (i.e., the iFrame was blank despite my designating a src). I also tried having a hidden window by using old-fashioned frames and setting the col-width to 0. That also did not work (i.e., Safari, if I recall correctly, opened a separate window).
I'm working a little blind, since I can't test anything on the iPhone, but I figure I have two options: I can either find a way to launch a QuickPic in an iFrame -or- I can find some way to incorporate the Apple toolkit file chooser into the Titanium app.
The problem with the first option -- but again, I don't know until I can try this on the iPhone -- is that I assume both apps (mine and CliqCliq's) could not run at the same time. Even if I had a hidden window, invisible iFrame, etc., the moment it launches QuickPic, I assume my app would quit(?).
The problem with the second option is that I don't have clue as to how to incorporate a file picker into my app by using Titanium (keeping in mind, everyone, that I know very little). Brian at CliqCliq has even offered to give me some code if I can't make Apple's file picker work but again, I'm not sure what to do next.
What do you folks think? What's the best method? And, what's the easiest thing for a simpleton to do?
Thanks.
<input type="file"> is not supported on the iPhone. You'll need to use Titanium's APIs, specifically the Media one (openPhotoGallery or showCamera).
As a side note, Apple reportedly rejects apps that are just a webview displaying a website. You may want to consider putting most of the app code in local storage and using AJAX to fetch content.