Android Debug Bridge via Command Line, MobAppDev Best Practices, UI Development


Published on

Android Debug Bridge via Command Line, MobAppDev Best Practices, UI Development

Published in: Software
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Android Debug Bridge via Command Line, MobAppDev Best Practices, UI Development

  1. 1. Android Programming Android Debug Bridge via Command Line MobApDev Best Practices UI Development Vladimir Kulyukin
  2. 2. Outline ● Android Debug Bridge (ADB) via Command Line ● MobAppDev Best Practices ● UI Development – Views & Containers – Common view properties – Android UI measurement units – Programmatic vs Declarative UI Development: Code vs XML – International Date Display Application
  3. 3. ADB via Command Line
  4. 4. ADB is now in /platform-tools
  5. 5. ADB is now in /platform-tools 1) List devices connected to the computer 2) Connect to the device and list all processes running on it 3) List contents of the current directory
  6. 6. MobAppDev Best Practices
  7. 7. Hardware Constraints ● Compared to their desktop & 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 life
  8. 8. Efficiency ● Mobile device manufacturers generally prefer small sizes and longer battery lives to processor speed improvements ● To mobile developers such preferences translate 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 power
  9. 9. Efficiency ● Some Android efficiency tips are in conflict with well established design practices, e.g., avoiding setters and getters ● Conventional design practices, such as advocated and practiced by software engineering gurus, are compromised for the sake of efficiency ● But bear in mind the classic tradeoff between clarity and efficiency
  10. 10. Limited Storage ● Most of the available storage on mobile devices goes to music and movies ● Android devices require that applications be installed in the internal memory (apps cannot run from the external SD card) ● Consequently, the size of compiled apps matters: – Use native Android frameworks (e.g., content providers, SQLite, SharedPreferences) 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 needed
  11. 11. Small Screens ● Users are demanding more and more information- rich UI 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 displays
  12. 12. Responsiveness ● Android forces apps to be responsive through the Activity Manager and Window Manager services ● If either service detects an unresponsive application, it displays a Force Close dialog box
  13. 13. Responsiveness ● Android monitors two conditions to determine responsiveness – App must respond to a user action within five seconds – Broadcast receiver must return from its onReceive() handler within ten seconds ● Likely culprits in low responsiveness – Network downloads – Complex processing (gaming, image processing) – I/O
  14. 14. Security ● Android basic premise: users take responsibility for the apps they install ● Some best AppDev practices – Require permissions for intents and broadcasts – Handle with care inputs from external resources such as Web, SMS, IM, etc – Avoid exposing access to low-level hardware through your apps ● Caveat: because we are in a classroom, we will take a weak approach to security, but that does not make it any less important
  15. 15. 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 still safe 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 application then have many bells and whistles fail at run time
  16. 16. Costs ● Data transfer services, such as SMS and Geocoding, are not free ● Generic data transfer cost minimization guidelines: – Transfer as little data as possible – Cache data – Stop data transfer when your app is invisible – Keep data update rates low – Expose data transfer rates and costs through user preferences
  17. 17. Respect Users Environment ● Never assume that your app is the most important feature on the device: to most users, a smartphone is firstly a phone, secondly an SMS and email processor, thirdly a camera, and fourthly a media player ● Consequently, your app should be: – Well behaved: does not waste cycles 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 data
  18. 18. Seamless User Experience (UE) ● UE is a fuzzy concept ● In many contexts, it stands for consistency in your apps starting, stopping, and transitioning without noticeable delays ● Several tips: – Persist data between sessions – Suspend tasks when they are invisible – De-emphasize “revolutionary” and “unfamiliar” and emphasize “cooperative” and “easily recognizable”
  19. 19. UI Development
  20. 20. Android Views ● Android GUI widgets are called views (text views, edit texts, buttons, radio buttons, etc) ● Views are grouped into containers (aka box models) ● Common containers are LinearLayout, RelativeLayout, and TableLayout (aka, a grid)
  21. 21. LinearLayout ● LinearLayout is one of the most common containers 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) padding
  22. 22. Orientation Property ● This property specifies whether a View 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 row
  23. 23. Fill Model Property ● A Views fill model specifies how much space the view can take in its parent view ● Three possibilities: – hardcoded dimension: 50px – wrap_content: view can fill up its natural space; if it is too big, word wrap will be used – match_parent: fill up all available space in its parent after all other viewss are handled
  24. 24. Weight Property ● This property indicates the proportion of the free space the widget should take ● This property is important when several widgets must split the available space inside a container ● For example: several buttons inside a LinearLayout
  25. 25. Gravity Property ● The gravity property specifies how the widget should be aligned on the screen (inside its container) ● Some common gravity values are – left – right – center_horizontal – center_vertical
  26. 26. Padding Property ● 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 use – android:paddingLeft – android:paddingRight – android:paddingBottom – android:paddingTop
  27. 27. Android UI Measurement Units ● PIXEL – dot on screen ● IN – inches ● MM – millimeters ● PT – point – 1/72 of 1 inch ● DP – density independent pixel (DP is a unit on a 160 dpi screen: 1 dp is 1 pixel on a 160 dpi screen) ● DIP – synonym for DP ● SP – scale-independent pixel, similar to DP but scalable by users
  28. 28. DP vs SP ● DP has constant ratio to PX: DP = PX * RATIO ● RATIO stays constant regardless of the device ● SP has scalable ratio to PX: DP = PX * RATIO * SCALE, where RATIO is constant but SCALE can be set by user ● Usage guideline: use SP for font sizes and DP/DIP for everything else
  29. 29. Declarative and Procedural UI Development ● Declarative development consists of specifying GUI element in some formal language (XML) and then attaching back end code to consume GUI events (clicks, scrolls, taps, etc.) ● Procedural/Programmatic development consists of coding everything in some programming language (e.g., java.swing.* or java.awt.*) ● Mixed development consists of designing all gadgets in XML and attach code to implement UI logic
  30. 30. XML-Based UI Design ● The most important step to mastering XML-Based GUI design is to relate visual GUIs with XML code that defines them ● XML specs are used to construct GUI objects they specify via XML inflation ● Why care about XML-Based GUI Design? ● It is not just for Android: – Microsofts Extensible Application Markup Language (XAML) – Adobes Flex – Mozillas XML User Interface Language (XUL)
  31. 31. XML Inflation <Button android:id=”@+id/button_one” style=”@style/my_button_style” android:layout_width=”wrap_content” android:layout_height=”wrap_content” android:text=”@string/button_one_text” /> // XML inflation of the Button View defined above protected Button mButtonOne = null; mButtonOne = (Button) findViewById(;
  32. 32. International Date Display App on Gingerbread & Jelly Bean source code at InternationalDateDisplayOnAndroid
  33. 33. App Specs ● Develop an application that consists of one activity that displays three buttons: one for US locale, one for Italy locale, and one for France locale ● A click on a button displays in the screen the current date according to the rules of the specific locale ● The app should use a vertical LinearLayout to arrange its components ● Dates should be displayed in an EditText ● Buttons should be arranged in a horizontal LinearLayout ● EditText and LinearLayout with buttons should have image backgrounds
  34. 34. Sample Screenshots 1 2 3 4
  35. 35. Activity Views
  36. 36. References ● ● ● ●
  37. 37. Feedback Bugs, errors to vladimir dot kulyukin at gmail dot com