Bug 15830 - MonoTouch.UIKit.UICollectionView.DequeueReusableCell should not return an NSObject
Summary: MonoTouch.UIKit.UICollectionView.DequeueReusableCell should not return an NSO...
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 7.0.3.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: 7.0.6
Assignee: Sebastien Pouliot
: 18270 ()
Depends on:
Reported: 2013-10-30 15:35 UTC by Alan Pogrebinschi
Modified: 2014-03-11 13:44 UTC (History)
5 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 Alan Pogrebinschi 2013-10-30 15:35:11 UTC
MonoTouch.UIKit.UICollectionView.DequeueReusableCell returns an NSObject, but:

- Xamarin docs say that it returns a UICollectionReusableView, and

- It is a binding of dequeueReusableCellWithReuseIdentifier:forIndexPath, which returns a UICollectionViewCell.

I would then expect it to return one of the types above and/or the documentation to be fixed (I'd prefer the former).

(by the way, similar method for tables, UITableView.DequeueReusableCell, returns a UITableViewCell)
Comment 1 Sebastien Pouliot 2013-10-30 21:56:09 UTC
Apple header file (and part of the documentation, e.g. the signature) shows it returns `(id)` which can be any NSObject. However it is later documented to be an `UICollectionReusableView` (sadly that was not reflected in the bindings).

OTOH changing the return type of a (public) method is a breaking change, i.e. any binary assembly (e.g. components) with a reference to this method would break if we change the definition.

note: `dequeueReusableSupplementaryViewOfKind:withReuseIdentifier:forIndexPath:` has the same issue.

I'll add comments in the bindings so if we ever need to break binary compatibility we can revisit that decision.
Comment 2 Alan Pogrebinschi 2013-10-31 08:45:50 UTC
Then it would be good to update Xamarin.iOS docs[1] so that it doesn't say it returns `UICollectionReusableView`. 

[1]: http://docs.go-mono.com/?link=M%3aMonoTouch.UIKit.UICollectionView.DequeueReusableCell
Comment 3 Sebastien Pouliot 2013-11-01 09:09:27 UTC
comment added in e761c97a62ad1963cdc01d643c266728fe929e68

I'm not sure about the documentation as it's really a `UICollectionReusableView` that's being returned (even if the signature is a base class of it). IMO changing this to `NSObject` would be more confusing since that information will be totally lost (not in the signature, neither in the docs).

It's a bit like a method that return a List when the signature specify an IList (it's still useful to know what's actually returned).

c.c. Larry as he might have some better idea on how to document this.
Comment 4 PJ 2013-12-11 18:46:02 UTC
This fix is planned to be released with Xamarin.iOS 7.0.6, which should hit the beta channel before December 23rd.
Comment 5 Sadik Ali 2013-12-18 10:39:08 UTC
I have verified this issue and found that "NSOBject" return type of "MonoTouch.UIKit.UICollectionView.DequeueReusableCell" is mentioned in both Doc and monotouch assembly.
Refer Screenshot: "http://screencast.com/t/YFkrhKxsl"

Checked With:

MAC: MT 10.8.4
XS: 4.2.3 build(20)
X iOS:
Comment 6 Rolf Bjarne Kvinge [MSFT] 2014-03-11 13:44:29 UTC
*** Bug 18270 has been marked as a duplicate of this bug. ***