New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(mobile): iOS background sync #1758
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
…d its failing at the root asset bundle in the localization.dart service
This finally at least works! I was able to sync a photo using the background fetch manual initialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reverted most of my comments from before. It seems like something I did worked, at least, because in the past my background code was able to acquire the lock while the app was in the foreground (which was wrong), and the foreground app was sometimes unable to acquire the lock from the background execution (which I haven't tested yet).
Now, when I run I simulate the background task while the app is in the foreground, I correctly see:
flutter: [_callHandler] could not acquire lock, exiting
performBackgroundRequest.UIBackgroundFetchResult(rawValue: 2) (finished in 5.209082007408142 seconds)
mobile/lib/modules/backup/background_service/background.service.dart
Outdated
Show resolved
Hide resolved
mobile/lib/modules/backup/background_service/background.service.dart
Outdated
Show resolved
Hide resolved
@@ -244,7 +228,7 @@ class BackgroundService { | |||
return true; | |||
} | |||
|
|||
Future<void> _checkLockReleasedWithHeartbeat(final int lockTime) async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reverted it.
mobile/lib/modules/backup/background_service/background.service.dart
Outdated
Show resolved
Hide resolved
@@ -389,8 +378,8 @@ class BackgroundService { | |||
return false; | |||
} | |||
// check for new assets added while performing backup | |||
} while (true == | |||
await _backgroundChannel.invokeMethod<bool>("hasContentChanged")); | |||
} while (false); //TODO: broken on iOS (true == |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs some better treatment for iOS, as we do not check for new assets added while performing backup in iOS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me now!
…network or charge
… for task to cancel itself
@@ -527,15 +543,15 @@ | |||
CODE_SIGN_IDENTITY = "Apple Development"; | |||
CODE_SIGN_STYLE = Automatic; | |||
CURRENT_PROJECT_VERSION = 86; | |||
MARKETING_VERSION = "$(FLUTTER_BUILD_NAME)"; | |||
DEVELOPMENT_TEAM = 2F67MQ8R79; | |||
DEVELOPMENT_TEAM = 6WU78265ZG; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alextran1502 I had to change this to compile it here. You should change it back by checking it out yourself and going to Runner -> Targets -> Signing & Capabilities -> Signing, then changing it back correctly. I'm hesitant of mangling the project.pbxproj
files by editing it myself. I think all that needs done is to change back the DEVELOPMENT_TEAM.
Alternatively, maybe you should add my Apple Developer Account to your Development Team, so I can compile it without changing this again.
@@ -12,6 +12,7 @@ dependencies: | |||
flutter: | |||
sdk: flutter | |||
|
|||
path_provider_ios: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I commit the pubspec.lock and Podfile.lock too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think that is fine.
All that's left to do here is some testing & validation. My last checkbox in the description is to check:
I guess try to open the app while it's in the middle of a sync job? Hard to do since the OS schedules the sync job. On the other hand, you can manually schedule one yourself. The logic hasn't changed between this and iOS, so it's likely OK. And when I run the background job while the foreground app is running, the background job correctly is unable to acquire a lock, so I'm confident it will work. Finally, some testing should be done to assure that Android's background sync has not regressed, but @zoodyy was kind enough to help there. And I made #1790 to go along with this, but I could bring it in here, too, if that's easier. I'd prefer to keep them separate and rebase, but I don't have any real reason for the preference. I just think it needs some more testing and I'm happy with the feature. Anything else you'd like to see here? |
…s and fixed network connectivity always required
…t-background-task
…/ disable background service on platform channel
Enables background sync on iOS.