-
-
Notifications
You must be signed in to change notification settings - Fork 687
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
A utility module has been created to work with android external storage files #2910
base: main
Are you sure you want to change the base?
Conversation
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.
Thanks for the contribution; however, there's a few issues here.
Firstly, have a read of our contribution guide, and in particular the section on submitting a pull request - there's a couple of additional pieces that we require in a pull request before it will pass CI.
Most of these are related to code style - you've altered some existing indentation from the preferred style. The changes are consistent with a formatting style imposed by PyCharm; I don't know if that's what you've done, but Toga uses the black
code style.
Second, you've added some docstrings in Russian; we require all code and docs to be in English. Those are also getting caught by the precommit checks - mostly because of the choice of variable names like ist
. We try to have more meaningful variables names (like input_stream
), rather than trying to abbreviate. The same goes for the uf
import alias - that's not a pattern we generally use.
Lastly - we get to the actual implementation. The VFile object you've created isn't quite the API that is required here. In your code, VFile represents an already open file; the existing Dialogs API returns a Path
object that can be opened and manipulated. This also allows the user to read a file in text or binary mode. Any API here needs to be modelled after the existing API. The correct abstraction here is an object that wraps the contentResolver()
, on which there is an open()
context manager that returns a readable/writable object (depending on the args passed to open()
), or to do that read/write in binary mode.
It would be worth reviewing the prior art related to this feature request: see #1171 and #1158 for details.
BufferedReader = java.jclass("java.io.BufferedReader") | ||
InputStreamReader = java.jclass("java.io.InputStreamReader") | ||
Objects = java.jclass("java.util.Objects") |
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.
You should be able to use from java.io import BufferedReader
etc here.
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.
Thank you for the information
android/src/toga_android/dialogs.py
Outdated
@@ -130,25 +132,39 @@ def __init__( | |||
|
|||
|
|||
class OpenFileDialog(BaseDialog): | |||
class HandlerOpenDialog(uf.HandlerFileDialog): |
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.
Unless there's a reason for nesting classes like this, we generally keep classes at the module level.
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.
Here is the reason for the class to be used only with OpenFileDialog
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.
That's not a reason to nest classes. It complicates the class definition, and makes debugging harder because there's implicit context (and potentially closures) that can contribute to any bug being observed.
Objects = java.jclass("java.util.Objects") | ||
|
||
|
||
class HandlerFileDialog(abc.ABC): |
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.
It's not clear to me why this is in utilfile.py
, rather than part of the dialogs class.
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 was just afraid to change something in the main file.
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.
Ok... but it's a dialog class. It should be with dialogs, not with utilities for file handling.
android/src/toga_android/dialogs.py
Outdated
|
||
def _handler(self, uri): | ||
ist = self.mActive.getContentResolver().openInputStream(uri) | ||
isr = uf.InputStreamReader(uf.Objects.requireNonNull(ist)) |
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.
InputStreamReader is a java class; it should be imported from the Java namespace, not implicitly from the utilfile
namespace.
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 will change the import
changes/2910.misc.rst
Outdated
@@ -0,0 +1 @@ | |||
Partial OpenFileDialog implementation |
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.
The changelog message should be written in the form of a potential release note for the new feature. In this case, it should be a .feature
(this isn't a small miscellaneous fix - it's a major new feature), and should read something like:
Partial OpenFileDialog implementation | |
Android now has support for OpenFileDialog. |
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.
And here I didn't expect it to be a major new feature. Because I looked at it and saw how a partial implementation of opening files
Generalization implementation of file interaction
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.
Thanks for those updates; however, there's still a lot more work that needs to be done (some of which relates to review comments I gave last time).
Fundamentally, it feels like you're missing part of the high-level architecture of Toga. The parts that are literally Android code seem OK; but that's never been the complication preventing this feature from being added. As noted in my last review, there's a "bigger picture" feature that needs to be addressed - #1171. That isn't an "Android" feature - it's something that needs to be designed and integrated as a high-level API throughout Toga's file handling. I'd almost suggest it needs to be implemented entirely independently, as a pre-requisite for implementing any Android File APIs.
|
||
@abc.abstractmethod | ||
def show(self): | ||
"""Запуск менеджера""" |
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.
As noted previously, we need the code to be documented in English.
android/src/toga_android/dialogs.py
Outdated
@@ -133,17 +135,32 @@ def __init__( | |||
|
|||
|
|||
class OpenFileDialog(BaseDialog): | |||
class HandlerOpenDialog(utilfile.HandlerFileDialog): |
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.
As noted previously, there's no reason for this class to be nested.
Objects = java.jclass("java.util.Objects") | ||
|
||
|
||
class HandlerFileDialog(abc.ABC): |
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.
Ok... but it's a dialog class. It should be with dialogs, not with utilities for file handling.
pass | ||
|
||
|
||
class BasePath(io.TextIOBase, abc.ABC): |
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 seems like something that should be a core-level utility, not something that is Android specific. It's also unclear why an object named Path
would be subclassing io.TextIOBase
- is it a path, or a text-readable IO object?
|
||
|
||
class PathReader(BasePathReader): | ||
"""A phalloid object for reading. |
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.
A what? Are you sure this is the word you mean?
@@ -0,0 +1,29 @@ | |||
class Singtools(type): |
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 can't work out what this collection of utilities is trying to achieve, or why it is almost duplicated between the Android and Winforms backends.
changes/2910.misc.rst
Outdated
Android implementation of OpenFileDialog | ||
|
||
Adding a utility module for reading from external storage files | ||
|
||
Adding singleton for file management on Android/Windows for API communication | ||
|
||
Support with Python 3.10+ |
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.
The change note isn't a commit message. It's a description of the new feature as it would appear in the release notes.
To that end, this shouldn't be a misc
note - if it were to be merged, it would be a major new feature
.
Изменение чтобы сосстествало общему API
Решил заняться реализацией файлового диалога для андроид