Silverlight 4... Which one should I use, ObservableCollection<T> or should I implement my own :
public class Moo : List<MyObject> , INotifyCollectionChanged { }
?
I'm confused.
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Silverlight 4... Which one should I use, ObservableCollection<T> or should I implement my own :
public class Moo : List<MyObject> , INotifyCollectionChanged { }
?
I'm confused.
ObservableCollection<T> is the default implementation, ie: wouldn't it be a bit strange to create the interface INotifyCollectionChanged and not have a default implementation?
Also, you would implement 'Moo' in your case as a Collection<T> not List<T>.
I believe ObservableCollection<T> also supports property change notifications as well.
stevo_ said:ObservableCollection<T> is the default implementation, ie: wouldn't it be a bit strange to create the interface INotifyCollectionChanged and not have a default implementation?
Also, you would implement 'Moo' in your case as a Collection<T> not List<T>.
I believe ObservableCollection<T> also supports property change notifications as well.
Hmmmmmmmmmmmm, I used List<T> and could make INotifyCollectionChanged to work. Maybe that's why. I'll switch to Collection<T> and see if goes better this time.
I tried to change the text of stuff in the ObservableCollection<T> but if they did not implement INotifyPropertyChanged, the change didn't show up, so I think it only supports ADD REMOVE RESET or something.
So basically, I'm good to go using ObservableCollection<T> instead of creating stuff with INotifyCollectionChanged all the time, correct?
Thanks.
turrican said:stevo_ said:*snip*Hmmmmmmmmmmmm, I used List<T> and could make INotifyCollectionChanged to work. Maybe that's why. I'll switch to Collection<T> and see if goes better this time.
I tried to change the text of stuff in the ObservableCollection<T> but if they did not implement INotifyPropertyChanged, the change didn't show up, so I think it only supports ADD REMOVE RESET or something.
So basically, I'm good to go using ObservableCollection<T> instead of creating stuff with INotifyCollectionChanged all the time, correct?
Thanks.
I think you need to look up the work Observable in a dictionary. If you use an ObservableCollection and your type has properties that impletent a propertychanged event then this will work.
You should never use a List<T> in databinding scenarios.
In .NET should I use List<T> or implement my own IList<T>? If you can answer that one, you can answer your own question. I can tell you that given your post, none of us can answer your question.
What are your requirements? What will the collection be used for? Will you be doing more inserts than lookups? Will you be doing random access? What about removing items, how often will you do that? Will you be removing random items, or only the front/back item? I could go on, but I think you get the idea.
If ObservableCollection<T> has the performance characteristics you need for the way you're going to use the collection, or at least it is "good enough", then use it. If it's not, then that's why INotifyCollectionChanged exists. Implement your own. I will say that it's probably wrong to implement your own by deriving from an existing collection type, however. Often you won't be able to correctly implement your collection doing that, as the base type doesn't provide the necessary hooks to modify the behavior. Instead, just create your own based on ICollection<T> or IList<T> and implement it by deferring to a member of the existing collection type that has the characteristics you want.
wkempf said:In .NET should I use List<T> or implement my own IList<T>? If you can answer that one, you can answer your own question. I can tell you that given your post, none of us can answer your question.
What are your requirements? What will the collection be used for? Will you be doing more inserts than lookups? Will you be doing random access? What about removing items, how often will you do that? Will you be removing random items, or only the front/back item? I could go on, but I think you get the idea.
If ObservableCollection<T> has the performance characteristics you need for the way you're going to use the collection, or at least it is "good enough", then use it. If it's not, then that's why INotifyCollectionChanged exists. Implement your own. I will say that it's probably wrong to implement your own by deriving from an existing collection type, however. Often you won't be able to correctly implement your collection doing that, as the base type doesn't provide the necessary hooks to modify the behavior. Instead, just create your own based on ICollection<T> or IList<T> and implement it by deferring to a member of the existing collection type that has the characteristics you want.
"In .NET should I use List<T> or implement my own IList<T>? If you can answer that one, you can answer your own question."
Excellent, thank you very much! Now I see it more clearly. I will use ObservableCollection<T>.
![]()
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.