Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting rightAccessoryButton won't remove cancelButton #3

Open
2 tasks done
bretdabaker opened this issue Sep 20, 2017 · 1 comment
Open
2 tasks done

Setting rightAccessoryButton won't remove cancelButton #3

bretdabaker opened this issue Sep 20, 2017 · 1 comment

Comments

@bretdabaker
Copy link

  • I have read this issue template and provided all possible information.
  • I'm using CocoaPods and have run pod update before filing this issue.

Hardware / Software

Which version of the library were you using?
Answer: 0.0.1

Which version of iOS are you running?
Answer: iOS 11

What model of iOS device were you testing on?
Answer: Simulator

If using CocoaPods, which version of CocoaPods are you on?
Answer: not related

Goals

What is the outcome result you want to achieve with this library?
Answer: We want to add a simple passcode lock when our app is launched and or enters background, we need to remove the cancel button because the passcode is not optional.

Expected Results

What did you expect to happen?
Setting rightAccessoryButton will remove the cancel button.

Actual Results

Setting rightAccessoryButton did not remove the cancel button.

Investigation

Currently the initialization flow is:

-initWithStyle:passcodeType
|_ -setUp
   |_ -view
      |_ -loadView
      |_ -viewDidLoad
         |_  -setUpAccessoryButtons

The problem begins with line 82: self.view.backgroundColor = [UIColor clearColor];. self.view triggers -loadView and in turn -viewDidLoad where the heavy view set up takes place. Then when -setUpAccessoryButton is called at line 175, the if statement is always true because it's called before the user has a chance to set rightAccessoryButton. Setting it after initialization has no effect because the logic is under -viewDidLoad.

In general calling self.view in -init should be avoided.

@TimOliver
Copy link
Owner

Hi @bretdabaker! Thanks for the detailed issue!

Ah you're right. That's definitely a bug being caused by some of my terrible coding practices. Sorry about that!

I just made a new push to master that moves the code triggering loadView to viewDidLoad. HOPEFULLY that solved the problem for you. Let me know! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants