Is it necessary to use Grouping class for long list selector? In my application i am using a simple list control for holding a large amount of data. Now i feel some performance issues (memory and loading) issues with the ordinary list. So i decided to change my list to long list selector. My doubt is that is it possible to use same Item template and item source for implementing long list. In an example i found a grouping class. Does this grouping is necessary?? If no is the answer how i can implement this with my existing data. Thanks in advance .
You do need to group your data by some type of field, so you'll have a list of groups, and inside each group, the list of items for that group!
I think this is one of the best articles that explains how the LongListSelector should be used!
If you don't need group data, just set: IsFlatList = true
Related
I'm struggling to understand how to use UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot to model change of items.
Let's say I have a simple item which looks like this:
struct Item {
var id: Int
var name: String
}
Based on the names of the generic parameters, UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot should operate not with Item itself, but only with identifier, which Int in this example.
On the other hand, again based on names of generic parameters, UICollectionView.CellRegistration should operate on complete Item's. So my guess is that UICollectionViewDiffableDataSource.CellProvider is responsible for finding complete Item's by id. Which is unfortunate, because then aside from snapshots, I need to maintain a separate storage of items. And there is a risk that this storage may go out of sync with snapshots.
But it is still not clear to me how do I inform UICollectionViewDiffableDataSource that some item changed its name without changing its id. I want UICollectionView to update the relevant cell and animate change in content size, but I don't want insertion or removal animation.
There are two approaches that would work solve your problem in this scenario.
The first is to conform your Item model to the hashable protocol. This would allow you to use the entire model as an identifier, and the cell provider closure would pass you an object of type Item. UICollectionViewDiffableDataSource would use the hash value for each instance of your model (which would consider both the id and name properties, thereby solving your name changing issue) to identify the data for a cell. This is better than trying to trick the collection view data source into considering only the id as the identifier because, as you stated, other aspects of the model might change. The whole point of structs is to act as a value-type, where the composition of all the model's properties determine its 'value'...no need to trick the collection view data source into looking only at Item.id.
Do as you said, and create a separate dictionary in which you can retrieve the Items based on their id's. While it is slightly more work to maintain a dictionary, it is a fairly trivial difference in terms of lines of code. All you should do is dump and recalculate the dictionary every time you apply a new snapshot. In this case, to update a cell when the model changes, make sure to swap out the model in your dictionary and call reloadItem on your snapshot.
While the second option is generally my preferred choice because the point of diffable data source is to allow for the handling of massive data sets by only concerning the data source with a simple identifier for each item, in this case your model is so simple that there's really no concern about wasted compute time calculating hash values, etc. If you think your model is likely to grow over time, I would probably go with the dictionary approach.
I'm attempting the Bucket List Design challenge here:
https://github.com/near-examples/workshop--exploring-assemblyscript-contracts
In the notes it says there is one model Activity, and this should include a PersistentVector for a list of friends.
My activities are stored as a PersistentVector, so this would mean a nested PersistentVector with the Activity model - it seems this would not be possible. Am I missing something, or is this maybe designed to create a bit of thinking?
It’s certainly possible to have a PersistentVector<Activity>, and inside each activity have a PersistentVector<string> with friends. However, using this datastructure, I think you end up with a shared list of friends for all activites (unless you use a unique prefix). If you use PersistentVector for your activities, then it’s possible to use a regular list (string[]) for your friends to isolate it inside one activity. Otherwise, you would need to store the PersistentVector of friends using the id of your activity (maybe as the unique prefix like below)
friends: PersistentVector<string> = new PersistentVector<string>(uniqueIdOfActivity);
I haven’t tested my hypothesis yet, but as far as I understand, a PersistentVector is just a helper to use the storage
In Windows Phone a ListBox support the virtualization of the data, that means it can only load the data needed and not everything. Peter Torr explains the interface you need to implement.
The short version is that you have to create both a method that return the position of an element and another one that return the element in a specific position. The problem is that the example of Peter Torr is rather dumb, he just return an object with the index as a name.
My question is: how do you actually implement this ?
My idea is to create one file that contains a list of an (integer) index and an (integer) id and a file for every object that contains the actual data. It doesn't seem a really elegant idea, but I can't think of anything better, can you ?
UPDATE
It seems that my question is inaccurate. When I say that the example of Peter Torr is "rather dumb" I am not saying that he has done anything wrong; his objective was simply to explain what interface you need to implement. The practical implementation will depend on the specific data.
What I am asking is what choices do I have to implement this ? Should I simply put the data on a web service and query it every time (with a local cache, of course), build a database, create a file the store the indexes and one for the data ? Is there a solution good enough in every case ? What are the downsides and upsides of every choice ?
The article you linked to includes a link to a downloadable project which demonstrates how to implement this.
What more are you after? The general idea is that the ListBox will call into your IList when it needs data. it will ask for an item at a specific index and you pass back an object. it then, presumably, calls ToString() on that object and displays the result in the list.
What that actual object is and where you pull it from is completely up to you. You might be using a really large array in memory. You might be pulling from IsolatedStorage or a web service. You could certainly use it to pull file info, but I don't suspect anyone has a ready-built IList implementation so that's the part that you will have to implement based on your specific project.
Using the Enterprise Library 4.1 Validation Application Block, how can I validate that a collection property contains at least one item?
I'm assuming you mean out of the box. If so, then I don't think there is way to validate directly the number of items in a collection.
These are some other ways that you could try:
Decree that you only deal with null collections and not empty collections and use a Not Null Validator. Not practical, though.
Use self validation and have the object validate in code that the collection(s) have the correct number of items. Will work but it's nice to have the validation in the configuration file.
Expose the collection count as a property. This could be done, assuming an employee collection for example, with an EmployeeCount property on your object that contains the collection or you could create your own custom collections that expose a count property. Then you could use a Range Validator to validate on the Count property.
Create a custom validator that can validate the number of items in a collection -- something like CollectionCountRangeValidator.
If I wanted to develop something quickly, I would probably go with option 3. However, option 4 fits in well with the Enterprise Library approach and also allows your class design to be independent of the validation requirements. Plus you could always reuse it on your next project. :) And does anyone really miss creating their own collections when a List will do nicely?
This is already implemented in the EntLib Contrib.
This is called CollectionCountValidator.
I have asked this question on more than one forums and it seems no one would even want to take a crak at it.
My problem is simple and i would guess everyone has run into it when using LINQ to SQL.
If your have a LINQ object called: Person and you would like to poulate a list box based on all of the people you have in your DB the task is simple:
BindingListCollectionView view;
view = (BindingListCollectionView)CollectionViewSource.GetDefault (dataContext.Persons);
Now say you wish to have a text box over the list to filter the results. that
would not work since IBindingList interface implemented by the LINQ to SQL objects returns false on "CanFilter" property.
What most people do is create an ObservebleCollection, the folloing is an example
im sure most of you use.
ObservebleCollection<Person> col = new ObservebleCollection<Person>(dataContext.Persons.ToList());
ListCollectionView view = (ListCollectionView)CollectionViewSource.GetDefault(col);
Since this will return a ListCollectionView and not a BindingListCollectionView
it will be filterbale and all is well with the world.
Here comes the problem, say you have Multi levels of Forign key relations:
Person<---Alias<---Tickets
and now you wish to have 3 list boxes binded when a person is selected the second list box will diplay only his Alias's and when an Alias is selected only it's Ticket's are shown, this is very simple with binding and syncronizing. the problem is if i want to add a textbox filter on tob of all of the listboxes ( say a person has over 1000 Aliases and i want to be able to filter them to choose 1 ).
The prvious solution of ObservebleCollection will not work since all the Person objects returned will have EntitySet objects for the forgin relation, and this will again return a none filterbale BindingListCollectionView and not a ListCollectionView.
The only way i found around this is to manually bulid an ObserverbleCollection based on the retunred Query this is tedious work and causes me to tie the BusnessObjects layer and the application Layer. also its very slow since you need to make many trips to the database...
Does anyone have a solution to this?
Thanks,
Eric.
I think the Model View View-Model pattern (MVVM) will help you out here.
Create a view for your first listbox and ensure it exposes its collection as something that implements INotifyCollectionChanged. Same with your second and third listboxes.
You can also make any of them include properties for binding to your textbox for filtering. When the value changes, you simple adjust the in-memory collection that the list is bound to.
Have a google for MVVM since it works quite well. Most examples will relate to WPF but are still applicable for what you are doing.
Also check out a product on codeplex called 'Bindable Linq' which allows you to do things like:
var q = from p in Persons.AsBindable() select p;