Remove manual creation of tokio runtime#8
Conversation
By leveraging the tokio feature of UniFFI we don't need to manually instantiate the runtime and thus can easily maintain the same code between the BTLB iOS app and the CLI. GH-6
|
This is awesome, I'll have a look later! |
q231950
left a comment
q231950
left a comment
There was a problem hiding this comment.
@molikuner this is a fantastic pr, thank you so much! I created a testflight build from BTLB main+ these changes and checked refresh, renewal and search. It all looked great 👍 I love the API refinement that's getting rid of Option and instead returning a future, that's great as well.
| /// | ||
| /// # Returns | ||
| /// * `Option<String>` - The first URL that returned 200 or None | ||
| pub(crate) async fn test_urls( |
There was a problem hiding this comment.
Maybe rename to ping_urls or validate_urls?
There was a problem hiding this comment.
I've renamed it to validate_urls 👍
| } | ||
|
|
||
| #[uniffi::export] | ||
| #[uniffi::export(async_runtime = "tokio")] |
There was a problem hiding this comment.
Ok, so this is where the magic happens ☝️
| pub(crate) fn search_result_detail_from( | ||
| document: scraper::Html, | ||
| ) -> Option<SearchResultDetail> { | ||
| ) -> impl Future<Output = SearchResultDetail> + Send { |
There was a problem hiding this comment.
This confused be for a moment that the 2 scrapers Opc4v2_13Vzg6SearchDetailScraper/HamburgPublicSearchDetailScraper have similar API with different return types. Nothing you need to change, just something I stumbled upon.
There was a problem hiding this comment.
Good point, I could remove the Result from Opc4v2_13Vzg6SearchDetailScraper as well, but there would still be the difference of this function being async, while the other function is sync (and it doesn't really make sense to introduce async there for no reason). I'm currently thinking about some other ways to align the APIs, so let's keep it like this for now and followup at a later point.
| pub struct RenewalService {} | ||
|
|
||
| #[uniffi::export] | ||
| #[uniffi::export(async_runtime = "tokio")] |
There was a problem hiding this comment.
I checked renewal in a TestFlight build 👍
2 participants
By leveraging the tokio feature of UniFFI we don't need to manually instantiate the runtime and thus can easily maintain the same code between the BTLB iOS app and the CLI.
Closes #6