Fix iossim's support for retina devices.

Fix iossim's support for retina devices.

Mac 10.8 started caching prefs so even though iossim writes the SimulatorDevice
value to the .plist on disk, the iPhone Simulator may not see that change and
therefore not respect the -d (device) parameter passed to iossim.

Using the CFPreferences API to set and sync the pref fixes the issue.  

BUG=224892
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=194939

[TVL, 2013-04-16 20:05:45]

https://codereview.chromium.org/14308003/diff/1/testing/iossim/iossim.mm
File testing/iossim/iossim.mm (right):

https://codereview.chromium.org/14308003/diff/1/testing/iossim/iossim.mm#newc...
testing/iossim/iossim.mm:495: // for this setting to take effect.
duplicate comment?

https://codereview.chromium.org/14308003/diff/1/testing/iossim/iossim.mm#newc...
testing/iossim/iossim.mm:583: simHomePath = [[NSFileManager defaultManager]
is it even worth having this option any more and trying to create a directory?

[lliabraa, 2013-04-17 13:15:37]

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim.mm
File testing/iossim/iossim.mm (right):

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim....
testing/iossim/iossim.mm:495: // for this setting to take effect.
On 2013/04/16 20:05:45, TVL wrote:
> duplicate comment?

Done.

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim....
testing/iossim/iossim.mm:583: simHomePath = [[NSFileManager defaultManager]
On 2013/04/16 20:05:45, TVL wrote:
> is it even worth having this option any more and trying to create a directory?

Can you remind me what the issue is here? It seems to be working as intended
(i.e. using the -u value as the sandbox dir of the app:

$ rm -rf /tmp/iossim_home
$ xcodebuild/ninja-iossim/Debug/iossim -d "iPhone" -u /tmp/iossim_home/
xcodebuild/Debug-iphonesimulator/sql_unittests.app/
<output clipped>
$ ls /tmp/iossim_home/
Documents	Library

[TVL, 2013-04-17 13:42:04]

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim.mm
File testing/iossim/iossim.mm (right):

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim....
testing/iossim/iossim.mm:495: // for this setting to take effect.
On 2013/04/17 13:15:37, Lane LiaBraaten wrote:
> On 2013/04/16 20:05:45, TVL wrote:
> > duplicate comment?
> 
> Done.

New upload?

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim....
testing/iossim/iossim.mm:583: simHomePath = [[NSFileManager defaultManager]
On 2013/04/17 13:15:37, Lane LiaBraaten wrote:
> On 2013/04/16 20:05:45, TVL wrote:
> > is it even worth having this option any more and trying to create a
directory?
> 
> Can you remind me what the issue is here? It seems to be working as intended
> (i.e. using the -u value as the sandbox dir of the app:
> 
> $ rm -rf /tmp/iossim_home
> $ xcodebuild/ninja-iossim/Debug/iossim -d "iPhone" -u /tmp/iossim_home/
> xcodebuild/Debug-iphonesimulator/sql_unittests.app/
> <output clipped>
> $ ls /tmp/iossim_home/
> Documents	Library


So the problem is what defaults the app (and simulator) actually get.  Since the
defaults daemon is caching things; it if has already loaded values it doesn't
reload new (empty) values based on this directory tree.  So the apps get the
values from the last run.  That's why our directly touching the file for the
simulator no longer works.  If the daemon hadn't loaded the simulator values it
worked; but once it had loaded them, any future runs didn't see the values we
wrote in the new files.

I guess we can leave it as is, because the simulator setting was the one most
breaking things, but any app that writes something to defaults and matching data
on disk might run into a mismatch now.

[lliabraa, 2013-04-17 16:52:03]

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim.mm
File testing/iossim/iossim.mm (right):

https://chromiumcodereview.appspot.com/14308003/diff/1/testing/iossim/iossim....
testing/iossim/iossim.mm:583: simHomePath = [[NSFileManager defaultManager]
On 2013/04/17 13:42:04, TVL wrote:
> On 2013/04/17 13:15:37, Lane LiaBraaten wrote:
> > On 2013/04/16 20:05:45, TVL wrote:
> > > is it even worth having this option any more and trying to create a
> directory?
> > 
> > Can you remind me what the issue is here? It seems to be working as intended
> > (i.e. using the -u value as the sandbox dir of the app:
> > 
> > $ rm -rf /tmp/iossim_home
> > $ xcodebuild/ninja-iossim/Debug/iossim -d "iPhone" -u /tmp/iossim_home/
> > xcodebuild/Debug-iphonesimulator/sql_unittests.app/
> > <output clipped>
> > $ ls /tmp/iossim_home/
> > Documents	Library
> 
> 
> So the problem is what defaults the app (and simulator) actually get.  Since
the
> defaults daemon is caching things; it if has already loaded values it doesn't
> reload new (empty) values based on this directory tree.  So the apps get the
> values from the last run.  That's why our directly touching the file for the
> simulator no longer works.  If the daemon hadn't loaded the simulator values
it
> worked; but once it had loaded them, any future runs didn't see the values we
> wrote in the new files.
> 
> I guess we can leave it as is, because the simulator setting was the one most
> breaking things, but any app that writes something to defaults and matching
data
> on disk might run into a mismatch now.

I see. So if we were to set up a dir for the simulator to use as it's home
directory, and put some .plist files in there, iossim wouldn't necessarily use
the because of the caching issue.

If that's the case, seems like the script that sets up the home dir and plist
files should be responsible for syncing them (i.e. CFPreferencesAppSynchronize).

If that's not the case, and I'm still not understanding, an example would help.

[TVL, 2013-04-17 17:03:59]

lgtm

[commit-bot: I haz the power, 2013-04-18 11:03:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/lliabraa@chromium.org/14308003/5001

[commit-bot: I haz the power, 2013-04-18 13:41:15]

Retried try job too often on win_rel for step(s) content_browsertests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-04-18 13:46:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/lliabraa@chromium.org/14308003/5001

[commit-bot: I haz the power, 2013-04-18 16:18:09]

Change committed as 194939