I have an app with 2 layers (at the moment); bottomlayer has a tableView, and I would like top layer to show different buttons/labels/etc based on tableView selection. Instinct to to hide/show layers based on didSelectRowAtIndexPath, but that would necessitate hiding/showing a lot of layers based on selection. I also imagine the storyboard would get quite messy as well :(
Is there a more reasonable/effective method for changing the UIView on the toplayer based on tableview selection?
Loop through them all in a for-in loop kind of like this:
-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
if (indexPath.row == 0) {
for (UIView *view in self.view.subviews) //change this to your container {
if (view.tag == 14)
continue;
/*Do Nothing, this is the golden view that stays on screen. Maybe set it's frame or alpha, but don't hide it.
*/
else
[view setFrame:CGRectMake(0, self.view.bounds.size.height, 768, 1024)]; //set this to any value that puts the view offscreen or set alpha to 0
}
}
}
it all depends on you setting their tags, which index is selected and which view you want to exclude.
Although, depending on the changes you want, or how many objects you have to change, this method may actually be more cumbersome.
Related
I have UITableViewCell that contains UIView (lets call it CPView) which is created while cellForRowAtIndexPath is called. CPView is just a plain coloured view and for every cell its width is different (that's why needed to create in cellForRowAtIndexPath).
Problem is
1)The CPView 's colour gets darker every time cell loads (May be due to every time that cell creates the same view so overlapping effect).
2) The cell overlaps / inherits other cell's CPView (we can see this because of light and dark colour of two CPView).
How can I prevent cell to recreate if it already exist or creation of this CPView again?
Edit
- (void)configureCell:(CreditDebitCell *)cell atIndexPath:(NSIndexPath *)indexPath {
//other code
UIView * CPView;
if (CPView){
CPView =nil;
}
else
{
CPView = [[UIView alloc] initWithFrame:CGRectMake(cell.bounds.origin.x, cell.bounds.origin.y, cell.frame.size.width*[self.percentArray[indexPath.row] floatValue] ,cell.frame.size.height )];
[CPView setClipsToBounds:YES];
[CPView setBackgroundColor:[UIColor colorWithRed:107/255.0 green:15/255.0 blue:47/255.0 alpha:0.5]];
[cell addSubview: CPView];
}
}
The issue here is reuse of the cells - and therefore you get multiple views added to your cell view.
You can:
-remove subview
-check if subview exists and do/don't do anything.
You can check if the subview is there by going through subviews:
for (UIView *v in cell.contentView.subview) {
if ([v isKindOfClass:[CPView class]]) {
// remove or flag that it exists
}
}
But I think that you should handle this in your cell - not your view controller that implements table view delegate. Better tell cell to use some view/hide some view based on some kind of logic then to do that inside cellForRowAtIndexPath
According to your i question(without cellforRowAtIndexpath) i can assume that you should check every time something like in cellForRowAtIndexPath
if(cpView){
cpView = nil;
}
// alloc again with required size for particular row.
Make a subclass of your UITableViewCell and make a property of it that will reference your CPView. This will now let you have a better control whether your subclassed cell does / doesn't have any CPView that needs to be added.
I want to make an app with the function like WangYinews app.
It has a UIScrollView at the center and the UIScrollView has some UITableViews.
Now what I want to do is let user change some static UITableViews by slide the UIScrollView left or right.
Here is the effect as follow.
Here is the effect as follow.
You can simply create 3-4 or more uitableview and add it on scroll view something like this:
[scrollView addsubView: table1];
[scrollView addsubView: table2];
And so on. And to differentiate these table views in delegate functions, you can use tag property like following:
table1.tag = 1;
table2.tag = 2;
//datasource methods
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{
if(tableView.tag == 1){
self.arrayForTable1.count;
}
if(tableView.tag == 2){
self.arrayForTable2.count;
}
}
Hope it will give you an idea.
After quite a lot searching around Google, Stackoverflow and apples documentation, I have almost given up.
I am making an app to index costumers and because of a potentially very long list, I use section index to navigate faster. My problem is shown in the picture below.
When I drag an item to reveal the delete button, it is partially hidden below my section index bar.
I have no code setting tableview or tableviewcells width and the section index can't really be changed, as far as i am concerned.
EDIT:
The question is how I can have the tableview cells end before they get overlapped, so the delete button is fully visible.
EDIT 2:
I already tried setting the cell frame smaller without any luck.
cell.frame = CGRectMake(cell.frame.origin.x, cell.frame.origin.y, cell.frame.size.width-30, cell.frame.size.height);
I also tried the same with the tableview, but as it is in a UITableViewController it cannot be resized.
self.tableView.frame = CGRectMake(self.tableView.frame.origin.x, self.tableView.frame.origin.y, self.tableView.frame.size.width-30, self.tableView.frame.size.height);
As a simple work-around we resolved the visual overlap of the index by setting the background color of the index to clearColor.
self.tableView.sectionIndexBackgroundColor = [UIColor clearColor];
* This looks visually better, but the index will still overlap your tableViewCell.
Another possible work-around would be to hide the index bar when entering edit mode:
// allow editing
[self.tableView setEditing:YES animated:YES];
// hides the index
self.tableView.sectionIndexMinimumDisplayRowCount = NSIntegerMax;
The inEditMode method should do the trick. Below I embed a complete code that hides the index while editing and shows it again when the editing is done.
-(void)tableView:(UITableView *)tableView willBeginEditingRowAtIndexPath:(NSIndexPath *)indexPath{
[self inEditMode:YES];
}
-(void)tableView:(UITableView *)tableView didEndEditingRowAtIndexPath:(NSIndexPath *)indexPath{
[self inEditMode:NO];
}
//on self.editButtonItem click
-(void)setEditing:(BOOL)editing animated:(BOOL)animated{
[super setEditing:editing animated:animated];
[self inEditMode:editing];
}
-(void)inEditMode:(BOOL)inEditMode{
if (inEditMode) { //hide index while in edit mode
self.tableView.sectionIndexMinimumDisplayRowCount = NSIntegerMax;
}else{
self.tableView.sectionIndexMinimumDisplayRowCount = NSIntegerMin;
}
[self.tableView reloadSectionIndexTitles];
}
Just Use this code before allocating any subview in cellForRowAtIndexPath
for (id object in cell.contentView.subviews)
{
[object removeFromSuperview];
}
I am creating an app and in one of the navigation views, I have a very similar design as that of the App Store app — see Details | Reviews | Related section. Following on similar lines, I wish to implement the segmented control in the 'same' way Apple has done in their app. (This is also similar to what Apple does in the Artist -> Albums navigation view in the default iOS 7 music app, albeit for a table header (maybe).)
If you scroll up, when the segmented control container touches the navigation bar, it sticks there.
It also allows the user to notice that this is some kind of overlay due to the alpha associated with it.
When you scroll down, it moves into position when required.
What I have done —
I have created a container view with the segmented control. When the scrollView scrolls, I reposition my container view to accomplish the sticky effect. This is just pseudo-code but my code actually works.
- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
if (scrollView == self.labTestScrollView)
{
/*
As soon as the user scrolls up, y changes, therefore, we need to stick the options container view
such that it doesn't go past the UINavigationBar
Need to check if the origin of the options container view in the coordinate system of the main
superview is just gone past the UINavigationBar in this controller's view.
- get the bounds rect for the options container view
- convert these bounds and position them in the coordinates of this controller's view
- check if origin.x for container view is less than that of view.origin.y
- if less than stick it by converting the headerFrame to the coordinate system of the options
container view; and raise the stuck flag
- if greater, check if the stuck flag is raised; check for another object in space before the container view and adjust accordingly.
*/
}
}
There are two issues:
No overlay effect. I can configure the alpha such that the effect is a bit more visible but that doesn't seem natural.
The second concern stems from the first. This seems like a very specific solution. I am looking forward to something that's more natural; and something that could work by default using table views or something.
Why not simply use a UITableView?
Put your 'top content' in section 0 and have no header for that section. Put all the other stuff in section 1 and give that section a header with your UISegmentedControl.
Following code works pretty well. You might want to find a way to give the background of the header a 'blur' effect to mimic Apple's behavior some more; maybe GPUimage could help you there?
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 2;
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return section == 0 ? 1 : 5;
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
NSString *identifier = indexPath.section == 0 ? #"header" : #"content";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
// customize cell
return cell;
}
- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section {
if(section == 1) {
UISegmentedControl *segmentedControl = [[UISegmentedControl alloc] initWithItems:#[#"Foo", #"Bar"]];
segmentedControl.backgroundColor = [UIColor colorWithWhite:1.0 alpha:0.95];
return segmentedControl;
}
return nil;
}
- (CGFloat)tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section {
return section == 0 ? 0 : 44;
}
I'll leave the tweaking up to you ;)
This is actually 2 views.
The first is the header of a UITableView.
This includes the segmented control and the app icon, the install button, etc...
The second view has a segmented control that sits at the top of the screen and is hidden.
When the tableview scrolls you can intercept the scroll view delegate method scrollView:didScroll...
In here, if the scrollView offset is larger than the height of the header then make the second view visible. Else make it hidden.
That's it. Now you just need to remember to update both segmented controls whenever one is hanged.
I have a UICollectionView with a grid of images. When you tap on one, it opens up the grid and shows a subview with some details. Like this:
I open up the grid in my UICollectionViewLayout by adjusting the UICollectionViewLayoutAttributes and setting a translation on the transform3D property for all cells below the current row of the selected item. This works really nicely, and is a much better animation and a simpler approach than my first attempt at inserting another cell into the grid which is a different size to the others.
Anyway... it works most of the time, but then after continued use I see old images on the collection view. They are like ghost cells. I can't click them, it's like they haven't been removed from the collection view properly, and they sit on top of the cells preventing taps and just being a nuisance. Like this:
Any ideas why these cells are doing this?
EDIT:
I'd like to add, I think it only happens when i scroll the collection view really fast. I've written my own UICollectionViewFlowLayout replacement to test if it still happens. It does.
EDIT 2:
The 3d transforms or layout have nothing to do with this. It must be a bug in UICollectionView. I can exploit by just scrolling really fast, letting come to a standstill and then querying the views that are on screen. There are often double the number of cells, but they are hidden as they are stacked on top of each other. My implementation above reveals them because of the translation i do.
This can really hurt performance too.
See my answer for a solution.
My second edit of my question details why this is happenening, and here is my workaround. It's not bullet proof, but it works in my case, and if you experience somethign similar you could tweak my solution:
- (void) removeNaughtyLingeringCells {
// 1. Find the visible cells
NSArray *visibleCells = self.collectionView.visibleCells;
//NSLog(#"We have %i visible cells", visibleCells.count);
// 2. Find the visible rect of the collection view on screen now
CGRect visibleRect;
visibleRect.origin = self.collectionView.contentOffset;
visibleRect.size = self.collectionView.bounds.size;
//NSLog(#"Rect %#", NSStringFromCGRect(visibleRect));
// 3. Find the subviews that shouldn't be there and remove them
//NSLog(#"We have %i subviews", self.collectionView.subviews.count);
for (UIView *aView in [self.collectionView subviews]) {
if ([aView isKindOfClass:UICollectionViewCell.class]) {
CGPoint origin = aView.frame.origin;
if(CGRectContainsPoint(visibleRect, origin)) {
if (![visibleCells containsObject:aView]) {
[aView removeFromSuperview];
}
}
}
}
//NSLog(#"%i views shouldn't be there", viewsShouldntBeThere.count);
// 4. Refresh the collection view display
[self.collectionView setNeedsDisplay];
}
and
- (void) scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {
if (!decelerate) {
[self removeNaughtyLingeringCells];
}
}
- (void) scrollViewDidEndDecelerating:(UIScrollView *)scrollView {
[self removeNaughtyLingeringCells];
}
A quick further comment to bandejapaisa's: under iOS 6 only, I found that UICollectionView also had a habit of bungling animated transitions. The original cells would remain where they were, copies would be made and then the copies would be animated. Usually on top of the originals but not always. So a simple bounds test wasn't sufficient.
I therefore wrote a custom subclass of UICollectionView that does the following:
- (void)didAddSubview:(UIView *)subview
{
[super didAddSubview:subview];
//
// iOS 6 contains a bug whereby it fails to remove subviews, ever as far as I can make out.
// This is a workaround for that. So, if this is iOS 6...
//
if(![UIViewController instancesRespondToSelector:#selector(automaticallyAdjustsScrollViewInsets)])
{
// ... then we'll want to wait until visibleCells has definitely been updated ...
dispatch_async(dispatch_get_main_queue(),
^{
// ... then we'll manually remove anything that's a sub of UICollectionViewCell
// and isn't currently listed as a visible cell
NSArray *visibleCells = self.visibleCells;
for(UIView *view in self.subviews)
{
if([view isKindOfClass:[UICollectionViewCell class]] && ![visibleCells containsObject:view])
[view removeFromSuperview];
}
});
}
}
Obviously it's a shame that 'is this iOS 6' test can't be a little more direct but it's hidden off in a category in my actual code.
A Swift UICollectionView extension version of bandejapaisa's answer:
extension UICollectionView {
func removeNaughtyLingeringCells() {
// 1. Find the visible cells
let visibleCells = self.visibleCells()
//NSLog("We have %i visible cells", visibleCells.count)
// 2. Find the visible rect of the collection view on screen now
let visibleRect = CGRectOffset(bounds, contentOffset.x, contentOffset.y)
//NSLog("Rect %#", NSStringFromCGRect(visibleRect))
// 3. Find the subviews that shouldn't be there and remove them
//NSLog("We have %i subviews", subviews.count)
for aView in subviews {
if let aCollectionViewCell = aView as? UICollectionViewCell {
let origin = aView.frame.origin
if (CGRectContainsPoint(visibleRect, origin)) {
if (!visibleCells.contains(aCollectionViewCell)) {
aView.removeFromSuperview()
}
}
}
}
// 4. Refresh the collection view display
setNeedsDisplay()
}
}