We built a PWA with Ionic 3, which is a multiple page application. We host this on a linux server with nginx and use Laravel as a backend
The situation
We have seen that a update to a PWA is not always instantly, our client requested that if we released a update this would happen instantly and automatically.
What we tried
File based caching:
Our first thought was to use the concept of (old fashioned?) cache busting, so when building the app we use a random hash string in the filename. This ended up causing a major issue: Some PWA’s seem to hold on to the old index.html. In our access log we can see that old files get requested. The result being people will see a white screen after the splash screen. The only way for them to fix it is to reinstall the PWA completely.
Url based caching:
We devised a new plan: instead of using random hash string in the filename we moved in to the folder name. The request path would look like this: ./build/98312uj91eh9u2e/vendor.js. With NGINX we remove the hash and serve the same file, so it will return the the file from this path: ./build/vendor.js. This caused another issue where files would be mismatched. So some user would have parts of the old version and parts of the news versions which caused a lot of random issues.
Hosting multiple versions hoping they would update:
This pretty much did nothing other than creating lot of confusion. because some PWA’s would never update some people would be stuck on a old version and not see the new features.
Our current idea
Instead of using a static html file we are thinking of using javascript to make an API call to the backend of the PWA. Which will return a string with the current version of the PWA. This version will be the random string contain within the file names. This way, regardless of index.html updates, the content well be dynamic and not cause issue before description issues.
So what is the question?
Is it a good idea to make use of the concept where we would use JavaScript for making an API call or would this cause other issues we have not thought about yet.
Related
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
So based on my searches this has been a long-standing bug on iOS/Apple’s end. As of yet I haven’t been able to confirm a workaround so would like to see if I’m up to speed on this.
I incorporated a new favicon on my site with the help of realfavicongenerator, and it’s showing up everywhere except Safari iOS where a faulty cache seems to force the old image to show when the site is favorited or bookmarked. Adding to homescreen works fine, MacOS favoriting/bookmarking works fine, Safari iOS doesn’t.
I remember having a similar issue when incorporating the first apple-touch-icon a few years ago, also using realfavicongenerator: when favoriting/bookmarking in Safari iOS the icon was empty instead of showing the image. Eventually it showed up but I don’t recall how or exacty when, but it definitely took a lot longer than it should have.
I’ve obviously tried clearing cache and website data/history through Safari settings, restarting my phone, appending a variable to the apple-touch-icon URL, using both absolute and relative paths, and tinkering with different image size specifications, none of which worked.
I saw a suggestion somewhere that resetting the phone may work, but my question in that scenario is what exactly to reset and whether this would compromise other data.
Are there any workarounds/fixes I’m not aware of?
I’m using an iPhone 7 with iOS 12.2. The code being used is straight from what realfavicongenerator provides.
RealFaviconGenerator's author speaking.
As you noticed, iOS Safari is quite lazy regarding favicon reloading. It is not the only one.
The trick is to force it to reload the icon by providing a URL it never encountered before. A simple way of doing this is to suffix the existing icon URL with a dummy parameter. For example, change /the_icon.png to /the_icon.png?v=2.
To do so with RealFaviconGenerator, generate your icons again. This time, make sure to open the Version/Refresh tab in the Favicon Generator Options panel, and select the second option, as below:
Note: You might want to edit manually the code already created by RealFaviconGenerator and append the version yourself. This might be a bad idea. For example, if you put your icons in your root folder, some HTML lines were not generated (because of conventions RFG is taking advantage of). But suddenly, these lines must be added to specify a version. This is definitely not something you can guess at first sight.
New favicon showed up today, with no intervention on my part (versioning had also been removed). Not sure why. Guess it may be due to a time interval.
I am trying to make an offline application with a bundled map. The map is running in SKConnectivityMode.Offline, so I have put the map data in: SKMaps.Bundle/PreinstalledMaps/v1/20150413/package
I have also copied the metadata into:
SKMaps.Bundle/PreinstalledMaps/v1/20150413/meta
The problem is that the data in the meta-folder is not picked up, and the map does not render. I tried to copy the meta-folder into the Library/Caches-location of a Simulator app, and then the map renders as expected.
A workaround I had in mind was to copy the meta-folder into the Library/Caches-area when the application is started the first time - but it will lead to double storage of files, and seems a bit dirty.
Any ideas what I might be doing wrong?
The version of the Skobbler API is 2.5.
I found a solution to the problem, with help from the API developers. The SKMaps.bundle was for some reason not being replaced in the application package by the build script, and I needed to run a Product->Clean from XCode.
I'm trying to setup a iPad app to work offline. I was able to successfully get it to work but I was told to put the app in multiple sub directories. When I did this and update the cache manifest file to the new destinations of all the files I kept getting an error that the site wouldn't work because it wasn't connected to the internet. I tried multiple paths and looked up different ideas but have come up empty handed. Is their a way to get offline mode working with a site inside sub directories?
Thanks.
This shouldn't make a difference. Make sure all urls in the manifest are relative and always end the manifest with:
NETWORK:
*
Furthermore make sure you don't forget to add any images, libraries etc. from the cached url's to the manifest. Sometimes even caps can make a difference. OPen the console of the developer tools in Chrome to see what's being cached and what breaks loading the appcache.
Also make sure there are no iframes (ie. like-buttons) on the homepage(page that includes the manifest attribute in the html-tag) which is always cached.
Little trick:
If you want to fallback you're homepage place the manifest attribute in an invisible iframe on the homepage of your app.
That way you have total control over what's cached and what not.
I am maintaining an existing BlackBerry application (implemented as a MIDlet). The application contains a number of data files that get bundled with the app as resources. Some of these data files need to be updated for a new version of the app. When the user goes to install a new version of the application (via URL of Jad file), it prompts them with the following message
"Persistent data exists for the application. Would you like to retain this data? "
If the user selects "Yes", it looks like the app continues to use the old resource files.
This is so surprising to me. First of all, am I losing my mind or will an upgrade really not overwrite existing resource files? Is there any way I can force it to?
Thanks,
Jeff
I think that message is only relevant to existing RMS records. Are you positive that your app is still using old resources? That sounds unbelievably strange (even for RIM). Anyway, this should be easy to verify if you change some image resource you're using in one of your screens or something.