For TableScreens, on_init is called after table_setup about promotion HOT 4 CLOSED

It's probably time to look at these initializer methods to define more clearly what they should be used for.

on_init is called from the on_create (which, in turn, is called from Screen.new). I'm not really sure what the intent was for this method, to be honest. It's not inserted into a view yet, so this is a very early call in the lifecycle of a screen.

on_load is triggered any time a screen is loaded via open or open_tab_bar, etc. It is fired just before actually pushing the screen onto the navigation stack or tab bar or whatever. In the split screen I just created, on_load actually fires after being added to the split screen. This is inconsistent. on_load is primarily used for initiating the request for data.

will_appear, on_appear, will_disappear, on_disappear -- these are all directly called from the viewWillAppear(animated) (and view_will_appear) methods, so they're a direct correlation. I use will_appear to set up my view (although I make sure it only sets up the view once).

I think some cleanup and standardization is in order here. For one thing, I believe in some cases we're instantiating and wrapping a UINavigationController more than once during this process.

For your specific case, Mark, I think I'd build a special method for your table_data. More on that in a bit...

from promotion.

Something like this:

attr_accessor :my_attr_accessor

def on_load
  # Initiate some async call
  async do |data|
    # Done with getting data. Set the accessor and update the table
    self.my_attr_accessor = data
    self.update_table_data
  end
end

def my_attr_accessor
  @my_attr_accessor ||= [] # only sets it to [] if nil
end

def table_data
  # build table data here with self.my_attr_accessor
end

from promotion.

If you're loading the screen's view into another view (instead of using open) it won't fire on_load, so maybe on_init is a better method. I'd avoid doing that in most cases, though. I've done it before and it seems to cause more problems than it solves (having a dangling view controller with an attached view). Maybe you're better at avoiding the pitfalls than I am.

from promotion.

So I eventually ended up solving it like this, not realizing before that I can send parameters that are set before any of the initialization or setup of the view are done.

@my_table_view = set_attributes MyTableScreen.new(:my_attr_accessor => []), {
  backgroundColor: UIColor.clearColor
}
@parent_view.addSubview @my_table_view.view

and the table screen:

class MyTableScreen < ProMotion::SectionedTableScreen
  attr_accessor :my_attr_accessor
  # Do other stuff here
end

...but I still think that on_init should be called before the table_setup method.

from promotion.