Include GPS metadata in photo download. [142012075]

Duplicate

of 80379228

Bug

Status Update

No update yet.

Description

ra...@gmail.com

created issue #1

Oct 3, 2019 04:11AM

A short description of the issue:
When downloading a photo through the API my GPS location that the phone put into the original photo is removed. I expect the original GPS location to be there. Why would that be stripped?

Background:
I pay and backup my photos to Google Photos, which is great. I do not believe my photos should be stored *only* in 1 place, loosing them would be a disaster. I download and backup my photos to another location as well. I used to do that though the automatic Google Drive sync which is now deprecated. Downloading new photos through the API seems the easy solution but *not* when the original GPS location is stripped. I have currently no way to backup my photos with GPS metadata from Google Photos!

Comments

ra...@gmail.com <ra...@gmail.com> #2Oct 3, 2019 04:13AM

Is this fixed ?

I tried this with same Compose version but new AS (2021.1.1 Beta 4), it does not recompose Child2

pa...@gmail.com <pa...@gmail.com> #3Oct 6, 2019 07:45AM

Still no update on this? This seems to be a major deficiency of a core concept to me. I ran into the same issue, although my list's state holder is a viewmodel.

ra...@gmail.com <ra...@gmail.com> #4Oct 6, 2019 08:05AM

Lists in Kotlin are not (yet) truly immutable. They're regular Java lists behind the scenes and can be mutated by casting to a Mutable list. Could that be the reason why?

dl...@google.com <dl...@google.com> #5Oct 14, 2019 11:37PM

Status: Duplicate of

80379228

A List<T> is not inferred as immutable because, for example, mutableListOf<T>() is also a List<T>. List<T> restricts the receiver from modifying the list (e.g. it is read-only) but does not imply the list is immutable as it can change at any time through a MutableList<T> typed reference.

Even though this is working as intended, I am keeping this issue open as we need to provide a solution here as using a List<T> as meaning an immutable list is a common pattern.

an...@gmail.com <an...@gmail.com> #6Jan 19, 2020 08:12PM

I tried to annotate a fun with @Stable but apparently it had no effect on the list parameter. Is this expected?

For me it was unexpected, as I thought I could force the compiler to just accept that it's stable.

j....@gmail.com <j....@gmail.com> #7Sep 10, 2022 11:11AM

Marking fun as stable does not mark it's parameters as stable. For possible workaround you can check the article from Chris Banes here: https://chris.banes.dev/composable-metrics/

I do agree that it would be nice if we could directly mark composable fun's parameters as stable, but the @Stable annotation can only be applied to classes and functions for now. It would be a good workaround for types from outside our module (external library for example). Compose cannot infer their stability and we have to do this tedious stable holders for those. Marking fun parameter as stable directly would be much simpler

ni...@gmail.com <ni...@gmail.com> #8Nov 26, 2022 03:01PM

I'm closing this issue as working as intended. We cannot mark List<T> as stable since it has no such guarantees (unfortunately). Please keep in mind that "i'm not allowed to write to this object" is not the same as "this object will not change".

It is likely that we will end up skipping simple cases like in your example above where we can analyze back to the variable initializer where the value is using listOf, however we will not in general skip a function parameterized with List<T>.

j....@gmail.com <j....@gmail.com> #9Jan 23, 2024 12:19PM

I imagine Google could assist in "stabilizing" Jetbrains' ImmutableList/PersistableList design and then treat those as @Stable.

For the time being it's straightforward to extend Jetbrains' API to create your own StableImmutableList and use that in your code pervasively, if you're able to put up with pre-release status.