i have a tableview with form fields, and there is a row that use segue to call an UICollectionView, everything is works except that i can't keep the selected cells (the visual effect that i show when the cell is selected) after go back to the tableview.
I mean, i selected my UICollectionView cells, after that i go back to the form, but if i need to again to my UICollectionView Cells, to deselect o select more cells before submit the data, once the UICollectionView appear my previous selection are there (i print the array, and i see the values) but i cant see the effect that i did for selected cells.
How i can keep the effect for selected cells if I'm going back to select again o deselect cells?
One thing to realize is that this is not going to happen by itself. When you segue back to the table view and the form fields, the UICollectionView is completely destroyed. The next time you show the collection view, it is a new and different collection view.
So, if you want to maintain a knowledge of what the selection was in the collection view, you are going to have to maintain it yourself, deliberately, storing it somewhere when you know that the collection view is being destroyed.
That way, the next time you show your collection view, even though that will be a completely new and different collection view, you can pass the knowledge of what the selection was to that collection view as you create and show it. The user will have the illusion of "returning" to the collection view, in the same state, but in fact you will have saved and restored its state.
It is then just a matter of reflecting the selected state in the collection view's display of its items. To do that, you need to configure your model so that when cellForItemAtIndexPath: is called, each cell looks selected if that item is supposed to be selected.
Every time you use segue to call an UICollectionView a new instance of UICollectionView is created and hence states of selected cells doesn't get restored.
I believe u must have taken an array of index paths of selected indexes to show the visual changes in the cell.
Make your tableView class as delegate of UICollectionView. Using its delegate methods return the selected index array to tableView class .And before pushing to UICollectionView send the same array of index paths back to the UICollectionView. Hope it helps.. Happy Coding.. :)
Related
I've found some similar questions already on SO, but nothing that seems to address this specific problem.
I'm using a UITableView with around 25 dynamic cells. Each cells contains a hidden UIProgressView. When the user taps on the download button within the cell to download that item, the UIProgressView is displayed and it indicates the progress of the download.
I've achieved this by assigning a tag to each cell which is equivalent to its corresponding downloadItemID. Each instance of MyCell has its own progressBar property.
This works fine as long as the table view is not scrolled during the download. It works also when the user is downloading multiple items at the same time. The code looks like this:
UIProgressView *theProgressBar;
for (MyCell *cell in self.tableView.visibleCells)
{
if (cell.tag == downloadItemID) theProgressBar = cell.progressBar;
}
float progressPercentage = (float)completedResources / expectedResources;
[theProgressBar setProgress:progressPercentage animated:YES];
The problem is that when the user scrolls the table view, the cell and progress view are transferred to another cell. It's simple enough to reset and hide the progress view for the new cell, but when the original/downloading cell is scrolled back into view, no progress is visible.
I've tried caching active progress bars into a dictionary and reallocating them back to the original cell in cellForRowAtIndexPath, but this is giving me the same result: no visible progress after scrolling the cell off and on the screen. Even if I can get them to show up, I'm doubtful I can get this to work seamlessly by rolling my own caching method.
What I need is to keep cells in memory. But can I work around dequeueReusableCellWithIdentifier? This whole problem has arisen because I had to switch to a dynamic system of allocating the cells, but it is too dynamic. Can I create the cells dynamically, but keep them in memory all the time once created, or at least keep the ones that are currently downloading?
(I understand the reasons why cell reuse is the preferred way to go with table views.)
You are working against the framework. As vadian says in the comment, you need to separate the logic and state information from the cells and put them elsewhere.
Here is one way of doing it.
Create a class to hold each download state, like a download ongoing flag, download progress, title, URL, etc.
In your view controller, create and add all your download objects to an array when the view controller is created. The first object corresponds to the first row in the table.
Whenever you dequeue a cell, populate it with data from the array. The NSIndexPath row property serves as the index into the array.
All your updates (download progress) updates the download objects in the array, then update the cell content using the updated object. You can use UITableView cellForRowAtIndexPath to get the cell for a specific array index, if you get nil there is no need to update it.
I'd like to get every data that is within all cells in one tableview which is quite a long list.
I'm looking for an approach on how to retrieve everything including those hidden in view, which I know the views are reused. I think some of you might have experienced this problem before, what are your approach on this?
I've tried
let cells = self.tableView.visibleCells
then looping into every cell and saving each data to an array but it is not effective in getting those that aren't part of the view or hidden. Is there a way to get over this?
In cellForRowAtIndexPath, YOU are telling the table what is in each cell. So why would you turn around and ask the table what's in each cell? If the user puts "Hello" in your first cell, then scrolls the table enough to push that first cell out of view, then when the user scrolls back to the top, YOU are the one telling it to put "Hello" back in that first cell. YOU own the data source, not the table.
You need a data source. That can be "empty" at first, maybe an array of empty strings if that's what you want (each index in the array could map to a table row for example). But then, as the user interacts with the text fields in the cells, you need to update that data source with the text they entered.
You should use that data source as your source for the cellForRowAtIndex method. That way you can handle populating the cells when they are requested by the table, and you also know all the data when the user is done.
Why not just update the model each time the user taps a key when editing a textfield? You could create a protocol for that cell subclass and make your view controller the delegate for each cell. As long as cells are guaranteed to stay on the screen while you're typing (you'll get some weird behaviors if not) the cell can send a message to the view controller or whatever you hook it up to telling it what new value to store. Then everything is already stored for you when you need the full list, and you don't have to interact with the tableview.
I have another question open where I'm trying to figure out how to reload the collectionView without auto-scrolling. I was also realizing there are a lot of other situations where I will need to change things in the collection view. Also I have some items that I will want to change the .alpha on and change the text of. Is there a way to do all of this in Swift? For example (to be specific) if I have a collection view with a view in each cell and that view has a textField in it, can I change the alpha and text, (change alpha with animation even) without reloading entire table?
Look at the documentation for UICollectionView. There are several "reload" methods:
reloadData()
reloadSections(_:)
reloadItems(at:)
If you just want to reload a single item, update your data source's data and then call reloadItems(at:) passing in the index path for the item.
Another option, if a cell is currently visible, is to use the cellForItem(at:) method to get a reference to an existing cell. Then you can directly access UI components of the cell as needed. You should also update your data model as needed so if the user scrolls and comes back, the cell will be rendered properly.
Most appropriate where you can update your custom view of a particular UIcollectionViewcell is reloadItemsAtIndexPaths.
You would be handling a particular item than whole collectionview with reloadData.
You can handle it via notifications or some call backs in your code where you can make decision when to update which cell.
Hope it will help you.
I am creating a settings menu and wanted to implement functionality so that when a user toggles any of the switches, it automatically saves their selection in my sqllite database.
I was thinking about putting each element into an outlet collection, iterating over each element, and adding each event to the same function.
Is there an easier way to do this or is that about it?
Thanks!
I'd put it in a tableview.
Then each cell manages its own UISwitch. The UISwitch also talks back to the cell.
Then in the cell you can call back to the table view controller to update it (with the row index) when the switch is updated.
In a core data app, I've got a UIViewController that has a "master" tableview on the left, with a set of detail controls (textfields, switches) and another UITableview on the right. (This is the iPad layout.) The tableviews are populated by NSFetchedResultsController instances. When the user selects a row on the leftmost tableview, it populates the details fields accordingly for editing, and the far right table is populated by another NSFetchedResultsController, displaying a set of related objects.
My problem is that for the master tableview, the one on the left, whenever I edit on of the fields related to the sort descriptors of the NSFetchedREsultsController, the table reorders and changes it's selection, which means the user would have to find the desired row and select it again to continue working. Is there a way I can prevent that selection from changing, or at least force it to reselect the proper row after it reorders the data?
It sounds like you are implementing the fetched results controller's delegate in only the most basic way, i.e. calling reloadData from within the controllerDidChangeContent: method. This will clear the table view's selection.
It you implement the fine-grained delegate methods, you should receive multiple changes of type NSFetchedResultsChangeMove during a reordering update, from which you can call moveRowAtIndexPath:toIndexPath:, which should preserve the table view's selection.
Otherwise you can store the model object that is selected in controllerWillChangeContent: and restore the selection from that model object in controllerDidChangeContent:.