We know that the beforeinstallprompt event is fired when the PWA meets the installability criteria.
Two of them are:
- The user needs to have clicked or tapped on the page at least once (at any time, even during a previous page load)
- The user needs to have spent at least 30 seconds viewing the page (at any time)
How can I reset the browser "memory" to test my PWA in a clean environment? If I open my PWA on my browser, I have already passed these two criteria so my PWA always prompts for the install banner.
But I need to emulate a new user for which the beforeinstallprompt is not triggered immediately.
I've tried in incognito mode, but Chrome doesn't quite fire the beforeinstallprompt event in this mode.
How can I do?
Many thanks in advance
Tried: incognito mode, deletion of cookies.
Related
We want to make our own app store as a website where all the "apps" are PWAs. Since people aren't yet used to the "Add to home screen" feature of PWAs, we want to make all the apps in our app store instantly launch the "Add to home screen" feature of the PWA.
For example, https://pwa.rocks/ is a nice "app store." But to add it to the home screen, users have to first navigate to the page, and then they are prompted to add it to the home screen. We want to skip step one entirely.
Your use case seems prone to abuse and has the potential to do serious damage both to your brand as well as the general perception of PWA's by your customers.
However, to answer your question, you could try using frames or iframes to achieve this. Here are the criteria to get the Add to Homescreen banner to show up:
The web app must not already be installed
Must meet a user engagement heuristic (currently, the user has interacted with the domain for at least 30 seconds)
Must have a web app manifest that includes:
short_name or name
icons must include a 192px and a 512px sized icons
start_url
display must be one of: fullscreen, standalone, or minimal-ui
Must be served over HTTPS (required for service workers)
Must have registered a service worker with a fetch event handler
When these criteria are met, Chrome will fire a beforeinstallprompt event that you can use to prompt the user to install your Progressive Web App.
Other browsers have different criteria for installation, or to trigger the beforeinstallprompt event.
Source:
https://developers.google.com/web/fundamentals/app-install-banners/
I have successfully integrated Paypal Embedded Chained Adaptive Payment system.
I have been testing it in sandbox environment. On GOOGLE Chrome, when user initiates the payment procedure, a light box gets opened with a login button inside it, but once user clicks on that login button, user comes across with following message
"Please continue with your purchase in the secure browser we launched. If you don't see it, click on Go."
The reason for this is that Chrome blocks the paypal login pop-up window. End user would not be able to figure out that what happened. Most of end users would not be aware about that paypal login pop-up window being blocked. Can we do something here so that we can avoid that pop-up window and can perform whole operation inside the Iframe only ?
Is there any solution this problem ?
Will it get resolved automatically once we shall move to production/live environment?
Please help me out.. We are going live very soon!!
I have been playing around with this a lot today and I too encountered the same issue with the lightbox. HOWEVER after much fiddling and time I decided to just try expType="mini" and it worked flawlessly. I did find one site that managed to get chrome to display the lightbox method correctly, but it was only successful about half of the time. It seems chrome is very sensitive to popups and sometimes it can be fooled and sometimes not.
Anyway the solution I found that worked was to scrap expType=lightbox and just go with expType=mini - seems to work without any problems. In the back of my mind I'm a little concerned that future browser releases (in particular chrome) will have updated popup blocking code may soon block this too. I hope this remains working, but I don't have a great deal of confidence in it. Make sure you have the good old Express Checkout method as a backup.
Hope this helped.
possibly a simple question, but I couldn't find definitive answer (see below for excerpt from HIG) myself that would state below scenario as 'unacceptable' and will result in app being rejected:
On 1st application launch after installation user will see an alert
asking to activate the app.
Tapping "Activate" will open Safari and display a web page with
"Activate" button.
Tapping it will launch my app via URL-scheme, pass some server
generated data and allow user to enter main UI.
The application will be locked until user activates.
If you need more context on why and how, please see this answer.
Mobile HIG (as of 2011-10-12):
"If possible, avoid requiring users to indicate their agreement to your EULA when they first start your application. Without an agreement displayed, users can enjoy your application without delay. However, even though this is the preferred user experience, it might not be feasible in all cases. If you must display a license agreement within your application, do so in a way that harmonizes with your user interface and causes the least inconvenience to users."
Well there's similar cases where an app is almost useless until the user registers to some service, take Instagram as an example.
I'd suggest however that you solve this by not forcing the user to leave your app. Instead, present the user with a web view within your app where you politely describe why it is necessary for the user to go through the activation process.
We've done something similar before (EULA presented modally within a web view on first launch, which could only be dismissed by accepting it) and it was approved right away.
Right now I am developing a Web-based Application, where the User has to login first.
When I open the Page by iPhone Safari, login and restart Safari, I am still logged in (Cookie & Session ID still set).
But when I add this Page with "Add to Home Screen", each Time i click the Icon for that page, I have to login again.
I did not find any information about that. What can I do so my users can set this page to their home screen
as icon and still don't have to login each time they open it?
A really simple approach could be to use a unique token in your Bookmark-URL which can serve you as a unique device identifier.
Example:
http://myWebApp.com/?token=randomId29238/1
The token can be generated at the server side at opening time of the application in Mobile Safari and before the user is prompted with the "Add to Home Screen" information.
The token can then be added to the URL using a quick redirect (…&token=randomToken) or a location hash (…#randomToken).
Whenever the Bookmark is now opened from the Home Screen, the token is sent to your server and you can identify the user's active session.
You may also use the token as a permanent session id, but I advise against that because of security concerns.
To allow future logout and login procedures, you can always assign the new sessions to the token.
The token will serve you as a unique device identifier whenever the user will re-open your link from his Home Screen.
There is an easier and, imo, more elegant solution than favo's.
At least under iOS 4.2.1, 5.1.1, 6.0 and 6.1 (I couldn't test other versions), if you extend the lifetime of your session cookie manually, Safari will hold on to the session cookie and even allow sharing of the session between the 'home screen installed' version of your web app and normal visits through Safari itself.
The trick is to do this:
// Start or resume session
session_start();
// Extend cookie life time by an amount of your liking
$cookieLifetime = 365 * 24 * 60 * 60; // A year in seconds
setcookie(session_name(),session_id(),time()+$cookieLifetime);
For a more elaborate discussion of this strategy you can take a look at my answer of this question:
Maintain PHP Session in web app on iPhone
I am going to expand a little further on Waldo Baggins' answer.
When I ran into this, I discovered the reason this was happening is that session cookies set on the server usually do not have an expiration value set. The default behavior in this case is for the browser to discard the cookie when the browser is closed / re-opened. Since the browser does not resend the cookie on re-opening, the server has no way of identifying the session, even if it hasn't expired on the server yet, and thus, your user is redirected back to the login page.
When the user is using your site in web app mode (icon added to home screen), iOS treats navigating to / from the app the same way a desktop computer would treat closing and reopening the browser, and loses the session when reopened.
So following Wilbo's suggestion and setting an expiration time for the cookie, iOS checks if the cookie has expired when the user navigates back to your app, and if it hasn't, re-sends the cookie, thus maintaining the session. The value of 1 year in Wilbo's answer is ridiculously long, you would typically want to set this to something like 8 or 24 hours, and ideally sync it with the session expiry timeout value you have set on the server.
Note that as a side effect, when your site is accessed from a desktop browser, and the user closes and re-opens the browser, the session would continue to persist and the user will still be logged in, which wouldn't have been the case previously (unless they were browsing privately). Your "Logout" feature would have to properly handle expiring this cookie.
For a Java webapp using web.xml version 3.0 or higher, the easiest way to do this is to modify <session-config> as follows:
<session-config>
<session-timeout>600</session-timeout> <!-- In minutes -->
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
<max-age>36000</max-age> <!-- In seconds -->
</cookie-config>
</session-config>
There are persistent key-value storage and database storage available for web apps. You can save your authentication data using localStorage object and use XMLHttpRequest to send it to the server.
Another option is saving your persistent data in a SQLite database, however this doesn’t seem to be a proper solution in your case.
Check out Apple’s Client-Side Storage and Offline Applications Programming Guide for details/examples.
I'm creating a web application meant to be viewed by iPhones, Blackberrys etc. My problem is that, when an iPhone user adds a link to the app on their home screen, they have to log in twice.
The cycle goes like this:
User bookmarks the app's homepage
User later goes to the homepage
They are brought first to the log in screen
After logging in, they are taken to the app's homepage
As soon as they click a link, Safari opens a new window in which they are brought to the log in page again
After logging in this time, everything works as normal
It seems like a problem with Session variables, though I can't seem to find any sort of elegant solution for it.
Also, the server is running ColdFusion.
Would it be possible to drop a cookie when the user first logs in?