I'm currently working on enhancing a web app with some cooler features. I started small and added a manifest file and a service worker to handle Add to Homescreen and show a offline page when no internet connection.
One thing I notice is that you can end up with a lot of homescreen icons of the same app (it's possible I might be doing something wrong).
Is there a way to avoid this? In an ideal world sequential add to homescreen would replace the previous shortcut.
Test on Nexus 5x + Chrome 58
Thanks
Related
A client wants a web app for an event and he wants to avoid handling store problems such as validation etc... to go faster.
I already developped some app for android & iOS platform and not really for flutter web.
The client wants to access the app offline, not everything of course but at least some static information and one or two request saved in cache.
I looked for those thing in PWA and it usually use service worker (a pain in the ass to use), so i tried but there si so many element to keep in cache with flutter that it is hard to keep all and impossible to show the page because some element are missing.
So i have 2 questions :
Did someone made a custom service worker and can show his web app offline ?
is there a way to do this differently ? detect if the connection is offline and show the page saved elsewhere (i know about hive etc for example but i don't know if it can work with this kind of cache)
Thanks you !!!
I'm adding to my App offline capabilities. Once the user clicks download button, the App is downloading some content to device (makes https calls and saves the result). The problem is that the download process is long (few minutes) and since the user is not interacting with the app, the app moves to the background and the download process fails. Coming from cordova world there is a simple plugin that allows running the app in the background. For Flutter, all the I found is the following medium article which looks pretty complicated solution to what I'm trying to achieve:
https://medium.com/flutter/executing-dart-in-the-background-with-flutter-plugins-and-geofencing-2b3e40a1a124.
Is there any method more simple to achieve what I need?
Experimenting with Mobile Chrome apps API: ( https://github.com/MobileChromeApps/mobile-chrome-apps )
What I'm trying to achieve is the registering of my chrome alarms without having to crudely start the apps' main activity as this causes a bad user experience.
The challenge:
I have specified a chome.alarm which gets successfully registered when I open the app ('cca run android ' for example). These alarms are specified in a background.js file, which is declared as a background script in the manifest.json file.
I wanted these to be registered automatically on boot, therefore I implemented a background service and thought I could simply call the app to register the alarms specified in the background.js file. However, the only way I can find thus far to achieve this, is via a call to launch the apps main activity via an Intent from within the background service as explained in more detail below.
On boot, my background service simply invokes:
//Launch main activity..
Intent LaunchIntent = getPackageManager().getLaunchIntentForPackage("com.company.appname");
startActivity(LaunchIntent);
The above launches the app into its main activity and the aforementioned chrome.alarms are registered as desired. Happy days! A massive downside to this, of course, is that no user wants the full blown main activity window to open on boot.
Please advise if there is a less clunky way to have the chrome.alarm specified in background.js registered at boot by a background thread. I do not wish to open the mainActivity of the app, yet this is currently the only way thus far I can see to get them to be registered. It is preferable not to register these alarms from within the Android SDK as I intend to stay as close to using web APIs and want to use background.js as the hook to do this keeping things in-line with chrome web apps as-well-as the android platform.
What I have done:
A cca (chrome mobile web app) app which registers a background service natively (I extend BackgroundService) as a plugin and register this to run at boot time. This is the only 'native android code' in order to load the app at boot-time.
Upon booting android, this background service then simply issues a startActivity(LaunchIntent) in order to open the app. In doing so, my chrome.alarm specified in my background.js file get registered successfully. If I don't do this, my chrome alarm specified in background.js do not get registered until I manually open the apps main activity. Therefore I use the backgroundService to open the apps main activity.
This is not at all ideal, I would simply like to somehow have my chrome.alarms registered without crudely having to launch the apps main activity window.
Is there a call which I can place in my BackgroundService to have only the chrome.alarms contained in my background.js file read and registered to fire?
Thank you for your time.
First, thanks for using Chrome Apps for Mobile! (Note: I work on the project)
Sorry that our current bootstrap is "crude" and "clunky", and we agree that it is. You can track this issue for progress on our effort to replace our current Background-scripts-embedded-in-main-Activity-webview strategy with a real background service and multiple window support. Basically you've summarized exactly our plan and existing limitations.
This work is actually scheduled for the near term, and will certainly be done before the end of the year.
As well as chrome.alarms, this feature is quite important for chrome.gcm and chrome.tcpServer (among other reasons).
I created a web app and added to my iPhone Home Screen. When I switch to another app and back, iPhone automatically reload my web app. This breaks my app flow.
How do I prevent iPhone from reloading the app?
I have apple-mobile-web-app-capable meta tag enabled to hide Safari toolbar and I don't want to turn it off.
I just found this related question on SO: Stop native web app from reloading itself upon opening on iOS
As it seems it's a limitation of Safari, a proposed solution is to persist your web apps state using Javascript and HTML5 localStorage. When your web app is launched, check for the persisted state and load it if available.
You can read about using localStorage in Safari here: http://developer.apple.com/library/safari/#documentation/iPhone/Conceptual/SafariJSDatabaseGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007256-CH1-SW1
Hope that helps you. At least it did for me, as I had the same problem as you. :-)
The short answer is that you can't control this. Sometimes iOS will keep a web app active in the background, at other times it will kill it. It's entirely related to how much memory is available on the device.
So, your best approach is to minimise the problems presented by this reload. Make sure your webapp updates the URL when you move from view to view, either by changing location.hash or using history.pushState(). This will allow you to reload whatever view the user was on before they switched apps. There are pagehide and pageshow events that allow you to execute code when the user moves away from your app - take that opportunity to store local state in localStorage and/or IndexedDB, then fetch that data again when the webapp is reopened.
I found a hack, tested on iOS 11.4.1/12.0
Open file uploading window and then switch back to the home screen.
The app still continues to work, in my case audio is playing and localStorage is updating
Proofs:
https://youtu.be/heehLUhGKYY
PS. note how song progress changes when we seek, it proves that app works in the background
Update: as this answer is receiving downvotes, I added this explanation.
Your problem might not be the actual reload, but the fact that Mobile Safari treats your user's cache and cookies differently when your web app is opened through the browser, than when it's 'installed' as a web app to the home screen. Although the solutions proposed here that use localStorage will work, they're a lot of work for client-side logic that can be avoided if your server is already responsible for persisting the session state of your user. The 30-second solution is to simply explicitly set the session cookie to have a longer lifetime.
This allows you to keep the state intact even between device reboots, so even though it doesn't technically stop the web app from being reloaded when launched from the home screen, it is an easy way to restore the state for the user without him/her noticing the reload - which in many cases I suspect is the real problem.
For a more elaborate discussion of this strategy and code examples, take a look at these questions and my answers there:
Maintain PHP Session in web app on iPhone
iPhone "Bookmark to Homescreen" removes cookies and session?
I've just written my first app in intraweb (control pack for the iphone)
It works, but after several hours I still cannot get the iphone to not show safari.
I've added a link to my homescreen and I start the (web)app from there and things start out ok.
But when I change a page safari shows up and breaks the look I'm an iphone app® magic and eats up 25% of my screen.
The intraweb documentation says this is due to the fact that the webadres changes (parameters in the url), so I switched to hidden fields, but to no avail.
How do I make sure my iphone webapp stays full screen and never goes to safari?
It works for me, and I suggest you ask in the TMS Software newsgroups, with steps to reproduce this behaviour, so they can look into it (which will give you a better chance of solving the issue that asking here, to be honest)...