ImportDataItem* item =
[[ImportDataItem alloc] initWithType:ImportDataItemType::kPasswords
status:ImportDataItemImportStatus::kImported
count:results.number_imported];
[_consumer setImportDataItem:item];Nit: A bit weird that here we create a local var for `item` and just above we instantiate it directly inline, let's be consistent
// credential type is handled in a separate async task. Creates a barrier
// closure to analyze the results when all tasks finish.Using a barrier closure is an implementation detail. Let's instead say that "results are analyzed once all tasks complete."
constexpr int kSupportedCredentialTypesAmount = 2;/s/Amount/Count
base::SequencedTaskRunner::GetCurrentDefault()->PostTask(Is it important that these run in sequence, or can we just use ThreadPool?
[weakSelf startImportingPasswords:barrierClosure];I'm assuming neither of these two tasks performs any blocking operations (e.g. file I/O) but let me know if I'm wrong
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
ImportDataItem* item =
[[ImportDataItem alloc] initWithType:ImportDataItemType::kPasswords
status:ImportDataItemImportStatus::kImported
count:results.number_imported];
[_consumer setImportDataItem:item];Nit: A bit weird that here we create a local var for `item` and just above we instantiate it directly inline, let's be consistent
I was thinking ahead that this `item` will need to set its `invalidCount` property eventually, but there was no indication of that in the code..
// credential type is handled in a separate async task. Creates a barrier
// closure to analyze the results when all tasks finish.Using a barrier closure is an implementation detail. Let's instead say that "results are analyzed once all tasks complete."
Done
constexpr int kSupportedCredentialTypesAmount = 2;Rafał Godlewski/s/Amount/Count
Done
I'm assuming neither of these two tasks performs any blocking operations (e.g. file I/O) but let me know if I'm wrong
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
base::SequencedTaskRunner::GetCurrentDefault()->PostTask(Is it important that these run in sequence, or can we just use ThreadPool?
Summary of some offline discussions:
Hence, with this CL I'll proceed with having a PostTaskAndReplyWithResult to translate NSObjects async and call the importer logic on the original sequence.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
_allCredentialTypesProcessedClosure.Reset();I don't think this is actually necessary; BarrierCallback already invalidates itself when the last invocation runs.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I don't think this is actually necessary; BarrierCallback already invalidates itself when the last invocation runs.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
11 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: ios/chrome/browser/credential_exchange/model/credential_importer.mm
Insertions: 0, Deletions: 2.
The diff is too large to show. Please review the diff.
```
[iOS][CX] Handle import transitions
This CL adds a skeleton of the remaining logic in credential importer
and adds a bunch of TODOs to annotate it. Notable changes:
* processing each credential type is triggered in its separate async task
* barrier closure is added to wait for all credential types processing to finish, before moving to next steps
* adds finishImport function that should resume the import in respective importers once all conflicts were resolved (if there were any)
Additionally adds a small change to trigger the UI transition from not
started to importing in credential_import_mediator.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |