Building UI Components Димитър Н. Димитров Astea Solutions AD

In a nutshell XML and Java Views and Layouts Displaying data and Adapters Menus Events and handling user interaction App Widgets (not android.widget.*)

Declarative way for defining UI – allows clearer separation between view and controller – arguably, better for visualizing and “getting” fairly complex UI – arguably, you need to write less with XML-based UI Resource-based way for defining UI – allows greater flexibility rely on the system to choose which of all the defined layouts to use, depending on the device configuration – allows better reusability XML Layout

Java Layout OK, in some cases when adding views dynamically – still, try ViewStub first Defining your own custom component doesn’t count – you can still add it to your layout via XML Java and views mix, but not for layout declaration UI event handling complex operations on views manually inflating XML views Don’t overindulge your “coder” dark side

Where it all starts... android.view.View – the granddaddy of all views (even ViewGroup) – occupies rectangular area on the screen – Android measures, lays out and draws views for you top-down measure phase top-down layout phase drawing phase android.view.ViewGroup – the granddaddy of all container views – usually subclassed for implementing custom layouts

And an arsenal of widgets Widgets: Button TextView, EditText ImageView WebView (technically, a container) MultiAutoCompleteTextView (what a nice name) Containers: FrameLayout RelativeLayout LinearLayout Gallery ListView

Displaying data and Adapters An important question for most of the apps – Q: What’s the best way to display our model data? – A: It depends, but AdapterView is a pretty good bet. Android’s mechanism for data binding, featuring: – AdapterView - a container which creates, initializes and updates (data-wise) its views and handles their interactions – Adapter - the bridge between the existing data and the specific AdapterView we are using to display it setAdapter(), getCount(), getView(), getViewTypeCount()

Menus Options Menu – Activity-specific – Shown when hardware MENU key is pressed – Very important for navigation and for easy access to important screen- or app-specific actions Context Menu – View-specific – Most often used by AdapterView children – Very important for providing item-specific actions (edit/delete an entry from your Contacts, for example)

Events and handling user interaction View event callbacks – Create new listener of the corresponding type Implement the corresponding callback: onClick(), onLongClick(),onFocusChange(),onKey(),onTouch() – Register the corresponding event listener to the view Complex gestures recognition GestureDetector GestureDetector.OnGestureListener GestureDetector.SimpleOnGestureListener

App Widgets Specific embeddable views, which can be used in other apps – update-able, used to show the most relevant data or functionality of your app – think Weather on the Home screen or Music control panel Pros can be very useful for some apps (apply Pareto’s principle to your app) can make your app used more often and improve overall UX Cons you may not need one, if you need one, you should plan for it (design, development) can be a battery eater, if you’re doing it wrong

UI components & your application Test your UI on all devices you are targeting Try to use the built-in views, when possible – yup, their ViewSwitcher is better than yours... Profile your UI with the available Android tools layoutopt and hierarchyviewer to begin with beware of 100+ views or unnecessary layouts Your views should be easy to use and simple – don’t distract your users with overcrowded screens – check

Q&A + Feedback Questions? Feedback section: – Did you hear well? – Was there anything you didn’t understand? – What would you like changed in our next lecture?

Recommended resources ml m View.html View.html ?tag=article ?tag=article (old, but gold)