I'm creating a simple web app that can connect to a bluetooth device that I want to be able to use offline, so I use a service worker to store the app in the web cache. I know the cache only clears if there is no more space but what about the service worker?
I found that is lifespan is 24 hours. My question is how long can I use the web app without connecting to the internet? Is the cache the only problem or does the service worker "die" after x amount of time and I need to connect to the internet again?
No, it does not die. You can use it forever.
You're confusing two things. The 24 hour lifespan is actually an automatic update checking interval. In other words, when using a site frequently the browser will automatically check for updated Service Workers (specifically updated /serviceworker.js or wherever you store it). Your code can of course manually, programmatically check for SW updates more often. Usually apps check for new SWs every time they're launched. But the device may be offline for eg a month and that doesn't prevent the use of the app.
Related
I am iOS developer and currently working on a Project which needs to hit an API after every 1 min in background and I am unable to do that. Is there any solution for it ? Please help.
Short: Not possible
Long:
The most precious resource on a mobile device is the battery power. It has to be sparsely used.
Therefore no application in its sandbox is allowed to run infinite or get waked every minute.
Whatever the usecase for contacting the server is, the process has to be redesigned to fit into a mobile scenario. The options are push, opportunistic background fetch or using background sessions for talking to the server. However none of this options will guarantee a wake up every minute.
My main question is how to detect the application termination by the end user when it was in the background (Suspended) to be able to send logout request to the server ?
We already have a timeout interval in the server to kill the session, but assume that the interval is 5 minutes so this means that the session will be alive for 5 minutes after the user terminated the app and anyone can sniff on the data and reuse it.
Notes:
We use HTTPS connection and SSL Certificate Pining.
We also implemented a heartbeat web service to be called by client app every fixed interval to tell the server to keep the session alive for this interval, if this web service didn't call for specific session, the server will kill this session.
Once your app is suspended you don't get any further notice before you are terminated. There is no way to do what you want.
Plus, the user could suspend your app to do something else (like play a game) and then not go back to your app for DAYS.
If you want to log out when the user leaves your app, do it on the willBeSuspended message. Ask for more background time and send a logout right then and there.
Mohamed Amer,
Here is an approach used by Quickblox Server and I feel its pretty much solid though it involves a little overhead.
Once the client application (either iOS android) establishes the session with quickblox server, quickblox server expects the client application to send the presence information to server after a regular interval continuously.
Sending the presense information is pretty much simple. They have written a api which we keep hitting after a interval of 5 mins with session id that we have. They validate the session id and once found valid they will extend the expiration time for the user ascociated with that id for 5 mins more.
What they will do I believe is that,
Approach 1 : they maintain the last hit time and for all the subsequesnt request they check if the request time is within the the time frame of 5 min if yes simply process it. If the request comes after 5 min they will delete the session id for the user and respond saying you have timeout the session.
Approach 2 : Because they provide online and offline info as well they cant simply depend on the incoming request to delete the session id from server so they probably create a background thread which swipes over the db to find the entry with last hit time greater then 5 min and removes it from DB. and declares the user session expired.
Though this involves client apps continously hitting the server and increases the burden on the server for the app like chat application in which presense information is so vital this overhead is still fine i believe.
Hope I have provided you with some idea at least :)
I need to keep the app to send a simple GET request ("ping") to the server every minute just for it to know that user is still online. I have no problem with it while the app is active and 10 minutes after it went background using "beginBackgroundTaskWithExpirationHandler".
But how can I keep request repeated all the time unless user terminates app manually?
That's not really how it works -- it's not a Windows or a Mac app that runs continually in the background.
What you probably want to do is use the background fetch process, whereby iOS will periodically run a particular method allowing you to do network operations while your app is in the background (or not running at all).
What this won't allow you to do is ping your server exactly once every minute. But actually that's a good thing. Consuming a users battery and data allowance like that is not very user-friendly.
I have an app that tracks wildlife where the user enters data based on their observations (eg. user enters they see 3 moose). The data is then uploaded to a server. However, because this app will be used out in the field where there is often no internet connection, I want to save data if there is no connection, and upload the data as soon as the network is available
I know about Reachability, but it looks like I can only check if the internet connection is available at that moment, and doesn't check in the background for internet connectivity
So to summarize:
If there is an internet connection when users submits data, then that's fine.
If there is no internet connection, when user submits data, I want to save this data. As soon as there is an internet connection, I want the data to be uploaded, without needing the user to open up the app again. I can't rely on the user to open the app again causing the data to be submitted, because they will likely only use this app out of the range of cell towers, and will likely NEVER run the app in a location with a network connection, so it would have to automatically submit this data for them.
Looking around, I can't find an answer so I'm beginning to wonder...is this even possible?
No, Apple don't allow applications to run indefinitely in the background for this purpose, and they don't allow applications to be triggered remotely or anything of that nature. At best you could have your application run in the background to get notifications about major location changes, but you'd have to have it as a proper feature rather than a hack to get around this limitation, otherwise your application won't get approved by Apple.
I know it's possible to utilize the network in the background but only for a limited time after the user closes the app. You could create a timer which checks for a network connection (using Reachability or by pinging Google) and set the timer to fire every minute after the app closes. It's not a very efficient solution but it may work. You should look into how long you can maintain a connection after the app close though, I think it is 5-10 minutes.
Is it possible to interface with a webservice (or, for what matter, do any scheduled local or remote activity) while the app is in background?
I know that you can receive remote pushes or schedule local alerts, but I wonder if I can periodically send my GPS position to a webservice even if the app is not in foreground.
I have been thinking about this myself in an attempt to impress my boss with an iPhone/iPad App that accesses our Web Service.
If the Web Service takes a non-trivial amount of time to process a request then there is absolutely no guarantee that the App won't be interrupted and stopped, therefore making it useless for any business-level tool. The only Apps that are allowed to run for extended periods in the background are a select set that use certain frameworks (music players, etc.).
I concluded that the only way of doing it is to introduce a middle tier that performs and waits for the response from the actual Web Service and provides an interface that the iOS App can poll or be pushed to in order to allow it to sleep/die whenever iOS thinks it should.
You can make sporadic network calls while you are running in the background if you are a location-based app with proper permissions. You need to make sure you are running a background task properly. FYI, there are a number of applications in the app store that do this.