Add setting to AppRTCMobile for iOS, that can change capture resolution.

Add setting to AppRTCMobile for iOS, that can change capture resolution.

To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473
Committed: https://crrev.com/d17d536577ad277032baaba19f3bdbd9aa38099d
Cr-Commit-Position: refs/heads/master@{#14881}

[daniela-webrtc, 2016-10-28 12:57:09]

denicija@webrtc.org changed reviewers:
+ magjed@webrtc.org

[magjed_webrtc, 2016-10-31 17:41:43]

Description was changed from

==========
Add setting to AppRTCMobile for iOS, that can change capture resolution.
To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473
==========

to

==========
Add setting to AppRTCMobile for iOS, that can change capture resolution.

To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473
==========

[magjed_webrtc, 2016-10-31 19:26:40]

Overall I think this looks good and very thorough with tests and everything.
It's more code than I expected and more code compared to how we do it on
Android, but I trust your expertise here and that this is the mature way of
implementing it.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/BUILD.gn
File webrtc/examples/BUILD.gn (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/BUILD.gn#newc...
webrtc/examples/BUILD.gn:235:
"objc/AppRTCMobile/ios/ARDSettingsViewController.m",
Shouldn't ARDMediaConstraintsModelTests.mm be added somewhere? How is the test
executed?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ARDAppClient.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ARDAppClient.m:325: -
(void)setDefaultMediaStreamConstraints:(RTCMediaConstraints *)mediaConstraints {
I don't think the word 'default' is appropriate here or in the
defaultMediaStreamConstraints function anymore. How about just
setMediaStreamConstraints? 'MediaStream' is also a bit too generic, maybe
setVideoSourceConstraints or setCameraConstraints instead?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel+Private.h
(right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel+Private.h:19: -
(nullable NSString *)currentVideoResolutionWidthFromStore;
What's the benefit of having this as a string and not an int?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h:39: - (NSString
*)currentVideoResoultionConstraintFromStore;
Wouldn't it be more convenient to represent the resolution as some kind of
struct { int width; int height; } POD?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.m:42: [[self
settingsStore] setVideoResolutionConstraintsSetting:constraint];
Should we verify that |constraint| is one of the
availableVideoResoultionsMediaConstraints here?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsSettingsStore.h
(right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsSettingsStore.h:18: *
It will presist between application launches and application updates.
nit: persist

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:45: -
(NSArray<NSString *> *)mediaConstraintsArray {
should this function be under 'View lifecycle'?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:49: #pragma
mark -
nit: Shouldn't this section have a name?

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:67: // Manully
invoke the delegate method because the previous invocation will not
nit: dot at end of sentence.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:71: #pragma
mark - Dismissall of view controller
nit: dismissal

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:87: #pragma
mark - Tablev view delegate
nit: Table

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:105: -
(UITableViewCell *)tableView:(UITableView *)tableView
The following functions - are they standard boilerplate code for a UITableView?
I don't really understand what they do and why so much code is necessary.

[daniela-webrtc, 2016-11-01 09:51:13]

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/BUILD.gn
File webrtc/examples/BUILD.gn (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/BUILD.gn#newc...
webrtc/examples/BUILD.gn:235:
"objc/AppRTCMobile/ios/ARDSettingsViewController.m",
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> Shouldn't ARDMediaConstraintsModelTests.mm be added somewhere? How is the test
> executed?

You are right. At this moment the test is only added but not executed as we
don't have test target for the demo apps. My plan is to wait on
https://codereview.webrtc.org/2050153003/ to land and then add the test to that
target.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ARDAppClient.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ARDAppClient.m:325: -
(void)setDefaultMediaStreamConstraints:(RTCMediaConstraints *)mediaConstraints {
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> I don't think the word 'default' is appropriate here or in the
> defaultMediaStreamConstraints function anymore. How about just
> setMediaStreamConstraints? 'MediaStream' is also a bit too generic, maybe
> setVideoSourceConstraints or setCameraConstraints instead?

That makes sense. Should we change the `defaultMediaAudioConstraints` as well? I
kinda like the symmetry those method have currently.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel+Private.h
(right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel+Private.h:19: -
(nullable NSString *)currentVideoResolutionWidthFromStore;
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> What's the benefit of having this as a string and not an int?

I've explained the rationale in one of my previous replies. Let me know if it
still doesn't make sense

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h:39: - (NSString
*)currentVideoResoultionConstraintFromStore;
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> Wouldn't it be more convenient to represent the resolution as some kind of
> struct { int width; int height; } POD?

It would make things cleaner for sure.  Sadly, string-int conversions are not
straight forward in ObjC, as oppose to Java for instance.  And it would require
additional helper method and classes to handle the int<->nsstring conversion.
Integers are simple types and they cannot be used for storing in
NSUserDefautlts, they cannot be used in NSDictionary and cannot be used as
DataSource for the Table view either.
That's why I've decided to stick to string representation everywhere.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.m:42: [[self
settingsStore] setVideoResolutionConstraintsSetting:constraint];
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> Should we verify that |constraint| is one of the
> availableVideoResoultionsMediaConstraints here?

Yes! I missed that. Thanks

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsSettingsStore.h
(right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsSettingsStore.h:18: *
It will presist between application launches and application updates.
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> nit: persist

Done.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:45: -
(NSArray<NSString *> *)mediaConstraintsArray {
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> should this function be under 'View lifecycle'?

Done.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:49: #pragma
mark -
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> nit: Shouldn't this section have a name?

Not necessarily. The pragma marks are useful for logical method grouping when
applicable, but they are also nice for visualization when browsing the document
items (ctrl+6) of the class in XCode. The "-" will be displayed as nice
horizontal line and in this case it would separate methods that don't belong
anywhere else :)

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:67: // Manully
invoke the delegate method because the previous invocation will not
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> nit: dot at end of sentence.

Done.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:71: #pragma
mark - Dismissall of view controller
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> nit: dismissal

Done.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:87: #pragma
mark - Tablev view delegate
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> nit: Table

Done.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDSettingsViewController.m:105: -
(UITableViewCell *)tableView:(UITableView *)tableView
On 2016/10/31 19:26:39, magjed_webrtc wrote:
> The following functions - are they standard boilerplate code for a
UITableView?
> I don't really understand what they do and why so much code is necessary.

Standard boiler plate :( And this is the bare minimum to have something shown in
a table view.

[magjed_webrtc, 2016-11-01 12:06:09]

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ARDAppClient.m (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ARDAppClient.m:325: -
(void)setDefaultMediaStreamConstraints:(RTCMediaConstraints *)mediaConstraints {
On 2016/11/01 09:51:12, denicija-webrtc wrote:
> On 2016/10/31 19:26:39, magjed_webrtc wrote:
> > I don't think the word 'default' is appropriate here or in the
> > defaultMediaStreamConstraints function anymore. How about just
> > setMediaStreamConstraints? 'MediaStream' is also a bit too generic, maybe
> > setVideoSourceConstraints or setCameraConstraints instead?
> 
> That makes sense. Should we change the `defaultMediaAudioConstraints` as well?
I
> kinda like the symmetry those method have currently.

I think we should leave the name 'defaultMediaAudioConstraints' for now. My
motivation for this is that 'defaultMediaAudioConstraints' is still a function
providing default values, similar to 'defaultVideoResolutionMediaConstraint' in
ARDMediaConstraintsModel, but this video constraints function does not provide
default values anymore. We can change the name of 'defaultMediaAudioConstraints'
and make it symmetric again once we make a similar CL like this for audio
settings.

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h:39: - (NSString
*)currentVideoResoultionConstraintFromStore;
On 2016/11/01 09:51:12, denicija-webrtc wrote:
> On 2016/10/31 19:26:39, magjed_webrtc wrote:
> > Wouldn't it be more convenient to represent the resolution as some kind of
> > struct { int width; int height; } POD?
> 
> It would make things cleaner for sure.  Sadly, string-int conversions are not
> straight forward in ObjC, as oppose to Java for instance.  And it would
require
> additional helper method and classes to handle the int<->nsstring conversion.
> Integers are simple types and they cannot be used for storing in
> NSUserDefautlts, they cannot be used in NSDictionary and cannot be used as
> DataSource for the Table view either.
> That's why I've decided to stick to string representation everywhere.

I thought we could just do this in ObjC:
someString.integerValue
@(someInt).stringValue
where the types are NSInteger and NSString. I think it would be more convenient
to convert to some int-based format as early as possible, i.e. in the store, so
that we can use ints as much as possible in the rest of the code. When we fill
in the dictionary we convert it back to strings like this:
mediaConstraintsDictionary = @{
  kRTCMediaConstraintsMinWidth : @(widthConstraint).stringValue,
  kRTCMediaConstraintsMinHeight : @(heightConstraint).stringValue
};

https://codereview.webrtc.org/2462623002/diff/20001/webrtc/examples/objc/AppR...
File webrtc/examples/objc/AppRTCMobile/tests/ARDMediaConstraintsModelTests.mm
(right):

https://codereview.webrtc.org/2462623002/diff/20001/webrtc/examples/objc/AppR...
webrtc/examples/objc/AppRTCMobile/tests/ARDMediaConstraintsModelTests.mm:72:
EXPECT_TRUE(result != YES);
nit: Can we do EXPECT_FALSE(result) instead?

[daniela-webrtc, 2016-11-01 14:43:32]

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h:39: - (NSString
*)currentVideoResoultionConstraintFromStore;
On 2016/11/01 12:06:09, magjed_webrtc wrote:
> On 2016/11/01 09:51:12, denicija-webrtc wrote:
> > On 2016/10/31 19:26:39, magjed_webrtc wrote:
> > > Wouldn't it be more convenient to represent the resolution as some kind of
> > > struct { int width; int height; } POD?
> > 
> > It would make things cleaner for sure.  Sadly, string-int conversions are
not
> > straight forward in ObjC, as oppose to Java for instance.  And it would
> require
> > additional helper method and classes to handle the int<->nsstring
conversion.
> > Integers are simple types and they cannot be used for storing in
> > NSUserDefautlts, they cannot be used in NSDictionary and cannot be used as
> > DataSource for the Table view either.
> > That's why I've decided to stick to string representation everywhere.
> 
> I thought we could just do this in ObjC:
> someString.integerValue
> @(someInt).stringValue
> where the types are NSInteger and NSString. I think it would be more
convenient
> to convert to some int-based format as early as possible, i.e. in the store,
so
> that we can use ints as much as possible in the rest of the code. When we fill
> in the dictionary we convert it back to strings like this:
> mediaConstraintsDictionary = @{
>   kRTCMediaConstraintsMinWidth : @(widthConstraint).stringValue,
>   kRTCMediaConstraintsMinHeight : @(heightConstraint).stringValue
> };

Sorry I think I didn't elaborate my thinking well enough previously.
Yes, we can use the NSNumber literal to convert int-NSNumber-NSString. But
that's not the main problem. 
The issue is that the resolution type representation should be serializable, i.e
compatible to be stored to NSUserDefaults (conform to NSCopying protocol). That
means we can
1. Create new class to represent the video resolution. Implement methods of
NSCopying and implement methods for the need of the data source in the settings
view controller (like toString or similar).
2. Use struct representation for the video resolution in  the model. Then we'd
need to have methods (either in the model or the store) to serialize the struct
into a type that can be stored (like NSString or NSDictionary).
Additionally provide some kind of toString class again that would be suitable
for the data source in the settings view controller.

Given the size of the CL I decided to go the simplest route possible (NSString
eeevrywhere) :) Let me know if you think it's worth adding more code to do this
right away.

https://codereview.webrtc.org/2462623002/diff/20001/webrtc/examples/objc/AppR...
File webrtc/examples/objc/AppRTCMobile/tests/ARDMediaConstraintsModelTests.mm
(right):

https://codereview.webrtc.org/2462623002/diff/20001/webrtc/examples/objc/AppR...
webrtc/examples/objc/AppRTCMobile/tests/ARDMediaConstraintsModelTests.mm:72:
EXPECT_TRUE(result != YES);
On 2016/11/01 12:06:09, magjed_webrtc wrote:
> nit: Can we do EXPECT_FALSE(result) instead?

Great catch! That slipped (bad habit of comparing against YES).

[magjed_webrtc, 2016-11-01 17:52:20]

lgtm

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
File webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h (right):

https://codereview.webrtc.org/2462623002/diff/1/webrtc/examples/objc/AppRTCMo...
webrtc/examples/objc/AppRTCMobile/ios/ARDMediaConstraintsModel.h:39: - (NSString
*)currentVideoResoultionConstraintFromStore;
On 2016/11/01 14:43:32, denicija-webrtc wrote:
> On 2016/11/01 12:06:09, magjed_webrtc wrote:
> > On 2016/11/01 09:51:12, denicija-webrtc wrote:
> > > On 2016/10/31 19:26:39, magjed_webrtc wrote:
> > > > Wouldn't it be more convenient to represent the resolution as some kind
of
> > > > struct { int width; int height; } POD?
> > > 
> > > It would make things cleaner for sure.  Sadly, string-int conversions are
> not
> > > straight forward in ObjC, as oppose to Java for instance.  And it would
> > require
> > > additional helper method and classes to handle the int<->nsstring
> conversion.
> > > Integers are simple types and they cannot be used for storing in
> > > NSUserDefautlts, they cannot be used in NSDictionary and cannot be used as
> > > DataSource for the Table view either.
> > > That's why I've decided to stick to string representation everywhere.
> > 
> > I thought we could just do this in ObjC:
> > someString.integerValue
> > @(someInt).stringValue
> > where the types are NSInteger and NSString. I think it would be more
> convenient
> > to convert to some int-based format as early as possible, i.e. in the store,
> so
> > that we can use ints as much as possible in the rest of the code. When we
fill
> > in the dictionary we convert it back to strings like this:
> > mediaConstraintsDictionary = @{
> >   kRTCMediaConstraintsMinWidth : @(widthConstraint).stringValue,
> >   kRTCMediaConstraintsMinHeight : @(heightConstraint).stringValue
> > };
> 
> Sorry I think I didn't elaborate my thinking well enough previously.
> Yes, we can use the NSNumber literal to convert int-NSNumber-NSString. But
> that's not the main problem. 
> The issue is that the resolution type representation should be serializable,
i.e
> compatible to be stored to NSUserDefaults (conform to NSCopying protocol).
That
> means we can
> 1. Create new class to represent the video resolution. Implement methods of
> NSCopying and implement methods for the need of the data source in the
settings
> view controller (like toString or similar).
> 2. Use struct representation for the video resolution in  the model. Then we'd
> need to have methods (either in the model or the store) to serialize the
struct
> into a type that can be stored (like NSString or NSDictionary).
> Additionally provide some kind of toString class again that would be suitable
> for the data source in the settings view controller.
> 
> Given the size of the CL I decided to go the simplest route possible (NSString
> eeevrywhere) :) Let me know if you think it's worth adding more code to do
this
> right away.

Alright, let's keep it as strings for now if you think that's simpler. I don't
know ObjC well enough to know how much boilerplate it will require to add a
resolution class with NSCopying and toString. I was hoping a resolution class
would simplify the code since we could then remove e.g.
currentVideoResolutionWidthFromStore/currentVideoResolutionHeighFromStore/videoResolutionComponentAtIndex
that already do string parsing. I think we might need a resolution class in the
future anyway when we refactor AVFoundationVideoCapturer so that we can
enumerate the available formats properly in
availableVideoResoultionsMediaConstraints.

[daniela-webrtc, 2016-11-02 09:32:36]

The CQ bit was checked by denicija@webrtc.org

[commit-bot: I haz the power, 2016-11-02 09:32:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-11-02 09:56:12]

Description was changed from

==========
Add setting to AppRTCMobile for iOS, that can change capture resolution.

To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473
==========

to

==========
Add setting to AppRTCMobile for iOS, that can change capture resolution.

To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473
==========

[commit-bot: I haz the power, 2016-11-02 09:56:13]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-11-02 09:56:19]

Description was changed from

==========
Add setting to AppRTCMobile for iOS, that can change capture resolution.

To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473
==========

to

==========
Add setting to AppRTCMobile for iOS, that can change capture resolution.

To achieve this, several changes needed to be made on both UI and
app logic level.
* Settings view controller is added (modally shown when the settings
button is pressed).
	- From there the user can see the current capture resolution
and select another capture resolution.
* Model class for the capture resolution added.
	- Improves readability and makes separation of concerns cleaner
	- Handles persisting
	- Provides defaults
	- Maps video resolution setting to RTCMediaConstraints dictionary
* Test for the model class

In future it would be possible to extend this CL and add further settings (i.e
bit rate).
Also it would be easy to remove the hardcoded resolutions and use dynamic values
depending on device capability.

BUG=webrtc:6473

Committed: https://crrev.com/d17d536577ad277032baaba19f3bdbd9aa38099d
Cr-Commit-Position: refs/heads/master@{#14881}
==========

[commit-bot: I haz the power, 2016-11-02 09:56:20]

Patchset 3 (id:??) landed as
https://crrev.com/d17d536577ad277032baaba19f3bdbd9aa38099d
Cr-Commit-Position: refs/heads/master@{#14881}