Checlist project datepicker

[fakefur]

hi

working my way through slowly and i just have to ask if the way we are adding the datepicker is the “proper” way this is done? it seems needlessly complex to be designed this way no? do we have to override the same “technically not to be overridden” functions whenever we use datepicker controls? or is this just because of the way you have built the UI here?

it seems a pretty normal and good UI design which is why i ask the question as to whether this is the “proper” iOS way to do this?

thanks

[fahim]

@fakefur

i just have to ask if the way we are adding the datepicker is the “proper” way this is done?

Which part of adding a date picker are you talking about? If it is the embedding in a table view bit, then whether that is standard or not depends on your perspective. But if you are talking about actually wiring up a date picker, then that is more or less the standard way it is done. Just note that you can have a date picker on a normal view with way less work than you had to do here to work in a table view - that’s just the UI design side of things.

If I’ve missed what you really mean, you might want to give specific page numbers so that I know what you are talking about

[fakefur]

hi and thanks

it’s just the tableView functions that need to be overridden with your warnings that this isn’t really a good idea to do, and a Danger: sidebar type thing

if the datepicker were always visible would i be correct in assuming there would not be the need to override the tableView functions to do all the showing and hiding stuff?

[fahim]

@fakefur

if the datepicker were always visible would i be correct in assuming there would not be the need to override the tableView functions to do all the showing and hiding stuff?

Yes, you would not need the code to hide/show the table view row if you wanted the picker to always be visible - you’d simply show the date picker all the time.

[sgerrard]

I found the datePicker process somewhat messy as well. I did some testing, and discovered that this statement in the text is not really true:

The question is: where does the cell for this new date picker row come from? You can’t put it into the table view as a static cell already because then it would always be visible.

You actually can put it in the table view as a static cell, and then control whether or not it is visible with the numberOfRowsInSection override:

override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    if section == 0 {
      return 1
    } else if datePickerVisible {
      return 3
    } else {
      return 2
    }
}

You just need to call tableView.reloadData() when datePickerVisible changes, or insert/delete the row yourself if you want the animation.

It seemed a lot easier this way to me.

[fahim]

@sgerrard

You just need to call tableView.reloadData() when datePickerVisible changes,

This would probably work fine in this particular instance (or may not - I have not looked at the code to see how things are set up) but basically, if you call reloadData() all your table cells get reloaded and depending on how your cells are set up, you might lose status information during the re-load. That is why this approach is generally not used.

But if it works for you, by all means go for it But do be aware of the possible pitfalls when you do so …