Can anyone confirm whether data syncs while the app is open but in the background or when the the device screen is locked? My experience thus far is that it does not. Is this correct?
@Michael,
If you set Automatic background updates to ON, then the app data is updated in 30min intervals
@LeventK I think you are referring to background syncing from other users, are you not? (โAutomatically retrieves changes made by other usersโ)
I would really like to know what the answer to Michaelโs question is on iOS. On my device, if I start a sync and the navigate to another app before the sync has completed, I get an error. This is a very important issue for my users so I would really appreciate more information on how this works on different devices.
I data saver on?
Thanks for your reply. Actually, Iโm testing on an iPod Touch, so I donโt have the options for cellular data that an iPhone has. So, the device only uses WiFi. I wonder if you have not experienced any sync problems on iOS devices when you navigate away from AppSheet. If so, perhaps this is a device specific issue.
I also think it does NOT sync in the background. In any case I think that some ui widget should show on the app how much time passed since the last update. The user has no idea if it is synced so he must sync before use which might be redundant.
I can confirm: background syncing is not happening at least with iOS devices even with automatic syncing enabled. The app must be in the foreground for syncing to occur. If the app is in the background or the device is locked, syncing does not take place.
It does NOT sync also on Android when in the background
It would be nice to have a response to this thread from someone at AppSheet. I think this thread identifies a major problem with AppSheet. I have students using an AppSheet app I made and they tend to be quite impatient. Most of the time when they are actually using the app, the syncing goes on in the background so itโs not a major problem. However, when the app is started and when they move to a new task in my app, they need to wait for the sync. If I could tell them โYah, it takes a little while to sync sometimes but, you can just do something else on your phone while youโre waitingโ I think they would accept that. But they donโt like just having to sit and wait. On a computer, this is no problem โ we can do something else while we are waiting for AppSheet to catch up. Phones, however, seem to be a different matter. If thereโs a technical issue that prevents this, I like to know what it is. Thanks!
I was able to get a background sync to work nicely on my Android device by not on my iOS device. Perhaps this is a device specific problem. If thereโs any way to make an iOS device do this properly, Iโd like to know about it. I have โBackground App Refreshโ turned on for AppSheet but that doesnโt seem to be enough.
I am facing same issue on iPhone xr
Lately I observe the same, I posted several problems in this regard in G +, because I also observed data loss and Aleksi Alkio is dealing with the issue. Before the synchronization worked perfectly, now it is locked and there are tens of minutes even in the foreground and updating manually.
@Steve @Kirk_Masden
I donโt believe the connection type makes a difference. WiFi or cellar, if a change is made and a sync begins, if the user navigates away from the app, a network connectivity error is thrown and the sync appears in the app to not have completed although the changes are made in the backend. The user at this point must click Cancel and then re-sync.
I see. Thanks. This is what I wanted to know. Itโs a bit disappointing, though. I wish AppSheet could get rid of the connectivity error. Any error message is always disconcerting for users. Also the need to click Cancel and then wait for the re-sync is also problematic.
Youโd rather errors not be reported?
No. Sorry for the confusion. Iโd rather that errors not occur. I thought perhaps that it was a false alarm sort of error but now I see thatโs not the case.
I do not think itโs a false mistake, I attributed it to my wifi, I hired a 50mb connection and everything is the same. The synchronization is hung, while the rest of the phone app works without problems. I cancel and resynchronize until at the end it does.
I have seen these problems since the end of last year. Before, it did not happen.
Thanks for the feedback, @Alfredo_Pou! I hope AppSheet can fix this. In my view, itโs a major problem. My Android phone works well enough (syncing in the background) but there are a lot of iOS users out there so this is important.
I am an Android user and I have the same problems. In my opinion it is a problem of server capacity, because it is not always the case, there are times when everything synchronizes correctly and there are times that it can take 10 minutes to update.
I started noticing problems when I switched to the 5 button view, which coincided with the announcement that the 1 dollar plan was discontinued. In the 5-button view, the end of synchronization is no longer displayed (there used to be an animation spinning). I think that in any of those modifications there is a bug.
Thanks! I hope AppSheet can use some of the funding they have received to work on this problem:
Hi everyone - great topic. Was this ever addressed?
I could have sworn that my updates were processing even when the app was closed/hidden a few weeks ago. This week I notice that the app has to be in the forefront in order for updates to go through.
Hi @Jon_Melo! Not that I know of. Actually, I think I might try building up a line of data that needs to be synced on my app (on an iPhone), then making the phone sleep overnight and then seeing what things look like in the morning.
I have found that if I leave the app, before a sync takes place, that it does NOT sync when the app is in the background. Even if itโs been over 30 minutes.
This is on an iPhone. I think that has been the same for me the past 6-8 months of using AppSheet.
AppSheet on phone has Background Refresh ON.
Currently my app has the following settings. I donโt understand how having both of these setting ON work.
In real life, syncs are done in a timely manner without the user pressing sync WHEN they are still IN the app, even with the following settings.
Further update:
35 minutes after I added the record and immediately switched to another app, I went back into the App.
It still showed the edits pending. In just seconds, they were synced.
How can we get our data to sync in the background? Iโm sure this will happen a lot and could end up with data lost.
Update: Here is a link that describes how Delayed Sync and Automatic Updates interact.
Same here - the two settings seem to contradict each other but it seems like the Automatic updates option โwinsโ as users donโt have to press the sync button if the App is open.
Question - where do you see the โBackground Refreshโ option? I canโt find this.
On iPhone:
Settings.
So, just to clarify - its not enough to have the โAutomatic Updatesโ enabled in Appsheet but the tablet settings should have enabled background app refresh.
This is something I have noticed with some of our apps also, but it has affected both tablet and desktop users.
I donโt know. These are the settings I have and updates are NOT being done in the background on Apple phone and tablet, in my case.
I think AppSheet might install on iDevices with background refresh set to Enabled. I donโt remember ever going in to change it.
Iโve asked internally for an authoritative answer. Until then, to share my experience as an Android user: no syncing seems to occur when the app is not displayed on the screen. So if the app is in the background or my phone is asleep, I would not expect syncs to occur, but they seem to occur immediately when the app comes to the foreground.
Thanks for sharing your experience and for trying to get an authoritative answer.
Thanks from me too. My experience is the same (no background syncs when the app isnโt being used). If AppSheet eventually starts doing syncs when the phone is not being used or when the user is using other apps, that will be a major step forward, particularly for my app when tends to build up lots of data that needs to be synced.
Has this feature request been submitted? If so, please show me where so that I can upvote it. If not, Iโm happy to create it.
To my knowledge it was a design decision. Personally itโs a love/hate of mine. I usually explain it to my users a benefit. I make sure to say at some point in the relationship to every user, โThese applications are designed with you and your device in mind. We need our mobile devices for a lot; these days itโs our lifeblood. To conserve battery and ensure your privacy we donโt collect any information in the background. All changes and information collected require the user to physically interact with the application. Make sure all of your information has been synced before you close the application.โ
This educates the users on how to better deal with it, while making our limitation feel like their benefit. See, @praveen I listen every once in awhile!
Also, this conversation typically happens early with management and early adopters and so they hear about this before they experience it. I have quite a few of these types of points that I cover at some point. In any relationship, itโs best to openly talk about limitations early and often.
Grant,
Thatโs a great way to explain it to users.
Also, what other points do you share? โI have quite a few of these types of points that I cover at some point. In any relationship, itโs best to openly talk about limitations early and often.โ
Any that you can share with us?
Iโm just going to use speech to text for this, so bear with me. In general, if you want you can go ahead and start naming some limitations of app sheet and I can probably tell you how Iโve explained that to people.
one of the first ones I find when Iโm working with clients that have input on the app design, is the general layout form and function of app sheet. In general I first when Iโm talking about app sheet Iโll straight explain that one of the powerful elements of app sheet is that it has built-in views we donโt have to build these views from scratch. And that actually helps the user experience because then all of your apps across the entire enterprise will generally have the same function form and feel if you try not to mess with it much. So this really goes miles in cutting down on client request to I want a gallery that makes a button take me somewhere and then I need someone to be able to this that and the other when you start to get the client in the mindset of that limitation being actually a good thing they start to respect it making your job easier. They also start to ask more questions instead of saying commands like I want this feature in that feature they will start to communicate more about like what do you think about this is this something apps sheet can do.
Another good one is the here and the now function, if youโve been on the form much you know that there are apps that let you cheat and force your device time and device location, and so I always bring that up pretty early as well especially bringing on users and talking to them if theyโre working on location sensitive apps and just bringing it up generally lets people know that one will be it where weโre used to finding this weโre used to dealing with this we know it exists and weโll figure it out and weโll hunt you down and weโll make sure you donโt use our business applications again. Even if we donโt actually have that capability, it actually is something we keep on the radar and we can sometimes find interesting things, usually itโs just people not having those services engaged. Iโve actually yet to find someone purposely forcing their location, and then from a design perspective it also shows our clients that we know that this happens so we donโt design critical systems around that so for like signing in on a project site we might have a rotating data matrix code that gets posted on a board printed and posted so that that has to be scanned when someone walks in you know thereโs all sorts of interesting things you can do to get around a lot of this will talk to him about oh yeah we record server time we donโt just take the device time and so we can see disparities and things like that so usually just openly talking about this with people lets them know that you can engage those issues and then they usually just donโt mess with it
Another one I usually try to explain is that sometimes when you click a button you will see multiple syncs queue up and so let them know that thatโs normal and that that can happen and that it means the device is taking some background action thatโs required to be front-facing, and that we talk about usually if we can weโll move that stuff off the device but often itโs required to be front-facing.
In the main thing is that talking about all these things with your client establishes you as the subject matter expert, and they will start to solution with you instead of directing you which is key even if youโre working with internal user groups
But seriously, if you can come up with a limitation of app sheet, you should also be able to play devilโs advocate and come up with why itโs a benefit.
Grant,
Thank you so much for taking the time to respond so thoroughly. I look forward to reading through these and being better prepared to train my users. My first training session is tomorrow so perfect timing.
Thatโs awesome! Iโve never had to really do training.
If you think about anything specific, just shoot it out.
Thanks @Grant_Stead! I didnโt realize that this was a design decision. I can understand not wanting the app to sync in the background when the device is sleeping. A lot of people find that kind of activity to be creepy and, as you indicate, thereโs the battery issue. But what about continuing to sync while the user is looking at another app? Iโd really like to be able to hit sync, go to another app to do something, and come back to find a completed sync. That, however, is something that I havenโt been able to get to work on my iOS devices.
User | Count |
---|---|
36 | |
31 | |
30 | |
20 | |
17 |