Skip to content
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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

SnayperTihCreator
Copy link

Решил заняться реализацией файлового диалога для андроид

Copy link
Member

@freakboy3742 freakboy3742 left a 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.

Comment on lines +6 to +8
BufferedReader = java.jclass("java.io.BufferedReader")
InputStreamReader = java.jclass("java.io.InputStreamReader")
Objects = java.jclass("java.util.Objects")
Copy link
Member

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.

@@ -130,25 +132,39 @@ def __init__(


class OpenFileDialog(BaseDialog):
class HandlerOpenDialog(uf.HandlerFileDialog):
Copy link
Member

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.

Objects = java.jclass("java.util.Objects")


class HandlerFileDialog(abc.ABC):
Copy link
Member

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.


def _handler(self, uri):
ist = self.mActive.getContentResolver().openInputStream(uri)
isr = uf.InputStreamReader(uf.Objects.requireNonNull(ist))
Copy link
Member

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.

@@ -0,0 +1 @@
Partial OpenFileDialog implementation
Copy link
Member

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:

Suggested change
Partial OpenFileDialog implementation
Android now has support for OpenFileDialog.

@mhsmith mhsmith changed the title Android update A utility module has been created to work with android external storage files Nov 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants