Having trouble reloading tableView - ios

Question

I am having trouble reloading the tableView. When my firebaseService.getAllPosts() method runs, it gives me the two posts in the database (as intended). I can tell this because when the didSet print runs, it gives me the correct count. However, because I know the tableview is set before the method gets run, I know I need to reload the tableview to update the count in my datasource. There-in lies the issue. I put the posts variable outside of my class on purpose so it could be accessed from every class. (If this is not a good practice, let me know.)
Where can I run tableView.reloadData() so my tableView datasource updates and gives me the correct could of posts? I've tried putting FeedController().tableView.reloadData() in the didSet and I've tried putting it in viewDidLoad() but neither of these worked. I've also tried adding a variable called _posts and setting it equal to posts and adding didSet to that with tableView.reloadData() inside the didSet but that doesn't work either.
class FeedController: UIViewController, UITableViewDelegate, UITableViewDataSource {
let tableView = UITableView(frame: UIScreen.mainScreen().bounds, style: UITableViewStyle.Plain)
let cellId = "PhotoCell"
let textCellId = "TextCell"
let firebaseService = FirebaseService.sharedInstance
static let sharedFeedInstance = FeedController()
var posts = [Post]() {
didSet {
tableView.reloadData()
print(posts.count)
}
}
override func viewDidLoad() {
super.viewDidLoad()
firebaseService.getAllPosts()
tableView.dataSource = self
tableView.delegate = self
self.view.addSubview(tableView)
}
// MARK: - Table view data source
func numberOfSectionsInTableView(tableView: UITableView) -> Int {
// #warning Incomplete implementation, return the number of sections
print("sections: \(posts.count)")
return posts.count
}
func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
// #warning Incomplete implementation, return the number of rows
return 1
}
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
let post:Post? = posts[indexPath.section]
if let _ = post?.imageContentName {
let photoFeedCell = tableView.dequeueReusableCellWithIdentifier(self.cellId, forIndexPath: indexPath) as? FeedTVCellWithPhoto
photoFeedCell?.post = post
return photoFeedCell!
}
let textFeedCell = tableView.dequeueReusableCellWithIdentifier(self.textCellId, forIndexPath: indexPath) as? FeedTVCellText
textFeedCell?.post = post
return textFeedCell!
}
}
Update 1: getAllPosts method from FirebaseService class
func getAllPosts() {
let postRef = ref.child("posts")
postRef.observeSingleEventOfType(.Value, withBlock: { snapshot in
// print(snapshot.value)
if let snapshots = snapshot.children.allObjects as? [FIRDataSnapshot] {
for snap in snapshots {
if let postDictionary = snap.value as? Dictionary<String, AnyObject> {
let key = snap.key
let post = Post(key: key, dictionary: postDictionary)
FeedController.sharedFeedInstance.posts.insert(post, atIndex: 0)
}
}
}
})
}

Answer 1

In essence, you are addressing the methods and properties of FeedController the wrong way. Every time that you use FeedController() in your code you should be using self.
The following two paragraphs are a refresher about class and instance methods and properties. Feel free to ignore them if it's something that's already in your radar:
If a method or property belongs to an instance (that is, it may vary from instance to instance) you call it with self.property or self.method(), although often you can drop the self. as long as it does not create ambiguity.
If a method or property belongs to the whole class (and therefore it is declared as static let, static var or static func) then you would call it with NameOfTheClass.property or NameOfTheClass.method(). In your case, you would call it FeedController.property or FeedController.method(). That is, without the trailing parentheses. In any case, class methods and properties should be used sparingly and would probably not be appropriate in this situation.
Having settled that, we have the question of how to reload the data. If you move posts inside FeedController (making the array an instance variable) and add tableView.reloadData() (without the self.) to the didSet() of posts, you should be good, notwithstanding other unrelated code smells that others have highlighted and you should try to fix, but those should not affect your ability to reload the data.

Answer 2

So off the bat:
"FeedController().tableView.reloadData()" is
instantiating another FeedController. That's not going to work. Where to put the reload call will depend on your requirements. For example if you have a lot of segues occurring where you go back and forth to this UIViewController and the data is being changed in other UIViewControllers, you can reload in an override of viewWillAppear() or the other lifecycle methods. You need to call that on the tableView for the instance of the UIViewController that is loaded into the UIWindow, not what you're doing now.
Any reason why you're doing a lot of this stuff programmatically rather
than through the storyboard? Either way is fine but I find storyboard
to be a nice separation. For example if you used a UITableViewController through storyboard you could have it set up the delegate and dataSource without doing it through code which just looks like ugly boilerplate. You can set these without using a UITableViewController as well, as long as you meet the protocols. Those things that can be handled in the storyboard should is what I usually go by.
Your class is extending UIViewController and implementing those two protocols, why not just extend a UITableViewController? Unless you're manually putting a UITableView on there and need to show something other than a UITableView on that UIViewController there's no reason I can think of to do what you're doing.
Something else to note is that the way you're doing the PhotoFeedCell and TextFeedCell is kind of weird and gives mixed signals. You're dequeuing a reusable cell and optional casting it and using optional chaining afterwards, both of which implies that you're accepting it may be nil, but then force unwrapping it right after.