Feature Request P3
Status Update
No update yet.
Comments
ni...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d46999fa005b4726287814ea0f8abe30cf189a01
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue May 26 15:36:06 2020
Clean up ActivityResultCaller implementation
Instead of using two separate anonymous classes to be returned by the
register methods, lets clean it up by using an internal class and only
doing the implementation once.
Test: Tested in app
Bug: 156875743
Change-Id: Ia63dd0dce4ecd7115ea93168f889e119738e3352
M activity/activity-ktx/api/1.2.0-alpha06.txt
M activity/activity-ktx/api/current.txt
M activity/activity-ktx/api/public_plus_experimental_1.2.0-alpha06.txt
M activity/activity-ktx/api/public_plus_experimental_current.txt
M activity/activity-ktx/api/restricted_1.2.0-alpha06.txt
M activity/activity-ktx/api/restricted_current.txt
M activity/activity-ktx/src/main/java/androidx/activity/result/ActivityResultCaller.kt
https://android-review.googlesource.com/1318046
Branch: androidx-master-dev
commit d46999fa005b4726287814ea0f8abe30cf189a01
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue May 26 15:36:06 2020
Clean up ActivityResultCaller implementation
Instead of using two separate anonymous classes to be returned by the
register methods, lets clean it up by using an internal class and only
doing the implementation once.
Test: Tested in app
Bug: 156875743
Change-Id: Ia63dd0dce4ecd7115ea93168f889e119738e3352
M activity/activity-ktx/api/1.2.0-alpha06.txt
M activity/activity-ktx/api/current.txt
M activity/activity-ktx/api/public_plus_experimental_1.2.0-alpha06.txt
M activity/activity-ktx/api/public_plus_experimental_current.txt
M activity/activity-ktx/api/restricted_1.2.0-alpha06.txt
M activity/activity-ktx/api/restricted_current.txt
M activity/activity-ktx/src/main/java/androidx/activity/result/ActivityResultCaller.kt
ma...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 55c784def8b9942026075af6fc659b551732ef44
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue May 26 08:45:51 2020
Add getContract to ActivityResultLauncher
Intents provide a way to check if the intent can be handled by any
Activity components and the ActivityResultLauncher should provide
the ability to do something similar.
This change adds a getContract API to ActivityResultLauncher that gives
the returns the contract used to register the launcher. This means that
users can create an Intent from their contract and make all of their
desired checks.
Test: ActivityResultLauncherTest
Bug: 156875743
RelNote: "ActivityResultLauncher now allows you to get the
ActivityResultContract that was used to register the launcher."
Change-Id: I64f536f2b3dde3e87cea884c6b9c111e5efe26ed
M activity/activity-ktx/build.gradle
M activity/activity-ktx/src/androidTest/AndroidManifest.xml
A activity/activity-ktx/src/androidTest/java/androidx/activity/result/ActivityResultCallerTest.kt
M activity/activity-ktx/src/main/java/androidx/activity/result/ActivityResultCaller.kt
M activity/activity/api/1.2.0-alpha06.txt
M activity/activity/api/current.txt
M activity/activity/api/public_plus_experimental_1.2.0-alpha06.txt
M activity/activity/api/public_plus_experimental_current.txt
M activity/activity/api/restricted_1.2.0-alpha06.txt
M activity/activity/api/restricted_current.txt
M activity/activity/src/androidTest/java/androidx/activity/result/ActivityResultLauncherTest.kt
M activity/activity/src/main/java/androidx/activity/result/ActivityResultLauncher.java
M activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
https://android-review.googlesource.com/1317916
Branch: androidx-master-dev
commit 55c784def8b9942026075af6fc659b551732ef44
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue May 26 08:45:51 2020
Add getContract to ActivityResultLauncher
Intents provide a way to check if the intent can be handled by any
Activity components and the ActivityResultLauncher should provide
the ability to do something similar.
This change adds a getContract API to ActivityResultLauncher that gives
the returns the contract used to register the launcher. This means that
users can create an Intent from their contract and make all of their
desired checks.
Test: ActivityResultLauncherTest
Bug: 156875743
RelNote: "ActivityResultLauncher now allows you to get the
ActivityResultContract that was used to register the launcher."
Change-Id: I64f536f2b3dde3e87cea884c6b9c111e5efe26ed
M activity/activity-ktx/build.gradle
M activity/activity-ktx/src/androidTest/AndroidManifest.xml
A activity/activity-ktx/src/androidTest/java/androidx/activity/result/ActivityResultCallerTest.kt
M activity/activity-ktx/src/main/java/androidx/activity/result/ActivityResultCaller.kt
M activity/activity/api/1.2.0-alpha06.txt
M activity/activity/api/current.txt
M activity/activity/api/public_plus_experimental_1.2.0-alpha06.txt
M activity/activity/api/public_plus_experimental_current.txt
M activity/activity/api/restricted_1.2.0-alpha06.txt
M activity/activity/api/restricted_current.txt
M activity/activity/src/androidTest/java/androidx/activity/result/ActivityResultLauncherTest.kt
M activity/activity/src/main/java/androidx/activity/result/ActivityResultLauncher.java
M activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
re...@gmail.com
This has been fixed internally and will be available in the Activity 1.2.0-alpha06 release.
To address this the ActivityResultLauncher now gives access to the ActivityResultContract.
With the contract, you can create the intent and use it to call resolveActivity() directly:
launcher.contract.createIntent(context, input).resolveActivity(packageManager)
tu...@gmail.com
Keep in mind that due to the resolveActivity() will return null unless you add the specific <queries> elements to your manifest.
As per that doc, the alternative is to catch the ActivityNotFoundException yourself by wrapping your launch() call in a try / catch, just like if you were using startActivityForResult() yourself.
ka...@gmail.com
+1
sl...@gmail.com
+1
gi...@gmail.com
Yes, the original intention of 109505022 was to be able to reorganize any items even those that existed before this API was created. The old Picasa API allowed this - I always thought the intention of this was to bring back the functionality we had with the old Picasa API?
But at least Google is looking at these bugs, thanks, Google.
But at least Google is looking at these bugs, thanks, Google.
ed...@gmail.com
+1 for the precision defined in
ke...@gmail.com
+1
og...@gmail.com
+1
th...@gmail.com
+1
fi...@algures.net
+1
ja...@gmail.com
+1
I would really like to support more advanced bulk album management than is possible through the website. Especially with the Google drive integration coming to an end.
I would really like to support more advanced bulk album management than is possible through the website. Especially with the Google drive integration coming to an end.
to...@merly.org
+1
wi...@gmail.com
As it is almost impossible in Photos' UI itself to easily select a couple thousand of photos and add them to an album, I was hoping to write a tool for this myself. This requires that existing photos can be added to an album using the API.
gr...@gmail.com
+1 Yes, we really need these APIs to be able to add and remove user photos that have been uploaded by another app like Google Backup and Sync or Google Photos. As it stands now the API is fairly limited. Its also inconsistent in that it allows you to list and view photos that have been created by these other apps, but you cannot group them into albums. Perhaps we need another authorization scope that gives the app full access to its photos, as well as the ones created by all other apps including Google Photos as well as Google Backup and Sync.
ma...@gmail.com
+1 After weeks of effort to get the correct mediaItemIds, I am perplexed to find out that that Google blocks adding an item to an album.
cl...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
re...@gmail.com
+1
an...@gmail.com
+1
ri...@gmail.com
The response to asking to be able to delete items was that it's a risk - as an app might perform a destructive action.
But I can't see how this can be an issue. If it's restricted to albums that the app created, then there's no risk at all.
It would also be good to be able to remove items from an album that the app has created (again, without removing the actual item)
But I can't see how this can be an issue. If it's restricted to albums that the app created, then there's no risk at all.
It would also be good to be able to remove items from an album that the app has created (again, without removing the actual item)
ma...@gmail.com
+1
It's also not very explicit in the documentation - I wouldn't have started on my reorg project if I had seen this earlier.
It's also not very explicit in the documentation - I wouldn't have started on my reorg project if I had seen this earlier.
gi...@gmail.com
+1
ch...@gmail.com
+1
ab...@gmail.com
+1
ju...@gmail.com
+1
ju...@gmail.com
What are the chances that Google actually adds this feature? It’s been many months now since the initial request...
ma...@lohr.net
+1
@Google: Any comment on this?
@Google: Any comment on this?
ig...@gelado.cat
+1
bi...@gmail.com
+!
ct...@gmail.com
+1
al...@gmail.com
+1
ev...@gmail.com
+1
ma...@maremoto.com
+1 Don't you think that would be easily solved by adding a new scope in order to allow the app to add existing media to albums?
Maybe that could be solved also if they would allow the action when the type of users allowed to authenticate are internal.
I think this won't be solved. The reason for @Google to avoid this action exceeds the conceptual or the programmatic issues. It is probably that they doesn't want a corporation to use Google Photos Mobile App as a part of an internal software solution.
If this is the reason, Google should have in account that this does not avoid that we use Google Photos App for the same goals. They are only getting their user angry (almost when we are paying big amounts of money for Google Suite for example).
Please, take this in account and at least answer us. We are waiting for you to give some solution or tell us if you wont solve it.
Thank you all.
Maybe that could be solved also if they would allow the action when the type of users allowed to authenticate are internal.
I think this won't be solved. The reason for @Google to avoid this action exceeds the conceptual or the programmatic issues. It is probably that they doesn't want a corporation to use Google Photos Mobile App as a part of an internal software solution.
If this is the reason, Google should have in account that this does not avoid that we use Google Photos App for the same goals. They are only getting their user angry (almost when we are paying big amounts of money for Google Suite for example).
Please, take this in account and at least answer us. We are waiting for you to give some solution or tell us if you wont solve it.
Thank you all.
tc...@gmail.com
+1
ma...@gmail.com
+1
fr...@gmail.com
+1
ca...@kellcomnet.us
+1 I am working on a app to automatically organize "orphaned" media items into albums based on their dates so that the user can then rename the albums to something relevant but anytime I try to add an existing mediaitem to an album I am getting "Request contains an invalid media item id"
ni...@gmail.com
+1
ro...@gmail.com
+1
wd...@gmail.com
+1
om...@gmail.com
+1
st...@gmail.com
Why is this even a thing?
What sort of API is this?
Just allow me to manage my own data!!!!!!!!
What sort of API is this?
Just allow me to manage my own data!!!!!!!!
go...@gmail.com
+1
dn...@gmail.com
It would be interesting and helpful to learn from Google why in the first place "foreign-apps" were dis-allowed from operating on MediaItems. Was it security? Doesn't seem likely, since each app has to ask permission and pass security checks.
This is a valuable part of the api, which would allow developers to code apps that do many things end-users would like a lot.
This is a valuable part of the api, which would allow developers to code apps that do many things end-users would like a lot.
pu...@gmail.com
+1
an...@gmail.com
+1
ay...@gmail.com
Interestingly, currently you can still add an item that was uploaded via web interface, to an album you created via the API, if you specify the albumId in batchCreate. It does not work if you first create an item, and then try to add it to an album. So looks like some of current limitations are not well enforced. More details here:
https://github.com/ylexus/jiotty-photos-uploader/issues/49#issuecomment-650786281
lu...@gmail.com
+1
ge...@gmail.com
+1
This API is basically useless without this. Spent a day only to realize these APIs only let you control data created by the app and not pre-existing data.
This should be made extremely clear on the Google API Page. I lost a day :(
I really hope Picasa would come back .. Google Photos is so limiting.
This API is basically useless without this. Spent a day only to realize these APIs only let you control data created by the app and not pre-existing data.
This should be made extremely clear on the Google API Page. I lost a day :(
I really hope Picasa would come back .. Google Photos is so limiting.
ph...@gmail.com
je suis d'accord avec tout ceux qui me précède même si j'ai pas tout lu
c'est réellement pénible cette restriction
déjà qu'il ne soit pas possible d'appliquer { 'sharedAlbumOptions': {'isCollaborative': True, 'isCommentable': True }} sur ces vieux albums Picasa !
à croire que Google pense que je dois faire cela manuellement ...
c'est réellement pénible cette restriction
déjà qu'il ne soit pas possible d'appliquer { 'sharedAlbumOptions': {'isCollaborative': True, 'isCommentable': True }} sur ces vieux albums Picasa !
à croire que Google pense que je dois faire cela manuellement ...
jo...@googlemail.com
+1
sa...@gmail.com
+1
ea...@gmail.com
+1
ak...@gmail.com
+1
....without it this api cannot be used to manage any existing photos :(
....without it this api cannot be used to manage any existing photos :(
ak...@gmail.com
previous item here should not be marked as fixes as clearly there is no way to add EXISTING items to albums
ma...@gmail.com
+1
bo...@gmail.com
+1
si...@gmail.com
+1
al...@gmail.com
+1
o....@gmail.com
+1
me...@gmail.com
+1
el...@gmail.com
+1
ri...@rilhia.com
This limitation renders this API pretty useless for most use cases. Please prioritise sorting this
ji...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
th...@gmail.com
+1
me...@clgr.io
+1
me...@clgr.io
So sad we can't do this ;((
mi...@gmail.com
The current policy is extremely restrictive and frustrating. I can understand that the operations on media are extremely sensitive both from the perspective of the user's privacy and the threat to the durability of the user's precious media should the app using the API run amok, but we're used to granting such rights to apps on our phones so the suggestion of some new scopes to make the distinction between app-created/app-managed and user-created/app-managed operations absolutely explicit seems like the transparent way to go?
Any chance of a formal response?
Any chance of a formal response?
se...@gmail.com
+1
pi...@gmail.com
+1
12...@gmail.com
Lost a fair bit of time before discovering this :( my use case is organising photos for a log book - the photos already exist in Google Photos and the aim of my app is to create a link so they can be viewed as part of the logbook.
This is likely to be a driver for me to look for a better place to store my photos if I can't manipulate them with API and Google Drive sync doesn't work anymore.
This is likely to be a driver for me to look for a better place to store my photos if I can't manipulate them with API and Google Drive sync doesn't work anymore.
ba...@gmail.com
+1
jo...@gmail.com
+1
kr...@gmail.com
+1
xu...@gmail.com
+1
jp...@gmail.com
+1. I feel like I wasted a fair bit of time without reading this fine print :(
jo...@gmail.com
+1 - If Google isn't going to improve on Photos (they went backwards when they stopped Picasa), then please allow us to do your work for you and create something that is actually functional for people who organize and catalog their years and years worth of photos and videos.
I feel they don't want to make it easy to upload all of our organized albums until after they relinquish on the free storage deal.
I feel they don't want to make it easy to upload all of our organized albums until after they relinquish on the free storage deal.
no...@gmail.com
+1
Is there any update on this?
The current Library API does not allow users or developers to manage/organize their existing pictures and existing albums in any meaningful way. Users essentially have read-only access to their own existing media via this API (we can change descriptions).
The Google Drive API allows
Some transparency would go a long way here.
es...@gmail.com
+1
ra...@rr7.com
+1
le...@gmail.com
It is incredible that this is not supported by the API :( I spent quite some time on writing an API client only to find out that I cannot manage existing albums and media items with the API at all :( Without this possibility it is pretty useless.
at...@gmail.com
+1
we...@gmail.com
+1
fr...@gmail.com
+1
sn...@gmail.com
+1
an...@gmail.com
+1 I am really disappointed at how limited the google photos API is :(
ni...@gmail.com
+1, i want use api to manager my exist mediaitems, if it can not ,i really do not know what can this api do
ji...@gmail.com
+1 really need this api feature, would really appreciate it we could have this!
sh...@gmail.com
+1 Not a single post to this issue by Google??
an...@gmail.com
+1 - needed to re-create old picassa albums programmatically
je...@gmail.com
+1
je...@geerdink.xyz
+1; the value of the API is quite low of you cannot somehow (additional scope?) manage all items. There is a huge opportunity for analysis of photo's and tagging them / putting them in albums, this is not allowed. However you can access aal existing photo's, so not sure how that fits security-wise. So I am not sure what the security concern is. Given the base assumption around security that mediaitems can not be modified if they are not owned by the API I would suggest that linking existing mediaitems to API created Albums should be allowed as there is no change to the actual mediaitem.
Alternatively being able to tag images would be great, but probably a greater security concern.
Alternatively being able to tag images would be great, but probably a greater security concern.
12...@gmail.com
I am actively looking at alternatives to Google Photos because of this missing feature (and the double counting for Google Drive storage for photos). When I hit my 200GB tier limit in the next month or so I'll probably move to something else. Currently evaluating photoprism.
ph...@gmail.com
As nothing is happening here are there any suggestions for alternatives to google photos with a good api?
bu...@gmail.com
+1
am...@gmail.com
+1
do...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1 plllleeease!
sr...@gmail.com
Onedrive is a better alternative and not Onedrive albums.
at...@gmail.com
+1
ka...@gmail.com
+1
ab...@gmail.com
+1
ki...@gmail.com
+1
ba...@gmail.com
+1
kr...@gmail.com
+1 Bump up! Though it seem that this limitation is on purpose as it likely required *more* effort on google side to impose it.
sa...@u.northwestern.edu
+1
br...@gmail.com
+1
rr...@gmail.com
Please.
ca...@gmail.com
+1
ro...@gmail.com
Comment has been deleted.
it...@gmail.com
+1
to...@gmail.com
+1
ka...@gmail.com
+1
dp...@gmail.com
+1
wa...@gmail.com
+1
vi...@gmail.com
+1
i was going crazy from all the time i spent trying to debug my code only to find out that the problem wasnt my code but these artificial limitations imposed on us by google and that its literally impossible to sort stuff like that, that has been uploaded by another app
pls fix asap, been waiting for over a year now
i was going crazy from all the time i spent trying to debug my code only to find out that the problem wasnt my code but these artificial limitations imposed on us by google and that its literally impossible to sort stuff like that, that has been uploaded by another app
pls fix asap, been waiting for over a year now
dm...@gmail.com
Yeah, +100 to this. I have over 65,000 photos and really want to programmatically be able to manage existing ones I've uploaded through the web UI.
vi...@gmail.com
same as #121, i have alot of stuff there, and most of the filenames use the same regex syntax so it would in theory be really easy to sort, but were just not allowed to
es...@gmail.com
There are two tickets on this very issue with over 200 +1s combined, and no updates from the last 5 years.
At the moment, it is impossible to organize existing photos, your OWN photos, into albums using the API. There are many use cases for such a functionality, many of which have already been outlined in the comments above. But especially for libraries that include thousands of photos, this limitation makes it impossible to use Google Photos effectively for many people. I'm already a paying customer, but the unresponsiveness from Google is making me seriously consider moving on to a different service where I can at least organize my photos despite lacking in other features.
Any update on this issue, even a simple explanation as to why it's not possible would be appreciated.
At the moment, it is impossible to organize existing photos, your OWN photos, into albums using the API. There are many use cases for such a functionality, many of which have already been outlined in the comments above. But especially for libraries that include thousands of photos, this limitation makes it impossible to use Google Photos effectively for many people. I'm already a paying customer, but the unresponsiveness from Google is making me seriously consider moving on to a different service where I can at least organize my photos despite lacking in other features.
Any update on this issue, even a simple explanation as to why it's not possible would be appreciated.
mp...@gmail.com
Maybe not all of you are aware yet, but Google doesn't care about this API and our feedback. This is the worst API in history of API. They could do it better, but they don't want to. Additionally my app with so stripped functionality (because API allow almost nothing) was banned overnight 'because of reasons' and 'because we can'.
TBH I have no idea why someone would use so stripped service.
Also - they want your pictures, but they don't want you to take control over them - even downloading them in batches is blocked, so you can't go somewhere else easily.
Cheers for all of you, I'm unfollowing this topic, because I'm tired of constant "+1" emails which won't change a thing. I'm here from the beginning and it has been years. Nothing.
TBH I have no idea why someone would use so stripped service.
Also - they want your pictures, but they don't want you to take control over them - even downloading them in batches is blocked, so you can't go somewhere else easily.
Cheers for all of you, I'm unfollowing this topic, because I'm tired of constant "+1" emails which won't change a thing. I'm here from the beginning and it has been years. Nothing.
re...@weteling.com
+1
Why isnt the api returning the full listof media items. It doenst make any sense.
Why isnt the api returning the full listof media items. It doenst make any sense.
da...@gmail.com
Hey sorry but I might add a +1 notificiation mail to your mailbox.
+1
I'd like to take control back to my content and be able to retrieve all of it via the API.
+1
I'd like to take control back to my content and be able to retrieve all of it via the API.
vi...@gmail.com
you can only request like 50 items at a time. just a simple while loop and it should work. but sadly yeah u cant see the exact contents of albums.
ve...@gmail.com
My main reason for looking at this API was to write something that would manage photos from my camera app. Basically move them to their own album called (you guessed it) "Camera". What a concept. This way I can go into "Camera" album and move these photos (from a computer) to a better storage medium without messing with photos that I continue to want stored on the cloud. Right now Camera photos are just intermixed with the photos that I want to keep on Google Photos.
My opinion is that Google Photos is for photos that you want to continue to have access to from any location, or photos that you want to share with other people or devices (photo frame anyone?). Not some random set of all photos that I took with my phone under poor lighting (rather than my professional grade camera). So please let me manage "MY" photos the way "I" want.
+1
Maybe this feature was implemented for security purposes. How about allowing the user to have an API/End User key that allows them "FULL" access to photos in their account. I understand the concept of API keys for an app that would be generally available to the public. Still the User (who might be giving you money monthly for storage) should have a say in giving full access.
My opinion is that Google Photos is for photos that you want to continue to have access to from any location, or photos that you want to share with other people or devices (photo frame anyone?). Not some random set of all photos that I took with my phone under poor lighting (rather than my professional grade camera). So please let me manage "MY" photos the way "I" want.
+1
Maybe this feature was implemented for security purposes. How about allowing the user to have an API/End User key that allows them "FULL" access to photos in their account. I understand the concept of API keys for an app that would be generally available to the public. Still the User (who might be giving you money monthly for storage) should have a say in giving full access.
de...@psencik.cz
Completed code just to discover that it does not work, because I have not noticed one sentence in documentation. Would it be possible to lift the limitation (not able to add photos to albums that were not created by app) at least for myself somehow? Because Google Photos have very limited functions to organize photos. It is not possible to do almost anything in the API. At least consider, please. Thanks.
na...@gmail.com
+1
dv...@gmail.com
+1
Built an application to maintain my photo collection, then when I'm what I think is almost the finish line, I get the rug pulled out from under me. This restriction is frustrating and seems nonsensical to me.
Built an application to maintain my photo collection, then when I'm what I think is almost the finish line, I get the rug pulled out from under me. This restriction is frustrating and seems nonsensical to me.
ko...@kalmaz.com
Came here to find out this was created in 2019! Seems like there's a message here Google is sending us.
mo...@gmail.com
+1
Unbelievable..
Unbelievable..
sh...@gmail.com
+1
ma...@marenjo.com
+1
ju...@gmail.com
+1
As many others, I would like to have an opportunity to reorganize my existing media library through API, as it's impossible to select thousands of items by filename through the web UI.
As many others, I would like to have an opportunity to reorganize my existing media library through API, as it's impossible to select thousands of items by filename through the web UI.
ar...@gmail.com
+1
ar...@gmail.com
225 requests to fix this.
1595 days since opening (4 years, 4 months).
What does it take to get Google to fix a bug?
1595 days since opening (4 years, 4 months).
What does it take to get Google to fix a bug?
vi...@gmail.com
its not a bug its a feature. designed to be dogshit
ky...@gmail.com
+1....
So sad that Google Photos, the leading one of the photos app market is not fixing these kind of basic problems. So, do we have to use other apps?
So sad that Google Photos, the leading one of the photos app market is not fixing these kind of basic problems. So, do we have to use other apps?
al...@gmail.com
+1
ma...@gmail.com
+1. Let me use my data!!!!!
ky...@gmail.com
+1
je...@gmail.com
As other developers have pointed out, the way the Photos API limits adding media items to albums is detrimental to the integration of Google Photos support in their apps. The vote count clearly shows there are many scenarios where developers would need to be able to reorganize albums containing media items not necessarily uploaded by the organizing app itself.
ak...@gmail.com
+1
to...@gmail.com
so i'm uploading new media items, its just that they have the same picture already in their google photos. so the media item id that i get for my newly uploaded item can't be be used. very broken behavior.
to...@gmail.com
so to work around this what i do is test to see if the uploaded media item has the same filename that i set while creating the media item. if not i'm assuming it was created the that user beforehand and will result in errors when later used. i then trim off 8 pixels from around the border of the image and re-upload so that it will create a new, usable media item. You could also upload a modified version of the media item at the time of failure when you try and add the media items to an album your app controls. Just easier in my case to know in advance instead of react later.
no...@gmail.com
Comment has been deleted.
no...@gmail.com
I spend a few hours on a script that:
- Lists all items in my local folder that I marked for deletion.
- Fetches all images from the Photo's api.
- Filtering images received from the api, matching my local "delete" list.
- Creates a new album "to delete" on the api.
(as means of a workaround of the api not supporting a "delete" command) - Tried to add all filtered images to the new "to delete" album.
(And this is where it failed)
The error returned is way to generic. It says "Request contains an invalid media item id." Where it could/should say something like "No permission to handle media not created by this application" or something that actually gives a clue about the issue.
Why not provide an extra scope That could be placed in the "Your restricted scopes" section that clearly states to the user that managing ALL images is allowed with this scope (including deletion?) That would make it all so much easier, especially for personal projects.
pe...@gmail.com
+1
pa...@gmail.com
I understand the security and privacy challenge Google faces by allowing an additional "god mode" scope. People too easily click yes-yes-accept and Google is likely trying to protect users from themselves. That said, there must be a safe way to achieve what we need. +1
ar...@gmail.com
+1
ag...@gmail.com
Google wont give away their power over our data.
Unless a major power forces them. Meanwhile, look for alternative decent providers.
bi...@gmail.com
+1
sj...@gmail.com
Comment has been deleted.
sj...@gmail.com
I downloaded all my photos via takeout.google.com to browse them more easily. I suppose I could now just delete them in google photos and upload them via my app so I have full control. Seems a bit silly but I guess it would work?
ma...@gmail.com
I got the impression that you don't even need to delete the pictures in Google Photos. As long as your app uploads them, even if they are duplicates, it can put them into albums. Let me know if that is incorrect, though.
mp...@gmail.com
+1
ma...@gmail.com
+1
ha...@gmail.com
+1
th...@gmail.com
+1
de...@gmail.com
I didn't want to manually select 20K+ photos for each year I have so I spent an evening trying to write a API Client to help organize my photos in to yearly albums and then I discover this.
https://github.com/djraval/Gphotos-Album-Creator
Its been over 4 years, but no updates.
Its been over 4 years, but no updates.
sa...@gmail.com
Don't be evil.
Just add a special permission.
I don't even care if it's just available for devs.
so sad this getting entirly ignored :'(
Just add a special permission.
I don't even care if it's just available for devs.
so sad this getting entirly ignored :'(
ha...@gmail.com
I just wanted to organize my own photos, and now I find out about this after writing all the code.
je...@gmail.com
+1 on this one too.
I'm glad I finally found this thread but understand what my issue was.
Less glad to discover that dozens of us are stuck in the same impasse.
That's really too bad.
Any suggestion on a free hosting service that would do what Google Photos does. i.e. organizing albums in a nice fashion, easily searchable, scrollable, etc...?
I'm glad I finally found this thread but understand what my issue was.
Less glad to discover that dozens of us are stuck in the same impasse.
That's really too bad.
Any suggestion on a free hosting service that would do what Google Photos does. i.e. organizing albums in a nice fashion, easily searchable, scrollable, etc...?
Description