Apr 6 | 3:50 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Apr 6 | 4:25 PM |
Randy | has entered the room |
Mark M. |
hello, Randy!
|
Mark M. |
how can I help you today?
|
Randy |
View paste
|
Mark M. |
IMHO, it depends on whether you want to consider this operation to be "linking images to the post" or "attaching images to the post"
|
Apr 6 | 4:30 PM |
Mark M. |
"linking" implies that the post is somewhat decoupled from the image, and so if the image gets deleted or moved, and your Uri is no longer valid, the user will not be horrified
|
Mark M. |
"attaching" (or "importing") implies that the image is truly a part of the post, and therefore should still work even if the selected image is moved or deleted
|
Mark M. |
in the latter case, make a copy
|
Mark M. |
in the former ("linking") case, persisting the Uri should be OK
|
Mark M. |
or, give the user the option of which to do
|
Randy |
That makes sense. Do you see a problem copying too many images for a single app though?
|
Mark M. |
well, it consumes extra storage space, which isn't great if the images in question are photos (and therefore typically not small)
|
Mark M. |
if you think you can nail the UX, offering the choice also helps to educate the user about the storage space issue
|
Randy |
That's kind of what I was thinking. As long as I have good messaging about the limitations of an offline app, hopefully that will be fine. I can then think about adding a back end service later.
|
Apr 6 | 4:35 PM |
Mark M. |
if you are implying that eventually you will upload the images to a server, that basically consolidates the choices, as everything turns into making a copy, just a remote one
|
Randy |
If I had a list of all the URIs, couldn't I fetch them at the time of back up?
|
Randy |
At least the ones that haven't been moved/deleted
|
Mark M. |
yes -- once you introduce a server, though, the question becomes: what is the system of record
|
Mark M. |
your use of "back up" suggests that the device is still the system of record, in which case the linking/attaching distinction remains
|
Mark M. |
in many other cases, the server becomes the system of record, in which case your app has a cache of some images and downloads them from the server as needed
|
Apr 6 | 4:40 PM |
Randy |
That actually leads into the syncing question which I haven't found a good answer for. The recommended Android Architecture seems to hint that you should always read the images from the Room DB. I get that the server can still be the source of truth and just asynchronously update the local DB when the data comes in. Where it gets fuzzy is how you keep the two in sync if the user is using the app when offline.
|
Mark M. |
that gets tricky and is really app-dependent
|
Mark M. |
for example, if the user has ways of manipulating the server-side data by other means (e.g., Web app), then things get seriously complicated
|
Randy |
Okay, that's what I figured. Wanted to make sure I wasn't overlooking a simple solution.
|
Apr 6 | 4:45 PM |
Randy |
Thanks, Mark. I might drop-in to another office hours in the future when I get deeper into this work.
|
Apr 6 | 4:50 PM |
Mark M. |
sounds good!
|
Apr 6 | 5:00 PM |
Mark M. |
that's a wrap for today's chat
|
Mark M. |
the transcript will be posted to https://commonsware.com/office-hours/ shortly
|
Mark M. |
the next chat is Tuesday at 7:30pm US Eastern
|
Mark M. |
have a pleasant day!
|
Randy | has left the room |
Mark M. | turned off guest access |