move the PdfViewer activity to be hosted as a Fragment #70
Comments
inthewaves
added a commit
to inthewaves/PdfViewer
that referenced
this issue
Aug 28, 2020
- Host the WebView and all of its related code inside of a Fragment
instead of an Activity. Fragments can give us more flexibility in the
future on how we can display the WebView, how we could manage some
bottom menu via a BottomNavigationView or similar, etc.
- Use a ViewModel and LiveData architecture in order to move away from
Loaders, which are now deprecated. Almost all state information for the
viewer (like current page, zoom ratio) is now stored in the ViewModel,
which survives configuration changes.
- Rewrite the document property parsing in DocumentPropertiesLoader in
Kotlin, taking advantage of Kotlin coroutines to do asynchronous
parsing of the document properties.
- Dynamically update the properties dialog after PDF loads.
If viewing the PDF properties while the PDF loads, before, the dialog
would show an error message. Now, the error message will be swapped out
with the parsed info as soon the document properties have been parsed.
This is done using an Observer on LiveData.
- Use an alpha version of AndroidX Fragment so that we can use a simpler
way to pass data between two Fragments:
https://developer.android.com/training/basics/fragments/pass-data-between
- Alpha version of Fragments also has ActivityResultLauncher, which
simplifies the SAF launch
https://developer.android.com/training/basics/intents/result
"While the underlying startActivityForResult() and onActivityResult()
APIs are available on the Activity class on all API levels, it is
strongly recommended to use the Activity Result APIs introduced in
AndroidX Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02."
Closes GrapheneOS#69, GrapheneOS#70
inthewaves
added a commit
to inthewaves/PdfViewer
that referenced
this issue
Aug 29, 2020
- Host the WebView and all of its related code inside of a Fragment
instead of an Activity. Fragments can give us more flexibility in the
future on how we can display the WebView, how we could manage some
bottom menu via a BottomNavigationView or similar, etc.
- Use a ViewModel and LiveData architecture in order to move away from
Loaders, which are now deprecated. Almost all state information for the
viewer (like current page, zoom ratio) is now stored in the ViewModel,
which survives configuration changes.
- Rewrite the document property parsing in DocumentPropertiesLoader in
Kotlin, taking advantage of Kotlin coroutines to do asynchronous
parsing of the document properties.
- Dynamically update the properties dialog after PDF loads.
If viewing the PDF properties while the PDF loads, before, the dialog
would show an error message. Now, the error message will be swapped out
with the parsed info as soon the document properties have been parsed.
This is done using an Observer on LiveData.
- Use an alpha version of AndroidX Fragment so that we can use a simpler
way to pass data between two Fragments:
https://developer.android.com/training/basics/fragments/pass-data-between
- Alpha version of Fragments also has ActivityResultLauncher, which
simplifies the SAF launch
https://developer.android.com/training/basics/intents/result
"While the underlying startActivityForResult() and onActivityResult()
APIs are available on the Activity class on all API levels, it is
strongly recommended to use the Activity Result APIs introduced in
AndroidX Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02."
Closes GrapheneOS#69, GrapheneOS#70
inthewaves
added a commit
to inthewaves/PdfViewer
that referenced
this issue
Aug 30, 2020
- Host the WebView and all of its related code inside of a Fragment
instead of an Activity. Fragments can give us more flexibility in the
future on how we can display the WebView, how we could manage some
bottom menu via a BottomNavigationView or similar, etc.
- Use a ViewModel and LiveData architecture in order to move away from
Loaders, which are now deprecated. Almost all state information for the
viewer (like current page, zoom ratio) is now stored in the ViewModel,
which survives configuration changes.
- Rewrite the document property parsing in DocumentPropertiesLoader in
Kotlin, taking advantage of Kotlin coroutines to do asynchronous
parsing of the document properties.
- Dynamically update the properties dialog after PDF loads.
If viewing the PDF properties while the PDF loads, before, the dialog
would show an error message. Now, the error message will be swapped out
with the parsed info as soon the document properties have been parsed.
This is done using an Observer on LiveData.
- Use an alpha version of AndroidX Fragment so that we can use a simpler
way to pass data between two Fragments:
https://developer.android.com/training/basics/fragments/pass-data-between
- Alpha version of Fragments also has ActivityResultLauncher, which
simplifies the SAF launch
https://developer.android.com/training/basics/intents/result
"While the underlying startActivityForResult() and onActivityResult()
APIs are available on the Activity class on all API levels, it is
strongly recommended to use the Activity Result APIs introduced in
AndroidX Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02."
Closes GrapheneOS#69, closes GrapheneOS#70
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Google seems to prefer and consider single-Activity architecture with Fragments as a best practice for managing UI, as seen by their Sunflower app and https://android-developers.googleblog.com/2018/05/use-android-jetpack-to-accelerate-your.html (though now they're looking into Compose and whatever new frameworks they want to move one to lol)
Using a Fragment for the WebView might be helpful for future features such as
The text was updated successfully, but these errors were encountered: