Bug 13894 - Make generated IBOutlet fields public
Summary: Make generated IBOutlet fields public
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: 4.0.12
Hardware: All All
: --- normal
Target Milestone: master
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2013-08-09 15:15 UTC by Erik Kerber
Modified: 2013-08-09 17:15 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Erik Kerber 2013-08-09 15:15:50 UTC
Reference: http://stackoverflow.com/questions/18147688/what-is-the-reason-for-iboutlets-being-private-in-xamarin-ios

Generated properties for IBOutlets should be public, to mimic typical patterns used in Objective-C development.  

The best example being UITableViewCells, where UIViewControllers and DataSources are usually responsible for populating UITableViewCells IBOutlet properties, not the cell itself.
Comment 1 Mikayla Hutchinson [MSFT] 2013-08-09 16:43:38 UTC
The reason for this is explained by http://stackoverflow.com/questions/18147688/what-is-the-reason-for-iboutlets-being-private-in-xamarin-ios/18154631?noredirect=1#comment26592866_18154631

In summary: the fact they're properties is an implementation detail, think of them as private fields. You can opt into exposing them via properties, like you do with private fields in C#. If they were all public, you would have no choice whether to expose them or not, breaking encapuslation.

Admittedly, it would be nice if the "create read-only property" context action would operate on [Outlet] properties like it does on fields. Maybe we could add some context actions like that into the iOS addin.
Comment 2 Jeffrey Stedfast 2013-08-09 17:15:46 UTC
What I've done is to make it such that if a user modifies the *.designer.cs file by hand and adds public, protected, internal, or protected internal access modifiers on an Outlet property, then they should get preserved in future syncs from Xcode.

However, if the accessibility is ever changed to anything other than private, the setter will be updated to be marked as private in the next sync from Xcode (this is mostly for your own safety).

Hopefully that will suffice for now.