Default to "large" version of photo (instead of "Actual Size") when uploaded from camera roll?

[benhalpern]

Is your feature request related to a problem? Please describe. "Actual size" is usually quite big, and I think the "Large" size of a photo is almost always good enough...

Describe the solution you'd like The default in this process is "Large". I presume the user could still open this dialog and switch to "Actual size" if necessary.

Describe alternatives you've considered I imagine there are other approaches to ensuring downsizing happens locally vs uploading the whole thing... Or maybe there is a more fleshed out photo taking and library selection library we might be able to trigger via native bridge vs the wkwebview defaults we currently use.

Some libraries I came across in a quick search...

https://github.com/1amageek/Sumo https://github.com/longitachi/ZLPhotoBrowser

(One strictly for compression, the other more of a full-on UI)

Additional context All in all I think getting photos more of a first class citizen will help the more non-DEV versions of our product.

[fdocr]

It definitely feels like an interesting opportunity to consider using the native bridge. This way we have a bit more customization capabilities to make sure it's sleek and efficient. I'll definitely check out the libraries suggested.

However, if there's an easy way to configure the downsizing I think we're better off with less surface area to maintain. It would also reduces the risk of dependency bloat in the long run.

I'll do a bit more research and get back to this soon.

[benhalpern]

Yeah, I think we'll want the native bridge one way or another especially if we can pluck good solutions for the time being here. There are so many apps with camera functionality that I have to think we could get something going pretty quickly as long as we can figure out how the bridge to that solution would work. Maybe the solution is one of the two I mentioned here, but maybe there's something else.

[fdocr]

Update on the progress so far:

The current PRs in progress are using the native bridge to trigger the image picker. I'm now sorting out the upload step of this feature but there's a few different approaches, each with their pros and cons. Here's a diagram for clarity:

In all three of them we trigger a native image picker. Once the image has been selected we process it (downscale if the image is too big) and then we have three options:

Option A

Make the upload directly from the native side using a library. Right now I think Alamofire is the most robust option for this because the originally suggested Sumo library doesn't have a lot of docs and hasn't had activity for a while.

Option B

Still make the upload directly from the native side but without using a library. My biggest concern compared with option A is that we're adding too much bloat in our Framework by adding more dependencies, which means that apps consuming our Framework will get that bloat.

It's just one HTTP request to upload an image, we should be able to rely on the existing APIs to achieve this.

Option C

Pass the image encoded in base64 into the JS context, then re-create a File object and use the exact same logic to upload as the web implementation would originally use. This would save us a lot of hassle (i.e. lines of code and/or dependencies), making it easier to maintain because we would rely on the web frontend implementation.

---

What's coming next:

From the experiments I ran so far option C seems to have problems handling a multi-megabyte (1MB~10MB) image. There's a bottleneck somewhere in the underlying native bridge technology (native bridge throughput, WKWebView performance, other?). I wish this wasn't the case because it was my preferred option 😕

For the sake of simplicity I'll probably continue focusing on option A over option B, because the image upload task isn't trivial. Also we have some tricky configs in the way we handle the image upload process that may take me longer to solve in option B.

Hopefully as soon as I'm able to get everything working with option A I'll make sure to open an issue for optimization, because I personally consider dependency bloat a very serious problem and the easiest slippery slope to fall for.