Skip to content

Home

Jump to bottom
Ratul sharker edited this page Oct 7, 2016 · 2 revisions

Home

This is the home page for RSCustomTabbarController (provide a link to the repository). This is a super flexible framework for building UITabbarContoroller (provide a link to appledoc) like or more enhanced user experience of your own implementation of TabbarController. Again i'm saying,

it's not a implementation of some kind of CustomTabbarImplementation, it's an framework, which provide some implementation of core functionality as UITabbarController(provide a link to appledoc) and provide you some elegant approach to reach your goal to implement your own custom tabbar controller implementation.

##Pages

  • link of the pages
  • link of the pages
  • link of the pages

Design philosophy

Philosophy behind the RSCustomTabbarController(link to repo) is to give developer the complete opportunity to design his own targeted tabbar design. Developer design the complete tabbar controller in the xib/storyboard, then provide the reference to these items via the delegation (provide the link to wiki delegation). Then the RSCustomTabbarController (link to repository) will automatically handle the operation that it could.

Lot's of chit chat is done, lets start about the class hierarchy for the implementation purpose. For implementation we are about to create a class for desired tabbar controller named DesiredTabbarController. We will declare this DesiredTabbarController as the subclass of RSCustomTabbarController. Subclassing this RSCustomTabbarController will provide the public functionality from RSCustomTabbarController. So Now your DesiredTabbarController got some functionality like the tabbar controller. Now Design the DesiredTabbarController in storyboard/nib, whatever the way you prefer. The general design consist of following items

  • a container
  • one (or more) tabbar item container
  • two (or more) tabbar items (typically UIButtons)
  • necessary constraints to bound them together

typical hierarchy of these following things are as follows

    UIViewController 
    | 
    |---UIView 
        | 
        |---container (An UIView)
        | 
        |---tabbar item container (An UIView) 
            | 
            |---tabbar item 0 (An UIButton)
            |---tabbar item 1 (An UIButton)
            . 
            . 
            .

Now let your DesiredTabbarController implement the RSCustomTabbarImplementationDelegate(link to the delegate). Implementing this delegate will conform that, whatever information or object is needed, can be accessed via DesiredTabbarController. Five things are asked via this RSCustomTabbarImplementationDelegate (link to the RSCustomTabbarImplementation), which are as following.

  • Who is the container (need to show the container object)
  • List of layout constraint which typically denote the height (can be width also) of the tabbar item container.
  • List of layout constraint denote the spacing between tabbar items and tabbar container.
  • What will be the height of the tabbar item container.
  • A event, which let you know that the selected tabbar index has been changed.

So why all these heck of a things are necessary ? Believe me, these all are required to introduce such a super flexible framework for tab bar controller. Let me start with one by one.

Firstly, the container object. We should let the RSCustomTabbarController know that, where it should add all the view controllers. RSCustomTabbarController will automatically add and remove them, by itself. But you have to make the introduction between the RSCustomTabbarController & view controller container such that, "Hey RSCustomTabbarController, this is the view controller container, whenever you put/render/add a view controller, you should put/render/add within this container."

Secondly, the layout constraints, denoting the size (typically the height, but it could be width or both). RSCustomTabbarController (link here) has a public function as follows

-(void)setTabbarVisibility:(BOOL)visible animated:(BOOL)animated;

which actually hide the tabbar containers (including the tabbar items). So how should the RSCustomTabbarController know that how to hide tabbar containers. While hiding, it actually set the constant to zero with a predefined animation. If you don't want this functionality just don't override them, in that case you have to provide your own implementation of the setTabbarVisibility: method.

Thirdly, the layout constraint between the tabbar items & tabbar item container. The reason behind necessity of these constraint is quiet messy. This complex is quite complex to follow, but let me try. Your tabbar item container will always be bigger than the tabbar items. so there is a spacing between tabbar container and tabbar items. Say in autolayout you stick 4 constraint top-leading-bottom-trailing between the tabbar item container & tabbar item. Which should look like following:

    |-- TABBAR ITEM CONTAINER --|
    |             |             |
    |             |             |
    |    |-- TABBAR ITEM --|    |
    |    |                 |    |
    |----|                 |----|
    |    |                 |    |
    |    |-----------------|    |
    |             |             |
    |             |             |
    |---------------------------|

Here the outer rectangle denote the tabbar item container & inner rectangle denote the tabbar item. Two vertical line and two horizontal line between to box denote the constraints. No what if the tabbar item container height and width constrain collapse to zero ? in that case to satisfy the constraint all together vertically and horizontally two constraint are needed to be relaxed. Otherwise the height and width of the tabbar item becomes negative. To cope up with situation we tell the RSCustomTabbarController that, this are the constraint which are needed to be relaxed while collapsing the tabbar item container. RSCustomTabbarController will restore them automatically while the tabbar item container is shown again. Again saying these list of constraint are optional, because your tabbar container item and tabbar item relation may not end up like shown in the above figure, just remember, if any constraint needed to relax while hiding the tabbar item container, just add them in this list.

Fourth is, why the height is needed. While hiding this height is not necessary. It's deliberately set the constraint's constant to zero But what should the RScustomTabbarController set while showing back from hidden state. How the RSCustomTabbarController gonna know what was the height or size of the tabbar item container size, thats why this method is here.

Fifth, RSCustomTabbarController need a way to apprise the DesiredTabbarContorller about which view controller are now currently in action, so that, upon changing the view controller DesiredTabbarController can change the state of the tabbar item. How the tabbar item will behave upon selection is needed to define inside this method.

Thats enough for a view from 5000 feet height. If you still don't get any of the idea discussed here, please checkout the demo's implementation, hope you find them helpful. Feel free to contact and report any bug.

Clone this wiki locally