Android Programming: Lecture 02


Published on

1) Developing for Mobile Devices: Best Practices
2) Developing for Android: Best Practices
3) User Interfaces: Views, Layouts, Code vs. XML

Published in: Software, Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Android Programming: Lecture 02

  1. 1. Android Programming Lecture 02 Vladimir Kulyukin Department of Computer Science Utah State
  2. 2. Resources Source code and screencasts for this lecture are at
  3. 3. Outline ● Developing for Mobile Devices: Best Practices ● Developing for Android: Best Practices ● User Interfaces – Views – Layouts – Code vs.
  4. 4. Developing for Mobile Devices: Best
  5. 5. General Remarks ● In a pedagogical context, efficiency is necessarily compromised for the sake of clarity ● This compromise should not be considered as the “do as I say, not as I do” approach: the first step toward mastery is understanding; some low level details must take the back seat for the time being ● I also subscribe to the SE principle that “early optimization is the root of all evil”: high level objectives and flexibility are often lost when optimization becomes the primary focus early
  6. 6. Hardware Constraints ● Compared to their desktop and laptop counterparts, mobile devices have – Low processing power – Limited RAM – Limited permanent storage – Small screens with low resolution – High data transfer costs – Slow data transfer rates – Unreliable data connections – Limited battery
  7. 7. Efficiency ● Mobile device manufacturers generally prefer small sizes and longer batter lives to processor speed improvements ● To mobile developers this preferences translates to the occasional invalidity of Moores law (number of transistors doubles on an integrated circuit every 2 years) ● A safer bet for mobile developers is increased power efficiency without significant increases in processor
  8. 8. Limited Storage ● Most of the available storage on mobile devices goes to music and movies, which leaves limited space to third-party applications ● Android devices require that applications be installed on the internal memory (e.g., an application cannot run off the external SD card) ● Consequently, the size of your compiled application matters: – Use native Android frameworks (e.g., content providers) to persist, reuse, and share data – Clean up: do not leave files in the file system or records in a database when they are not
  9. 9. Small Screens ● Users are demanding more and more information-rich GUI experience ● This demand is a challenge for small screens ● Several assumptions and recommendations ASSUMPTION RECOMMENDATION User will only glance at your GUI Reduce number of widgets User will relate to intuitive layouts Put most important widgets in the center User will unlikely use a stylus Make your views big enough to support touch User will use different screen resolutions Make your GUIs scale on larger
  10. 10. Low Speed, High Latency ● Mobile connections are not as fast, reliable, or available (3G, 4G, and citywide WiFi are slowly changing this assumption) ● It is safe (at least, for now) to assume that your connection will be slow, intermittent, and expensive (in Eclipse IDE, you can simulate it by opening DDMS perspective, finding Emulator Control, and setting Latency to EDGE) ● It is safe to assume that applications will lose data or will not find it when it is required ● It is sometimes the best to limit the functionality of your
  11. 11. Costs ● Data transfer services, such as SMS and Geocoding, come at a price ● It is important to minimize data transfer costs associated with your application ● Some generic guidelines: – Transfer as little data as possible – Cache data – Stop data transfer when your application is not visible – Keep data update rates low – Expose data transfer rates and costs through user
  12. 12. Respect Users Environment ● Never assume that your application is the most important feature on the device ● To most users, a smart phone is firstly a phone, secondly an SMS and email processor, thirdly a camera, and fourthly a music/movie player ● Your application should be: – Well behaved: does not waste cycle when invisible, switches seamlessly from foreground to background – Polite: does not interrupt current activities – Consistent: presents consistent Uis and data formats – Responsive: does not freeze due to lack of
  13. 13. Developing for Android: Best
  14. 14. Android-Specific Tips ● Efficiency ● Responsiveness ● Security ● Seamless user
  15. 15. Efficiency ● Some Android efficiency tips are in conflict with well established SE design practices, e.g., avoiding setters and getters in your classes and using interfaces or virtual classes ● Conventional design practices, such as advocated and practiced by SE gurus, must sometimes be compromised for the sake of efficiency ● But, as you go through the class notes, presentations, and screencasts, bear in mind the pedagogical tradeoff between clarify and efficiency!
  16. 16. Responsiveness ● Android enforces responsiveness through the Activity Manager and Window Manager services ● If either service detects an unresponsive application, it displays a Force Close dialog box to the
  17. 17. Responsiveness ● Android monitors two conditions to determine responsiveness – Application must response to a user action within five seconds – Broadcast receiver must return from its onReceive() handler within ten seconds ● Likely culprits in low responsiveness – Network lookups – Complex processing (gaming, computer vision) – I/
  18. 18. Security ● Android basic premise: users take responsibility for the applications they install ● Some development tips and practices – Require permissions for intents and broadcasts – Handle with care inputs from external resources such as Internet, SMS, IM, etc – Avoid exposing access to low-level hardware through your application ● Caveat: because we are in a classroom, we will take a rather weak approach to security, but that does not make it any less
  19. 19. Seamless User Experience (UE) ● UE is a rather foggy and fuzzy concept ● In many contexts, it stands for consistency in applications starting, stopping, and transitioning without noticeable delays ● Several development tips and practices: – Persist data between sessions – Suspend tasks when invisible – De-emphasize “revolutionary” and “unfamiliar” and emphasize “cooperative” and “easily recognizable”
  20. 20. User
  21. 21. View ● A View is a UI building block: a text view (label), a edit text view (text frame/box), a button, a radio button view, etc ● Views are hierarchical objects that know how to draw themselves ● The easiest way to test basic views is through
  22. 22. XML-Based GUI Design ● The most important step to mastering XML-Based GUI design is to relate visual GUIs with XML code that underlines them ● Why care about XML-Based GUI Design? ● It is not just Android! Some examples: – Microsofts Extensible Application Markup Language (XAML) – Adobes Flex – Mozillas XML User Interface Language (XUL)
  23. 23. Views Fill Models● A fill model specifies how much space a view (widget) can take in its parent container● Three possibilities: – Specific hardcoded dimension: 50px – wrap_content: the widget can fill up its natural space, if it is too big, Android will use word wrap – match_parent: fill up all available space in its container after all other widgets are
  24. 24. Text View: /layout/
  25. 25. Text View: /layout/text_view_00.xml <?xml version="1.0" encoding="utf-8"?> <TextView xmlns:android="" android:layout_width="match_parent" android:layout_height="match_parent" android:text="I am a Text View!" android:textSize="40px" > </TextView>
  26. 26. Button View: /layout/
  27. 27. Button View: /layout/button_00.xml <?xml version="1.0" encoding="utf-8"?> <Button xmlns:android="" android:layout_width="match_parent" android:layout_height="match_parent" android:text="I am a Button!" android:textSize="20px" > </Button>
  28. 28. Button View: /layout/
  29. 29. Button View: /layout/radio_button_00.xml <?xml version="1.0" encoding="utf-8"?> <RadioButton xmlns:android="" android:layout_width="match_parent" android:layout_height="match_parent" android:text="I am a Radio Button!!!" android:textSize="20px" > </RadioButton>
  30. 30. Containers ● Basic views (text views, edit texts, buttons, radio buttons, etc) do not exist by themselves: they go into containers ● Containers are sometimes referred to as box models ● Android has several containers: the most common are LinearLayout, RelativeLayout, and TableLayout (aka, a grid)
  31. 31. LinearLayout ● LinearLayout is by far the most common container used in Android UIs (probably because it provides for simple, intuitive interfaces consisting of item lists) ● LinearLayout has five main properties that the UI designer can manipulate through XML or source code: 1) orientation; 2) fill; 3) weight; 4) gravity; and 5)
  32. 32. LinearLayout: Orientation ● This property specifies whether a LinearLayout object functions as a row or as a column ● If the value of the property is VERTICAL, the object is a column ● If the value of the property is HORIZONTAL, the object is a
  33. 33. LinearLayout: Fill ● Hardcode specification ● WRAP_CONTENT ● MATCH_PARENT (this used to be FILL_PARENT)
  34. 34. LinearLayout: Weight ● Weight is important when several widgets must split the available space ● android:layout_weight property indicates the proportion of the free space the widget should take ● Make sure that all widget weights add up to
  35. 35. LinearLayout: Gravity ● The gravity property specifies how the widget should be aligned on the screen (inside its container) ● Some common gravity values are left, center_horizontal, center_vertical, and right ● Make sure that all widget weights add up to
  36. 36. LinearLayout: Padding ● The padding property comes in handy when widgets are tightly clustered inside a container ● android:padding allows you to manipulate the white space between widgets ● You can be use android:paddingLeft , android:paddingRight , android:paddingBottom , android:paddingTop to control the padding on the corresponding sides of the
  37. 37. UI Harness Project: Basic Views ● Let us create a project that allows us to create, customize, and test various basic views ● All XML documents must be placed in /res/layout ● Make sure that you compile the project after create each XML resource file so that the layout constants are updated in
  38. 38. UI Harness Project: LinearLayout Views ● Let us continue with our UI Harness Project to create, customize, and test various
  39. 39. LinearLayout: /layout/
  40. 40. LinearLayout: /layout/layout_00.xml <LinearLayout xmlns:android="" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical"> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" android:text="@string/text_view_txt"/> <EditText android:layout_width="match_parent" android:layout_height="wrap_content" android:text="I am an edit text!!!"/> </LinearLayout>
  41. 41. Three Basic UI Development Steps ● Design UI (use a software tool or pencil and paper) ● Implement UI (code or XML or both) ● Attach event handlers to various
  42. 42. Display Date
  43. 43. The Point of the Project ● Tradeoffs b/w developing GUIs in code vs XML ● GUIs can be built in three ways: – Code – XML – Mix of code and
  44. 44. Feedback Bugs, errors to vladimir dot kulyukin at gmail dot
  45. 45. Reading Suggestions ● ● ● ● Chapters 1 & 2 in Rito Meiers Professional Android 2 Application