I am developing a PWA with Vue 3 CLI that grabs some of it's content from a seperate CMS/API. The application is a touchscreen game and a primary use case is running without an internet connection, although the user environment is controlled and the game can be updated with latest updates sync'd and cached via ServiceWorkers when required.
When I build my app, Webpack performance recommendations warn of assets larger than the recommended size limit; in this case an intro video (25MB) and some font files (300kB each).
Should I be serving the video and fonts (and other large files) from the CMS/API and keeping my Vue app build as small as possible, bearing in mind the offline functionality being important? Or is there a good reason to package the fonts and video in the Vue JS build output?
This is my first PWA, so am just looking for confirmation whether to follow the Webpack guidelines in this case, given the app functioning properly offline is a priority?
There is a limit you can store depending on your browser How Much Can You Store
Me personally i would not recommend to store such large video files. If it is not absolute needed for your users offline experience.
If the video is not mandatory to play the game, I would not cache it by default, but give the user the opportunity to do it if she wants.
Some players might have low quota data plans and want to not show the video.
The fonts look like a good asset to put in cache.
Related
I've built multiple sites with Nuxt SSR, but never touched the static part.
As far as I know, upon build-time, Nuxt automatically executes all API calls and caches them.
If I want to make a blog with a static Nuxt site, how would I update the content? Is it only possible when I rebuild the app?
Seems unnecessary to rebuild everything every time I add a new blog post. With SSR I just reload the page.
Also wanted to note that I have a Strapi.js backend running on a VPS and I usually make changes weekly. Nuxt's docs state that I need to push my changes to the main repo branch but there's no changes on the frontend.
Does this also mean that the headless cms should be local only?
The whole point of having a static build is to have all the generated files with no additional server Node.js server needed. It reduces heavily the costs, removes a point of failure, discard any notion of server charge (amount of users at the same time on your app) and probably some other advantages yeah.
Downside, you indeed need to actually yarn generate the whole app again if it's something that was added/changed in the codebase. Usually it's pretty fast and there are also incremental builds if I do remember properly (you will not regenerate all the 99 old blog posts but only the 100th, the new one).
Headless CMS like Strapi usually work with a webhook: you add a new CMS article or alike, Strapi will notify your JAMstack platform to rebuild your app. Even if no front-end code was changed, you can force to build it with the new data coming from the headless CMS' API.
My question is essentially how can I get around the storage quota limits enforced on a PWA? A little background...
I am hoping to create an offline-ready line-of-business progressive web app that would ideally push about 2GB of images and video resources onto my user's phones or tablets - well beyond the current storage quota for caches and Indexed DB. What I'd like to be able to do is have my users (we all work at the same company) do a 1 time download of a zip file or directory and have the user's store that on their phone/tablet's file system in a well known directory. As the online version of the app treats these files as URL's, the fetch api would seem ideal since I could serve from online if connected or the local serviceworker managed cache if not online. But the qouta limits have me stumped. None of the files are larger than 15MB, but there's no way to know which files are needed before a user goes offline. Can I use something like an HTML input type=file tag to load files into the cache at runtime and then treat them as URL's? Of course I would remove other files to make room. But since these files wouldn't be coming from "the origin" with its secure https address (a PWA requirement I think) , but rather a local file system, I'm not sure this will work. If it is workable, would my users be forced to browse to the files manually?
If its an option, you can have a native Android service to do the caching part to avoid space constraint and then serve the data from native code to PWA using websockets/secure web sockets.
No PWA solution possible for now. File API has limitation as its sand-boxed.
I have gotten to the point where I can launch the barcode mock mode.
I am trying to figure out how I can start scanning test codes in development.
Or would an app that I am trying to test this on, need to have camera permissions on the app?
In that case, how do you overcome the use of the Camera Hardware on the PWA?
Or is there a way that I can scan QR-Codes using a different javascript API that would work in all cases?
Also, I had to move the camera and barcode service Javascript files into my Widget folder because when I was trying to reference them as you do on the instructions, the files wouldn't load.
Yes when you are in web it will mock the functionality because you're not on a device. There are HTML5 Camera API's see (https://www.html5rocks.com/en/tutorials/getusermedia/intro/)
You can use the BuildFire Previewer App (contact customer support if you havent downloaded it yet)
While you can take a copy of the services into your plugin it is risky. If we issue any updates or bug fixes you will not receive them. Also if it breaks compatibility at any time (rare but possible) your plugin stop working
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
I have read some posts on S/O and also around the web. We are producing a HTML5 JS based web app that runs on the web. We are packaging it up for Google apps, and also for phonegap.
Can we package this app for windows 8? Of course, I appreciate it won't use the windows 8 features. But, will the app run none the less, as it stands. So that we can place it in the store and build out windows 8 features as we move forward.
I appreciate this is a slightly non-concise question, but I guess the real point is what is our quickest route to take our existing HTML 5, CSS, JS App and deploy it in the store and get it working on this platform.
In general, the answer is yes. The transition is not seamless, but you will be able to use a ton, if not all, of the application artifacts in Win8. A good test is if you can run it in IE10, you can run the app as a Win8 app. Again, this is a very broad brush - things you need to worry about are things like all scripts files need to be local (no CDN), changes to web and security contexts, and the fact that Win8 is a horizontal paradigm whereas most web apps are vertical. But in general, you should be able to make the move. Usual caveat - your mileage will vary.
Yes, although not recommended, you can package your existing app for Win8. You'll need to add a few bits of code though. The minimum would be to embed your app's start/init code within WinJS's first promise callback, like so:
args.setPromise(WinJS.UI.processAll().then(function () {
// your init code
}
You'll also need to create a couple of icons for the start screen and an image for your app's launch screen.
It is possible that you'll run into a few issues, like some security related restrictions, where you'll have to modify your code to use some native WinJS functions. This all depends on you app's implementation.
You can also check Microsoft's guidelines for migrating a web app to win8, here: http://msdn.microsoft.com/en-us/library/windows/apps/hh465143