Since Tizen 3.0 (released in 2017) introduced a new view managing system, Tizen View Manager for the native applications. Using View Manager, Applications could compose and manage their views easier and more efficiency. In this article, it describes the concept of the new Tizen view manager and its features for Tizen developers.

  • Tizen Viewmgr git repository:
  • https://review.tizen.org/git/platform/core/uifw/ui-viewmgr refs/


    1. Overview of Tizen View Manager


    1.1 Tizen View



    Conceptually, there are 2 types of views in Tizen. One is window view and the other is logical view.

  • Window View:
  • This view works as an output of an application display. Actual type of Window view depends on the window system. So in the previous version of Tizen 3.0, it worked with X11 Window. But in Tizen 3.0, it works with Wayland window system. Basically Each window is managed by Window manager. For example, its size, position, active status, life-cycle, etc.

  • Logic View:
  • A logical view works for a logical output area which is inside of a Window View. Normally, the actual type of Logical view is Evas_Object in EFL UI framework system or Layer in Dali UI framework. Also, it could be another type in additional UI frameworks in Tizen. This means the substance of logical view is totally depends on UI framework system. UI framework decides its behavior, visual look, programming method and etc. Current Tizen UI framework is EFL (Enlightenment Foundation Libraries) and it provides a Layout Component as a View and Naviframe as a View manager.

    Other than EFL, other UIFW in Tizen doesn’t have any view managing concept so far. Generally, one Tizen UI applications are being consisted views with Logic Views. One UI application has one basic Window view and it contains multiple logical views for navigating scenes. However, some applications occasionally use multiple windows for switching scenes. In this case, it could contain below scenarios.

  • Switching apps by App Control (i.e. Contact turns to Call for an immediate call)
  • App intentionally creates multiple windows (since it’s allowed)
  • Video output, System popup …


  • Figure 1: Current Tizen view system



    1.2 Naviframe


    A Naviframe stands for navigation frame. It’s a view manager for applications. A Naviframe holds views (or pages) as its items. Those items are organized in a stack, so that new items get pushed on top of the old, and only the topmost view is displayed at one time. Due to the characteristics of a stack, even though you push a new item, previous item is not deleted. Previous item will be shown when you pop new item. The transition between views is animated, depending on the theme applied to the widget. A default Naviframe style support title part above all the pages consisting of titles and function buttons and icon.

    Figure 2: Naviframe View navigation between Page 1 and Page 2


    1.2.1 Naviframe module (Elementary) in Tizen 2.4

    Figure 3 shows you where Naviframe (Elementary) package is located in Tizen building blocks.

    Figure 3: Naviframe (Elementary) in Tizen 2.4


    1.2.2 Naviframe Basic API Usage
    static void
    create_base_gui(appdata_s *ad)
    {
        //…
    
        //Create a Naviframe
        Evas_Object *nf = elm_naviframe_add(win);
        /* Push a previous button to naviframe item automatically */
        elm_naviframe_prev_btn_auto_pushed_set(nf, EINA_TRUE);
        /* Set naviframe as a main layout content */
        elm_object_part_content_set(layout, “elm.swallow.content”, nf);
        /* Add Callbacks for Back, More key events */
        eext_object_event_callback_add(nf, EEXT_CALLBACK_BACK, eext_naviframe_back_cb, NULL);
        eext_object_event_callback_add(nf, EEXT_CALLBACK_MORE, eext_naviframe_more_cb, NULL);
    
        //Create a view content. create_main_content() is an utility function that application defined.
        Evas_Object *content = create_main_content(nf, “Naviframe Demo<br/>Page 2”);
    
        //Create a view
        Elm_Object_Item *it = elm_naviframe_item_push(nf, "Title Buttons", NULL, NULL, content, NULL);
    
        //Set a view title cancel button
        Evas_Object *cancel_btn = elm_button_add(nf);
        elm_object_text_set(cancel_btn, "CANCEL");
        evas_object_show(cancel_btn);
        elm_object_item_part_content_set(it, “prev_btn”, cancel_btn);
    
        //Set a view title done button
        Evas_Object *done_btn = elm_button_add(nf);
        elm_object_text_set(done_btn, "DONE”);
        evas_object_show(done_btn);
        elm_object_item_part_content_set(it, “next_btn”, done_btn);
    
        //…
    }
    


    1.2.3 Naviframe API list
    //Create a Naviframe
    Elm_Naviframe *elm_naviframe_add(Elm_Naviframe *parent);
    //Create a Naviframe View
    Elm_Naviframe_Item *elm_naviframe_item_push(Elm_Naviframe *nf, const char *title_label, Evas_Object *prev_btn, Evas_Object *next_btn, Evas_Object *content, const char *item_style); 
    //Insert a Naviframe View
    Elm_Naviframe_Item *elm_naviframe_item_insert_after(Elm_Naviframe *nf, Elm_Naviframe_Item *after, const char *title_label, Evas_Object *prev_btn, Evas_Object *next_btn, Evas_Object *content, const char *item_style);
    //Insert a Naviframe View 
    Elm_Naviframe_Item *elm_naviframe_item_insert_before(Elm_Naviframe *nf, Elm_Naviframe_Item *before, const char *title_label, Evas_Object *prev_btn, Evas_Object *next_btn, Evas_Object *content, const char *item_style);
    //Destroy a Naviframe View
    Evas_Object *elm_naviframe_item_pop(Elm_Naviframe *nf);
    //Enable/Disable touch event on Naviframe View transition
    void elm_naviframe_event_enabled_set(Elm_Naviframe *nf, Eina_Bool enabled);
    //Preserve the content objects when Views are popped
    void elm_naviframe_content_preserve_on_pop_set(Elm_Naviframe *nf, Eina_Bool preserve);
    //Control if creating prev button automatically or not
    void elm_naviframe_prev_btn_auto_pushed_set(Elm_Naviframe *nf, Eina_Bool auto_pushed);
    //Return a handle of the top view
    Elm_Naviframe_Item *elm_naviframe_top_item_get(const Elm_Naviframe *nf);
    //Return a handle of the bottom view
    Elm_Naviframe_Item *elm_naviframe_bottom_item_get(const Elm_Naviframe *nf);
    //Return the list of the views
    Eina_List *elm_naviframe_items_get(const Elm_Naviframe *nf);
    //Set style of the view (“default”, “tabbar/icon/notitle”, “tabbar”,  “empty”)
    void elm_naviframe_item_style_set(Elm_Naviframe_Item *item, const char *style);
    //Return the style of a Naviframe View
    const char *elm_naviframe_item_style_get(const Elm_Navifrmae_Item *nf);
    //Enable/Disable Title area of Naviframe
    void elm_naviframe_item_title_enabled_set(Elm_Naviframe_Item *item, Eina_Bool enable, Eina_Bool transition);
    //Promote an item already in the Naviframe stack to the top of the stack.
    void elm_naviframe_item_promote(Elm_Naviframe_Item *item);
    //Pop the top item and delete the items between the top and the above one on the given item.
    void elm_naviframe_item_pop_to(Elm_Naviframe_Item *item);
    //Set a function to be called when an item of the Naviframe is going to be popped.
    void elm_naviframe_item_pop_cb_set(Elm_Naviframe_Item *item, Elm_Naviframe_Item_Pop_Cb func, void *data);
    


    1.3 Tizen 2.4 View manager work flow


    Figure 5 shows you Tizen 2.4 view manager work flow briefly.


    Figure 5: Tizen 2.4 View manager work flow


  • Elementary:
  • Elementary is a basic widget set library that is easy to use and is based on EFL. It provides the basic building blocks for creating applications and user interfaces. Naviframe which is a view manager in Tizen 2.4 is also provided by Elementary.

  • efl-extension:
  • EFL Extension provides functionalities to enhance the EFL libraries. It includes device-specific features (like support for hardware back key) or profile-specific features (circular UI for wearable device.) The Tizen platform offers the Menu, Back and Home keys as physical hardware keys for mobile devices and rotary components parts for wearable devices. You can utilize the hardware keys in your applications with key grabbing. Basically, EFL does not depend on any specific hardware input methods such as hardware keys, to generate back and home events, or rotary component parts to generate rotary events. Instead these hardware input events have tightly related to the Tizen UX, as a result, Tizen has created the EFL extension library to support common UX behavior between application sand hardware events.

  • Window Manager:
  • A window manager is system software that controls the placement and appearance of windows within a windowing system in a graphical user interface. Most window managers are designed to help provide a desktop environment. They work in conjunction with the underlying graphical system that provides required functionality – Support for graphics hardware, pointing devices, and a keyboard, and are often written and created using a widget toolkit. In Tizen, Enlightenment which is built on EFL is adopted for the window manager.

  • App Control:
  • An application control (app control) is a way of sharing an application’s functionality. To use another application’s features through application controls reduces your efforts and time to develop your application. An application can be launched by the user from the Launcher or by another application. The application control can be used to describe either an action to be performed by other applications, or the results of the operation performed by a launched application. The application can receive results from the launched application.

    Basically, an application creates one default window that is a output of application display and fill inside it with views. Mostly, applications create views using any kind of container widgets like Elementary Layout, also control those views using Naviframe. Naviframe provides convenient functions via view push/pop mechanism. Additionally, it constructs basic view templates – Title and content parts and their look and feel styles - for views. Also, Naviframe implements view transition effects on the theme.

    In a certain situation, application may require another view that is suggested by other application package. For instance, your application could request camera view from camera app package for your application scenario. In that case, you cannot push the camera view into your Naviframe, instead you could launch the camera application window which contains the camera view using App Control. App Control is a way of sharing an application’s functionality like this situation. Once you launched the other application using App Control, it would be possible that one more windows for your applications could be constructed. However, window behaviors were controlled by Window manager under the Tizen window managing policy. Now, if you want to switch the views over the windows, in this case, then Window manager will perform the view switching immediately.

    Lastly, when the user pressed the Menu or Back key, the key generates a signal with its key property. EFL library receives the signal then propagates it to application layers as an event. The EFL extension library consumes the events and handles the views of the application according to key properties. Otherwise, EFL extension manages the rotary events, which are generated from rotary components in wearable devices and delivered to application layers by defining an event callback or a handler function, and registering it.


    1.4 Problems (Improvement Points)


    Since first generation of Tizen, we’ve found a few weak points and here list tells you the improvement point proposal for the next Tizen platform.


  • Current View Manager, Elementary Naviframe is hard to customize for Tizen UX Scenario such as View transition effects and View style. One of reason is, it has too strong dependency with EFL Open Source policy and some policies are conflicted with Tizen.

  • It needs a generic way to treat screen, irrespective of content. Not only a formal views but also overlay views such as Popup can be managed by view manager. Current applications have totally responsible for managing popup/contextual popup.

  • Integrated management of hardware key such as Menu and Back key and associated handler globally. Currently efl-extension does this role instead. However, It should be migrated to view manager side in order that applications could get those events easier and more convenient.

  • Abstraction of Screen creation process. Current View manager system doesn’t provide any basics for view life-cycle. For enhancing the application development usage, view interfaces need to hide their fundamentals but make compatible with widget, window and system process. Interfaces of view life cycle integrated with system events such as Load, Unload, Pause, Resume, Active, Inactive and Destroy, could be suggested for each view instance.

  • Indicator state management. Currently, indicator status in one application process is working globally. That means it requires applications to handle their indicator status change and recover manually in view by view. It’s a burdensome to them in keeping the context for the indicator through views.

  • The video interface has still too weak integration between UI framework and Multi-media framework. As the result, it occurs user’s burdensome. They need to assemble the video output into a view.




  • 2. New Tizen View Manager


    2.1 Considerations


    Now, we are trying to design new Tizen View Manager that improves the above problems (1.4). Additionally, here are more ideas when we’re considering the design.

  • Integration of Window View and Logic View:
  • As you’ve read the previous section, current Tizen has 2 types of views - Window and Logic Views. These different types of views results that users confuse in their application view management context. Tizen View Manager might need to define the window as the view without logic view. But this methodology leads to a lot of fundamental system changes including Window manager, EFL and peripheral service modules. Most of all, it requires tremendous optimization tasks because a window resource is much more expensive than a logic view.

    But the point is, whatever its substance is, if it provides an abstracted interface for the views, it will decrease conceptual complexity in point of user programming view. Also theoretically, it’s possible to achieve a management system for separated views from different UI systems such as EFL, Dali and Volt.

  • Integration of different UI systems:
  • One of downside of Tizen is, it has multiple UI systems. These UI systems have totally different development concepts, even different programming languages. Currently, EFL is based on the C language but Dali is based on C++ on the other hands. If we design the common Tizen View manager interfaces and it comes out with the specification for the UI application view managing, then users would understand the view manager concept quickly and easier through the different UI systems. Also, those UI systems could utilize the common View manager implementation body.

    The conclusion is, Tizen View Manager needs an enhanced clean and easy interface set out of Elementary Naviframe. It should be extendable by 2nd, 3rd parties, also its framework interface should be well-organized with Tizen application life-cycle and Tizen system. If the concept is closed to more Tizen family wise, it would be satisfied with any concepts of Tizen UX.


    2.2 UI View Manager Common Classes



    2.2.1 Class Description

    Next common interface classes are designed for Tizen View manager basic behaviors. Some of the methods are implemented with basic behaviors but some of them don’t because some parts of body are independent with UI systems but some parts must depend on UI systems. So you must inherit them definitely to implement the specific behaviors for current UI system.

  • UiIfaceViewmgr:
  • This is a base class of view manager. One view manager represents a class which contains multiple views. A view manager does not only manage views life-cycle but also constructs basic infrastructures such as key events handling, transition effects, transient views and etc. This interface guides you a basic policy and behaviors of a view manager. Be aware that when view manger is destroyed, all containing views should be destroyed as well.

    Figure 6: UiIfaceViewmgr class diagram


  • UiIfaceView:
  • This is a base class of view. A view must have one actual content instance which represents a view for a current screen. The content type could be any types with regard to UI systems (i.e. Eo*, Layer, Window…). A derived class must implement the view body based on the actual content in its UI system. This view will be belongs to a UiIfaceViewmgr instance and dominated its state by UiIfaceViewmgr. Basically, a view communicates with UiIfaceViewmgr to active cooperatively. This class is inherited to UiIfaceRotatable class to handle view’s rotation state. Also, user can handle a view’s life-cycle events with theses –load, unload, activate, deactivate, pause, resume, destroy-. A view may have its own show/hide transition style. That means, it’s available that views have different show/hide effects on demands. It’s not mandatory but view should describe the transitions in this class. Please be full aware of view life-cycle to understand view’s behavior.

    Figure 7: UiIfaceView class diagram


  • UiIfaceRotatable:
  • This is an interface class to support rotation behavior of views (or overlay). This class just defines status such as rotate, portrait, landscape so the derived class must implement the behavior body in its concept.

    Figure 8: UiIfaceRotatable class diagram


  • UiIfaceOverlay:
  • This is a base class to support overlay view which could be active on other view. An overlay is designed to be one subordinate of a UiIfaceView. The specific behaviors of this class are totally depended on the derived class but it must be communicated with UiIfaceView to work successfully. Fundamentally, overlay view provides simpler interfaces than UiIfaceView since most of the overlay views are active temporarily. This class is inherited to UiIfaceRotatable class to handle view’s rotation state.

    Figure 9: UiIfaceOverlay class diagram


  • UiIfaceApp:
  • UiIfaceApp is designed for wrapping the application instance. This class hides unnecessary application settings but expose only basic functions such as initialization and run. Basically, it works on the application life-cycle. It has application life-cycle event interfaces such as create(), pause(), resume(), terminate(), etc so that users can handle those events for their application behaviors. Also, It provides system event interfaces such as lowBaterry(), lowMeomory(), langChanged(), regionChanged() and so on. UiIfaceApp create a unique UiViewmgr instance internally, and manage its life.

    Figure 10: UiIfaceApp class diagram


    2.2.2 Design Diagrams

    A View manager designed on a certain UI system could be built on the base common interfaces. Applications may access that view manager to achieve view managing functions. Next figure 9, 10 shows you this design abstraction diagrams.

    Figure 11: Abstract View Manager Design Diagram




    Figure 12: UI system specified View Manager Design Diagram




    Figure 13: EFL View manager Design Diagram



    2.3 EFL View Manager Classes



    2.3.1 EFL Base Classes

    EFL base classes are designed for supporting view manager basics under profiles. Each view manager in various profiles could extend these base classes for their own specific policy and behaviors of profile. These bases implements common behaviors for EFL.

  • UiBaseViewmgr:
  • This is a base class of EFL View manager. Typically, this view manager extends UiIfaceViewmgr and implements basic behaviors for EFL View manager across all profiles. This view manager internally has one default window to display several logic views as well as this has a conformant and default application layout to display indicator, application layout and virtual keypad properly. This base view manager implements view transition effects. Of course, those could be customized for each profile. Also, it implements events blocking for views during views going back and forth. But this behavior will be turned on/off based on the system profile. Be aware when this view manager is destroyed, its window, conformant and default layout will be removed as well.

    Figure 14: UiBaseViewmgr class diagram


  • UiBaseView:
  • This is a base class of EFL View. Typically, this view extends UiIfaceView and implements basic behaviors for EFL view in all profiles. A view must have one Evas_Object content instance which represents a view for a current screen.

    Figure 15: UiBaseView class diagram


  • UiBaseOverlay:
  • This is a base class to support EFL overlay view which could be active on other UiBaseView. An overlay is designed to be one subordinate of one UiBaseView. UiBaseOverlay is nothing more than UiIfaceOverlay in behavior perspective. It just comes out with renaming class for adapting with other EFL base classes.

    Figure 16: UiBaseOverlay class diagram


  • UiBaseKeyListener:
  • This is a base class for EFL key listener. Typically, this class has a role for delegating event propagation from system to a view. UiBaseKeyListener grabs HW back key event then pass it to the top view from the view manager. You could extend this class for more HW key events for your profile feature. By overriding UiBaseKeyListener:extend_event_proc(), you could get the key event information when that event is triggered. This class must be requested by UiBaseViewmgr and controller wholly by it.

    Figure 17: UiBaseKeyListener class diagram


    2.3.2 Mobile profile EFL View manager classes

  • UiViewmgr:
  • This is a mobile EFL view manager class. Typically, this view manager extends UiBaseViewmgr and implements mobile specific behaviors for EFL view manager in mobile profile. UiViewmgr is nothing more than UiBaseViewmgr in behavior perspective. It just comes out with renaming class for adapting with other EFL mobile classes.

    Figure 18: UiViewmgr class diagram


  • UiView:
  • This is a mobile view class. Typically, this view extends UiBaseView and implements mobile specific behaviors for EFL view in mobile profile. UiView implements basics for running together with overlays such as UiMenu and UiPopup. You can use this UiView as an empty form view.

    Figure 19: UiView class diagram


  • UiStandardView:
  • This is a mobile standard view. This view extends UiView and implements mobile specific behaviors for EFL view in mobile profile. Basically, UiStandardView implements standard UI form for mobile application view. It internally constructs a layout which builds a basic form view that is consisted of title, tool and content parts. The title part locally has a left, right button parts as well as title and sub title text parts. The tool part is designed for an additional tool feature in a view. Elm_Toolbar widget could be used for this part and UiStandardView will set up all Elm_Toolbar decorating options for users convenient. Lastly, the content part is used for main content for UiStandardView. According to the system profile, when this view is pushed into a UiViewmgr, it will internally create a software back key that triggers popping the view.

    Figure 20: UiStandardView class diagram


  • UiMenu:
  • UiMenu is to support Tizen menu UI which could be active on one UiView. A menu is used for traditional contextual popup to give an option in its view context. Elm_Ctxpopup widget could be set as this UiMenu content for mobile profile. UiMenu will set up all Elm_Ctxpopup decorating options instead of users for their convenient. A UiMenu is designed to be one subordinate of one UiView in order to share events and contexts each other to work nicely. Only one menu could be active on a UiView. That means the previous menu will be removed by UiView when a new menu comes. UiMenu and its content, Elm_Ctxpopup will be deleted by its owned UiView on the proper time. So you can just leave its instance to it.

    Figure 21: UiMenu class diagram


  • UiPopup:
  • UiPopup is to support Tizen popup UI which could be active on one UiView. A popup is used for traditional popping context information to give an option or information in its view context. Elm_Popup widget could be set as this UiPopup content for mobile profile. UiPopup will set up all Elm_Popup decorating options instead of users for their convenient. A UiPopup is designed to be on subordinate of one UiView in order to share events and contexts each other to work nicely. One of differ points of UiPopup with UiMenu is, multiple popup could be active at the same time. That means, a new UiPopup will be overlaid on the previous UiPopup on the demands. It’s up to user’s scenario. UiPopup and its content, Elm_Popup will be deleted by its owned UiView on the proper time. So you can just leave its instance to it.

    Figure 22: UiPopup class diagram


  • UiKeyListener:
  • This class extends to UiBaseKeyListener to support additional HW Menu key for mobile profile. Basically, HW Menu key will be propagated to the top view and UiView::onMenu() will be triggered.

    Figure 23: UiKeyListener class diagram


  • UiApp:
  • This is a mobile UI application class. Typically, this application extends UiIfaceApp and implements mobile specific behaviors for mobile profile. UiApp is nothing more than UiIfaceApp in behavior perspective. It just comes out with renaming class for adapting with other EFL mobile classes.

    Figure 24: UiApp class diagram


    Figure 25 shows you an entire class hierarchy for EFL Mobile profile.

    Figure 25: Class hierarchy for EFL Mobile Profile



    2.4 New Block Diagram


    Next figure shows you where UiViewmgr package is located in Tizen building blocks.

    Figure 26: UiViewmgr in Tizen 3.0



    2.5 New View Manager work flow


    Figure 27 shows you Tizen 3.0 UI View Manager work flow briefly.

    Figure 27: UI View Manager work flow


    Compared to the previous architecture, new view manager in Tizen 3.0 is wholly replaced to UiViewmgr from Elementary Naviframe. This new UiViewmgr will work on a UI system, hiding detailed view managing mechanism with regard to UI system. Main functionality of view managing is similar with functionality of Naviframe. However, UiViewmgr takes cover not only view managing but HW key propagation and popup context management also.

    UiView is a more abstracted handle for a view that provides much more convenient functions and simpler interfaces. Not like Elm_Object_Item, which is a view interface of Naviframe, UiView works on the view manager which is running with Tizen application process. UiView notifies users to handle some pre-conditioned various states on time. For instance, after registering a view, user could get a notification about load, unload, pause, resume, activate, deactivate. This state based view managing methods reduces the complexity of view context, also improves the application infrastructure design cohesion.

    Next figure shows you a life-cycle of a view on a certain scenario.

    Figure 28: View life cycle


    A view works on state based, it must have only one certain state by scenario. The next describes those states of a view.

  • Load:
  • A view of this state is moving onto the screen. Get ready for this view. Generally, you could prepare this view's content here and set them to this view. In the most cases, this load will be triggered with this step. Load -> Deactivated -> Activated. This Load will be triggered only when view has not any content yet.

  • Unload:
  • Remove resources (contents) with regards to this view for saving memory. Otherwise, you could keep those resources (contents) for later access. Removing resources might be better in point of performance view but it's up to your scenario. Unload will be triggered just right before the view is going to be deleted by popping or by somehow. Also, Load will be triggered when this view is pushed behind other views.

  • Activate:
  • Generally, a view will be activated when show-transition is finished. From whatever its state, when the view comes on the screen, Activate will be triggered. In the most cases, activate will be triggered with this step. Load -> Deactivate -> Activate

  • Deactivate:
  • Get ready for unload. Hide transition may be triggered at this point. If the system blocks application running in some cases such as phone call, system notification, application switching ..., Deactivate state will be triggered. Also, when a view is going to be popped or destroyed, onDeactivate() will be triggered. Lastly, when a new view is pushed, so if it becomes invisible state by other views, onDeactivate() will be triggered also.

  • Pause:
  • Some UI controls such as Popup or a Menu popup usually blocks views. For those scenarios, this blocked view would be paused and shouldn't be interactive with users. However, still it would be visible in some way (ie, half transparency). For this, this Pause will be triggered. If the view is already deactivated or under the unload state, the pause won't be called.

  • Resume:
  • When a view is returns to the activate state from pause state, this onResume() will be triggered. For instance, a Popup is dismissed.

  • Destroy:
  • When this view is on destroyed by popping or by somehow, destroy will be trigged. Most of the cases, you can free your personal resources for the view because this view instance will be totally freed at the end of destroy. Be aware that you must not request any view functions on this state.



    3. Sample Code (C++)

  • Base GUI
  • class SampleApp: public UiApp
    {
    public:
        SampleApp() : UiApp(PACKAGE, LOCALE_DIR) {}
        ~SampleApp() {}
    
        bool onCreate()
        {
            if (!UiApp::onCreate()) return false;
    
            /* Create a first view content here… */
            UI_VIEWMGR->pushView(new page());
    
            return true;
        }
    };
    
    int main(int argc, char *argv[])
    {
        SampleApp app;
        return app.run(argc, argv);
    }
    

  • View creation
  • class page: public UiStandardView
    {
        /* on_load() will be called when this page is requested to be shown. */
        void onLoad()
        {
            UiStandardView::onLoad();
    
            /* create content */
            …
            this->setContent(content, “title”);
        }
    };
    

  • View deletion
  • class page: public UiStandardView
    {
        void onLoad()
        {
            …
    
            /* create a back button */
            Elm_Button *btn= elm_button_add(this->getBase());
            evas_object_smart_callback_add(btn, “clicked”, 
                                           [](void *data, Evas_Object *obj, void *event_info) -> void
                                           {
                                               UI_VIEWMGR->popView();
                                           }, this);
    
            /* create content */
            …
            this->setContent(content, “title”, NULL, btn, NULL);
        }
    };
    

  • View title
  • class page: public UiStandardView { void onLoad() { /* create content */ … this->setContent(content, “title”); /* Sub title */ this->setSubtitle(“subtitle”); /* Title Left Button */ Elm_Button *leftBtn= elm_button_add(this->getBase()); this->setTitleLeftBtn(leftBtn); /* Title Right Button */ Elm_Button *rightBtn= elm_button_add(this->getBase()); this->setTitleRightBtn(rightBtn); /* or you could use this, this->setContent(content, “title”, “subtitle”, leftBtn, rightBtn); */ } };


  • View indicator
  • class page1: public UiStandardView { void onLoad() { … this->setIndicator(UI_VIEW_INDICATOR_DEFAULT); /* You could use one of below items. UI_VIEW_INDICATOR_DEFAULT, UI_VIEW_INDICATOR_OPTIMAL, UI_VIEW_INDICATOR_OVERLAP, UI_VIEW_INDICATOR_HIDE, UI_VIEW_INDICATOR_SHOW, */ } }; class page2: public UiStandardView { void onLload() { … this->setIndicator(UI_VIEW_INDICATOR_OVERLAP); } }; //UI View Manager will recover the indicator status when it goes back to page 1 from page 2


  • View transition effect
  • class page: public UiStandardView { void onLoad() { … this->setTransitionStyle(“fade”); } };


  • Menu popup
  • class page: public UiStandardView { void onMenu(UiMenu *menu) { UiStandardView::onMenu(menu); Elm_Ctxpopup *ctxpopup = elm_ctxpopup_add(menu->get_base()); elm_ctxpopup_item_append(ctxpopup, "Phone calls", NULL, ctxpopup_item_select_cb, this); elm_ctxpopup_item_append(ctxpopup, "Favorites", NULL, ctxpopup_item_select_cb, this); elm_ctxpopup_item_append(ctxpopup, "Search", NULL, ctxpopup_item_select_cb, this); elm_ctxpopup_item_append(ctxpopup, "Dialer", NULL, ctxpopup_item_select_cb, this); menu->setContent(ctxpopup); } };


  • Popup
  • void createPopup(page *view) { UiPopup *popup = new UiPopup(view); Elm_Popup *obj = elm_popup_add(popup->getBase()); elm_object_text_set(obj, "This popup has only text which is set via desc set function, (This popup gets hidden when user clicks outside) here timeout of 3 sec is set."); popup->setContent(obj); popup->activate(); } class page: public UiStandardView { void onBack() { /* Do something */ UiStandardView::onBack(); } };


  • Back Event
  • class page: public UiStandardView { void onBack() { /* Do something */ UiStandardView::onBack(); } };