1
0
mirror of https://github.com/immich-app/immich.git synced 2024-12-23 02:06:15 +02:00
immich/mobile/lib/modules/backup/models/backup_state.model.dart

196 lines
8.5 KiB
Dart
Raw Normal View History

// ignore_for_file: public_member_api_docs, sort_constructors_first
import 'package:cancellation_token_http/http.dart';
import 'package:collection/collection.dart';
import 'package:photo_manager/photo_manager.dart';
import 'package:immich_mobile/modules/backup/models/available_album.model.dart';
import 'package:immich_mobile/modules/backup/models/current_upload_asset.model.dart';
import 'package:immich_mobile/shared/models/server_info/server_disk_info.model.dart';
enum BackUpProgressEnum {
idle,
inProgress,
manualInProgress,
inBackground,
done
}
class BackUpState {
// enum
final BackUpProgressEnum backupProgress;
final List<String> allAssetsInDatabase;
final double progressInPercentage;
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
final String progressInFileSize;
final double progressInFileSpeed;
final List<double> progressInFileSpeeds;
final DateTime progressInFileSpeedUpdateTime;
final int progressInFileSpeedUpdateSentBytes;
final double iCloudDownloadProgress;
final CancellationToken cancelToken;
final ServerDiskInfo serverInfo;
final bool autoBackup;
final bool backgroundBackup;
final bool backupRequireWifi;
final bool backupRequireCharging;
final int backupTriggerDelay;
/// All available albums on the device
final List<AvailableAlbum> availableAlbums;
final Set<AvailableAlbum> selectedBackupAlbums;
final Set<AvailableAlbum> excludedBackupAlbums;
/// Assets that are not overlapping in selected backup albums and excluded backup albums
final Set<AssetEntity> allUniqueAssets;
/// All assets from the selected albums that have been backup
final Set<String> selectedAlbumsBackupAssetsIds;
// Current Backup Asset
final CurrentUploadAsset currentUploadAsset;
const BackUpState({
required this.backupProgress,
required this.allAssetsInDatabase,
required this.progressInPercentage,
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
required this.progressInFileSize,
required this.progressInFileSpeed,
required this.progressInFileSpeeds,
required this.progressInFileSpeedUpdateTime,
required this.progressInFileSpeedUpdateSentBytes,
required this.iCloudDownloadProgress,
required this.cancelToken,
required this.serverInfo,
required this.autoBackup,
required this.backgroundBackup,
required this.backupRequireWifi,
required this.backupRequireCharging,
required this.backupTriggerDelay,
required this.availableAlbums,
required this.selectedBackupAlbums,
required this.excludedBackupAlbums,
required this.allUniqueAssets,
required this.selectedAlbumsBackupAssetsIds,
required this.currentUploadAsset,
});
BackUpState copyWith({
BackUpProgressEnum? backupProgress,
List<String>? allAssetsInDatabase,
double? progressInPercentage,
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
String? progressInFileSize,
double? progressInFileSpeed,
List<double>? progressInFileSpeeds,
DateTime? progressInFileSpeedUpdateTime,
int? progressInFileSpeedUpdateSentBytes,
double? iCloudDownloadProgress,
CancellationToken? cancelToken,
ServerDiskInfo? serverInfo,
bool? autoBackup,
bool? backgroundBackup,
bool? backupRequireWifi,
bool? backupRequireCharging,
int? backupTriggerDelay,
List<AvailableAlbum>? availableAlbums,
Set<AvailableAlbum>? selectedBackupAlbums,
Set<AvailableAlbum>? excludedBackupAlbums,
Set<AssetEntity>? allUniqueAssets,
Set<String>? selectedAlbumsBackupAssetsIds,
CurrentUploadAsset? currentUploadAsset,
}) {
return BackUpState(
backupProgress: backupProgress ?? this.backupProgress,
allAssetsInDatabase: allAssetsInDatabase ?? this.allAssetsInDatabase,
progressInPercentage: progressInPercentage ?? this.progressInPercentage,
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
progressInFileSize: progressInFileSize ?? this.progressInFileSize,
progressInFileSpeed: progressInFileSpeed ?? this.progressInFileSpeed,
progressInFileSpeeds: progressInFileSpeeds ?? this.progressInFileSpeeds,
progressInFileSpeedUpdateTime:
progressInFileSpeedUpdateTime ?? this.progressInFileSpeedUpdateTime,
progressInFileSpeedUpdateSentBytes: progressInFileSpeedUpdateSentBytes ??
this.progressInFileSpeedUpdateSentBytes,
iCloudDownloadProgress:
iCloudDownloadProgress ?? this.iCloudDownloadProgress,
cancelToken: cancelToken ?? this.cancelToken,
serverInfo: serverInfo ?? this.serverInfo,
autoBackup: autoBackup ?? this.autoBackup,
backgroundBackup: backgroundBackup ?? this.backgroundBackup,
backupRequireWifi: backupRequireWifi ?? this.backupRequireWifi,
backupRequireCharging:
backupRequireCharging ?? this.backupRequireCharging,
backupTriggerDelay: backupTriggerDelay ?? this.backupTriggerDelay,
availableAlbums: availableAlbums ?? this.availableAlbums,
selectedBackupAlbums: selectedBackupAlbums ?? this.selectedBackupAlbums,
excludedBackupAlbums: excludedBackupAlbums ?? this.excludedBackupAlbums,
allUniqueAssets: allUniqueAssets ?? this.allUniqueAssets,
selectedAlbumsBackupAssetsIds:
selectedAlbumsBackupAssetsIds ?? this.selectedAlbumsBackupAssetsIds,
currentUploadAsset: currentUploadAsset ?? this.currentUploadAsset,
);
}
@override
String toString() {
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
return 'BackUpState(backupProgress: $backupProgress, allAssetsInDatabase: $allAssetsInDatabase, progressInPercentage: $progressInPercentage, progressInFileSize: $progressInFileSize, progressInFileSpeed: $progressInFileSpeed, progressInFileSpeeds: $progressInFileSpeeds, progressInFileSpeedUpdateTime: $progressInFileSpeedUpdateTime, progressInFileSpeedUpdateSentBytes: $progressInFileSpeedUpdateSentBytes, iCloudDownloadProgress: $iCloudDownloadProgress, cancelToken: $cancelToken, serverInfo: $serverInfo, autoBackup: $autoBackup, backgroundBackup: $backgroundBackup, backupRequireWifi: $backupRequireWifi, backupRequireCharging: $backupRequireCharging, backupTriggerDelay: $backupTriggerDelay, availableAlbums: $availableAlbums, selectedBackupAlbums: $selectedBackupAlbums, excludedBackupAlbums: $excludedBackupAlbums, allUniqueAssets: $allUniqueAssets, selectedAlbumsBackupAssetsIds: $selectedAlbumsBackupAssetsIds, currentUploadAsset: $currentUploadAsset)';
}
@override
bool operator ==(covariant BackUpState other) {
if (identical(this, other)) return true;
final collectionEquals = const DeepCollectionEquality().equals;
return other.backupProgress == backupProgress &&
collectionEquals(other.allAssetsInDatabase, allAssetsInDatabase) &&
other.progressInPercentage == progressInPercentage &&
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
other.progressInFileSize == progressInFileSize &&
other.progressInFileSpeed == progressInFileSpeed &&
collectionEquals(other.progressInFileSpeeds, progressInFileSpeeds) &&
other.progressInFileSpeedUpdateTime == progressInFileSpeedUpdateTime &&
other.progressInFileSpeedUpdateSentBytes ==
progressInFileSpeedUpdateSentBytes &&
other.iCloudDownloadProgress == iCloudDownloadProgress &&
other.cancelToken == cancelToken &&
other.serverInfo == serverInfo &&
other.autoBackup == autoBackup &&
other.backgroundBackup == backgroundBackup &&
other.backupRequireWifi == backupRequireWifi &&
other.backupRequireCharging == backupRequireCharging &&
other.backupTriggerDelay == backupTriggerDelay &&
collectionEquals(other.availableAlbums, availableAlbums) &&
collectionEquals(other.selectedBackupAlbums, selectedBackupAlbums) &&
collectionEquals(other.excludedBackupAlbums, excludedBackupAlbums) &&
collectionEquals(other.allUniqueAssets, allUniqueAssets) &&
collectionEquals(
other.selectedAlbumsBackupAssetsIds,
selectedAlbumsBackupAssetsIds,
) &&
other.currentUploadAsset == currentUploadAsset;
}
@override
int get hashCode {
return backupProgress.hashCode ^
allAssetsInDatabase.hashCode ^
progressInPercentage.hashCode ^
feat(mobile): Adds file upload progress stats (#7760) * feat(mobile): Adds file upload progress stats: current upload file size uploaded, current file size and formatted bytes per second upload speed. Closes #7379 * chore(mobile): Fix stan issues * chore(mobile): Remove non-'en-US' translations, as I saw on another PR review (just looking around) that localisation is done via Localizely and this was the instruction (to only provide the en-US localisation). * fix(mobile): Provide boundary checks to ensure overflow issues are accounted for on erroneous upload speed calculation, sometimes the numbers received back from the upload handler can be a bit wild. * fix(mobile): Some heuristic bug fixing. Whilst thinking what could trigger overflow issues or 'zero' readouts, left over values from the previous file may do that. So adding the last upload sent bytes to the values to be reset may help! The time isn't necessary, as the period/cycle is inconsequential in this circumstance, well it should be anyway. * fix(mobile): Actually, in combination to the last commit, some more heuristic bug fixing. I was thinking it would be advantageous not to reset the update time, as it would trigger a quicker first upload speed calculation. However, I realised that could also cause the calculation to be incorrect on the first cycle as the period wouldn't align. Not really sure if it would be a big deal, but I'm taking wild guesses in the dark here. Again, some purely heuristic debugging as I can't re-produce the underlying issue. This is mainly just ensuring that the state is fully reset and is a known state at the beginning of each file as a common strategy to reduce issues. * refactor(mobile): Move the UI for the file progress to underneath the progress bar, it makes more sense there than in the file information table which contains only static information pertaining to the file itself. Switching to a monospace font to keep the UI from jumping around as the numbers change. * refactor(mobile): In order to have the UI always present an 'active' upload speed (as per the discussion on PR #7760), this stores the 'upload speeds' (capped at the latest 10) in a list and calculates the current upload speed as the average over them. This way the UI can always display a 'constant' upload speed during uploading, instead of starting a fresh when each file starts uploading. Limiting it to the 10 latest keeps the average somewhat recent and ensures some level of sensible memory allocation.
2024-03-14 22:15:22 +02:00
progressInFileSize.hashCode ^
progressInFileSpeed.hashCode ^
progressInFileSpeeds.hashCode ^
progressInFileSpeedUpdateTime.hashCode ^
progressInFileSpeedUpdateSentBytes.hashCode ^
iCloudDownloadProgress.hashCode ^
cancelToken.hashCode ^
serverInfo.hashCode ^
autoBackup.hashCode ^
backgroundBackup.hashCode ^
backupRequireWifi.hashCode ^
backupRequireCharging.hashCode ^
backupTriggerDelay.hashCode ^
availableAlbums.hashCode ^
selectedBackupAlbums.hashCode ^
excludedBackupAlbums.hashCode ^
allUniqueAssets.hashCode ^
selectedAlbumsBackupAssetsIds.hashCode ^
currentUploadAsset.hashCode;
}
}