use system photo picker instead of UIImagePickerController

[michaelkirk]

This is kind of a meta story that solves: #13 #96 #101 #123

I'm going to revisit using the built in UIImagePickerController to take the photo - essentiall replacing much of the home-baked CameraViewController.

There are just so many features we get for free, that I think it outweighs the downside of the inconsistent application UX.

Plus, I think there's work that can be done to get the system picker to fit in better.

• [ ] make it obvious why a guess requires a photo
• [ ] instruct user to include their bike in the photo
• [ ] make photo controller look like other screens (transparent bottom bar, nav bar, etc. Not sure if this is possible nor essential, but nice to have)

If it's not possible to solve the "make it obvious why a guess requires a photo" and " instruct user to include their bike in the photo" by overlaying them on the photo controller, other approaches include:

1. a (one-time ?) intermediate screen before the photo-picker explaining whats happening and why
2. a (one-time ?) pop-over with the same instructions

[svevang]

Could the one-time pop-up be decomposed into a separate task? That would be a fun one.

[michaelkirk]

@svevang - I'm hoping to not have to implement the one-time pop up at all.

The context is that currently the cameraview has a header that says "Take a photo to prove it" and a line that says "remember to include your bike".

With the default system photo picker we lose those. Ideally those things would be integrated into the system photo picker. Only if that's not feasible would I want to implement them in a separate pop-up.

[michaelkirk]

I've spent some agonizing hours days trying to get the system photo picker to work, but I'm not able to get the right flow.

Approaches:

1. Launch the photo picker as a modal on top of the existing CameraView controller, this leads to a sort of double pop-up effect. And then when you cancel the photo picker you're back at the (blank) camera view subclass. Not ideal. We could hack the "dismiss" camera view controller" to pop you back an extra view controller.
2. Where do we put the "don't forget to include your bike"? It's possible to have our own controls overlayed, but they obscure the essential camera controls, or more of the image
3. Tried to make the CameraView subclasses inherit from the ImagePicker doesn't allow us to ineherit from our application controller, so we'd have to move our (e.g.) fake API configuration
4. Tried embedding a photopicker in a container view inside the camera controller subclasses, but the photopicker has it's own nav bar, and also was unable to render custom controls on top of the photo picker. Somehow the photopicker would be rendred beneth my nav bar, but over top of my controls.

All of this is to say that maybe it's possible to use the photo picker, but it entails quite a bit of work, and I still think the native UI is unfortunate in terms of "app flow".

So, I'm going back to implementing these features piecemeal. I have mixed feelings about this, essentially on "re-inventing the wheel" grounds. People already know how to use the native ios camera interface and it alread works. But, c'est la vie. Knocking these features of piecemeal actually lets me release something. (I'm pushing up some touch to focus code in a minute #96)

[michaelkirk]

Closing this, and pursuing individual fixes.