designatednerd / dnscastrosegmentedcontrol Goto Github PK

Hello,

This isn't really a bug, but more of a feature request.
I noticed that you hardcoded the radius value. Why not just expose the divider a public property? This way we could personalize the radius ourselves:

CGFloat cornerRadius = (CGRectGetHeight(self.frame) / publicRadiusVariable);

The higher the value - the more square corners will get. I'd probably submit a PR, but I'm more of a Swift person and just afraid to mess things up :)

It's possible for the control to be deallocated without registering for KVO. When this happens, this code will throw an exception:

- (void)dealloc
{
    [self removeObserver:self forKeyPath:[self boundsKeyPath]];
}

Here's the ugly solution as suggested by NSHipster:

- (void) dealloc {
    @try {
        [self removeObserver:self forKeyPath:[self boundsKeyPath]];
    } @catch(NSException * __unused exception){}
}

When called programmatically the selected outline does not move, only selected the icon changes selected color.

In my case the outline should have moved the the second icon.

programmaticSegmentedControl.setSelectedSegmentIndex(1, animated: true)

The current implementation does this:

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
    // some stuff…

    [self setSelectedSegmentIndex:roundedSection animated:YES];
}

I believe most users will consider it unexpected if an app's state changes while they're still dragging their finger. Normally, it's safe to drag controls around on the screen, and nothing will take effect until the finger is lifted. For example, in Settings, a user can drag the Airplane Mode switch right and left, and Airplane Mode won't enable unless they lift their finger while the switch is enabled.

Instead, I believe this behavior should be in touchesEnded:, and touchesCancelled: should revert selectionView to its original state.

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesMoved:touches withEvent:event];
    [self touchesEndedOrCancelled];
}

- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesMoved:touches withEvent:event];
    [self touchesEndedOrCancelled];
}

These methods both call touchesMoved: instead of their appropriate super method.

If this is intentional, can we document the reason?

From layoutSubviews:

if (!self.choices) {
    NSAssert(@"NO", @"Cannot setup with no choices set!");
}

However, @"NO" evaluates to YES, so the assert is never thrown.

I suggest we assert the actual condition:

NSAssert(self.choices, @"Cannot setup with no choices set!");

This would allow us to remove the conditional.

This will require some refactoring since right now the selection chiclet is at a z-level above the images/labels.

Options:

• Add background vs. outline mode, set z-level of the chiclet appropriately.
• Add a background view if background color is not nil, pin it to the chiclet.

After discussing #2 with @jacobvanorder, we determined that the main issue he was trying to address would be solved by automatically calculating the intrinsic width of the control based on length of strings, which is not done right now.

The link to castro goes to castrofm.com and I think it should go to castro.fm.