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

Account for constantly breaking APIs #1304

Closed
dcindia opened this issue Mar 8, 2021 · 6 comments
Closed

Account for constantly breaking APIs #1304

dcindia opened this issue Mar 8, 2021 · 6 comments

Comments

@dcindia
Copy link

dcindia commented Mar 8, 2021

Intro

I was trying to fire an intent that requires sharing of file to different application. Then i observed that API 24 has a drastic change, oh that FileProvider

Background

Was trying to build a new API to auto update kivy APKs directly from Github, Playstore or Amazon. Whole of code written, tested but when comes to deploying i discovered that at last step i.e. transferring apk to package manager, there was something wrong.

The Problem

API 24 brings with it compulsion to use Fileprovider for such cases. I know how i can solve this, adding newly required stuffs template files in .buildozer.
But with me anyone using this API have to dig five levels deep and change those stuffs. Isn't it cumbersome and more prone to errors.

The Big Problem

Bigger because this is inevitable. We are facing one of cons of semantic versioning i.e.
Every update is API breaking

Further on the same road, API 30 brings Scoped Storage on field. Kivy/Buildozer have improved a lot but handling APIs is major problem left with it.
No functions provided to handle different APIs inside from code.
Introduction of custom classes, decorators or making available basic methods to comman practices.

Subsequent Advantages

Currently, some recipes and widgets by kivymd are used to extend the limits of kivy. I believe that python files themselves are capable as extension instead of libraries for every small things. Greater community contribution is also expected.

Conclusion

It should not be expected as a feature request. There can be ways it can be improved and collect some suggestions how this can be tackled in a future proof way.
Workarounds for my personal problem are also heartly welcomed.

@RobertFlatt
Copy link
Contributor

First off, there is nothing anybody here can do about the Android developers changing stuff. Learn to enjoy it or go crazy.

For version management, I think you can get the build api (as an int) at run time with:

mActivity.getApplicationContext().getApplicationInfo().targetSdkVersion

No need for a FileProvider. Use api >=29 anything you put in "scoped storage" gets a uri that might previously have required a FileProvider. So anything that has been shared can be shared! Which sounds trivial, but indicates the underlying model is now coherent.

Scoped storage is really easy, all you need to know is that it is a database not a Linux file system.
I'll share some examples sometime soon, and add another post here at that time.

@dcindia
Copy link
Author

dcindia commented Mar 9, 2021 via email

@RobertFlatt
Copy link
Contributor

Perhaps the .apk case is special, but I can share a file by inserting it in the MediaStore.
The returned uri can be used to share using ACTION_SEND in the usual way. No additional FileProvider required.

Like this (autoclass() implied!), In the fragment below the shareable .doc file is made visible under Documents. Which is why it can be shared with another app.

root_uri = MediaStoreFiles.getContentUri('external')
# make a MediaStore uri
cv = ContentValues()
cv.put(MediaStoreMediaColumns.DISPLAY_NAME, file_name)
cv.put(MediaStoreMediaColumns.MIME_TYPE, 'application/doc')  
cv.put(MediaStoreMediaColumns.RELATIVE_PATH, sub_directory)  # requires api>=29, else remove
context = mActivity.getApplicationContext()    
uri = context.getContentResolver().insert(root_uri, cv)
# then copy my file contents to the MediaStore
ws  = context.getContentResolver().openOutputStream(uri)
rs = FileInputStream(file_path)
FileUtils.copy(rs,ws)

I'll still share a running example. However right now I find that when returning to the Kivy app after sharing with some particular apps the Kivy screen is black. My Kivy app is there as the buttons work, I just can't see them.
Anyway I need to figure that out, and I don't know how long that will take.

@dcindia
Copy link
Author

dcindia commented Mar 10, 2021

  • I think you are right. There are other ways of getting the same behavior. I found a way to directly send file without use of URI here. However, the alternative solution is so complicated that i assume is going to be challenge for pyjnius capabilities.
    Packaging data in ClipData can also be a good approach.
  • Add optional android fileprovider. python-for-android#1922 may solve these problems at once in a pythonic way. I am in favor of merging this pull request. I don't think that python users are so dumb that they can't override manifest or xml files, if needed.
  • That blackout issue, i experienced once. Same gmail app doesn't cause any issue with mailto: intent. If its only happening with selective apps means those apps might be sending something back that our application is unable to receive.

@RobertFlatt
Copy link
Contributor

That blackout issue, i experienced once.
Thank you, this one statement enabled me to look for Window.update_viewport()

My view of Android 29+ storage is described here https://github.com/RobertFlatt/Android-for-Python/tree/main/Android-for-Python-Users#android-storage

My code to share a file or plain text is here https://github.com/RobertFlatt/Android-for-Python/tree/main/share_snd

And code that implements my view of storage https://github.com/RobertFlatt/Android-for-Python/tree/main/storage

@Julian-O
Copy link
Contributor

Closing as WontFix as there seems to be approaches that reduce the pain, but there will always be API changes.

@Julian-O Julian-O closed this as not planned Won't fix, can't repro, duplicate, stale Oct 25, 2023
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

No branches or pull requests

3 participants