Skip to content

Instantly share code, notes, and snippets.

@nesquena
Last active December 24, 2015 20:39
Show Gist options
  • Save nesquena/2e76670cfb4e751caf95 to your computer and use it in GitHub Desktop.
Save nesquena/2e76670cfb4e751caf95 to your computer and use it in GitHub Desktop.
Android Project 1: Tip Calculator Feedback Guide

Project 1: Tip Calculator Feedback

This is the feedback guide for Project 1 - Tip Calculator. It covers the key issues that we see most often when engineers submit this homework.

  • Did you name your Java activity semantically? Your Java Activity should have a name like TipCalculatorActivity with the Activity suffix.

  • Did you name your XML Layout file properly? Your XML Layout should have a name such as activity_tip_calculator.xml that matches the name of your Java class.

  • Did you properly name your views? Every view in your layout XML file should have a proper id that semantically describes the purpose AND have a prefix indicating the view type. For example, the text field where you enter the total amount might be called etTotalAmount. et indicates this is an EdiText and the TotalAmount indicates the purpose of this textfield.

  • Did you use relative sp / dp for any view units? All units within XML layouts should be relative using sp for font sizes and dp for margin+padding and any other positioning. You should also use wrap_content and match_parent for width/height whenever possible. Check out this stackoverflow answer for more detail about these units. Avoid ever using px or pt in Android apps.

  • Did you properly apply relative placement rules in a RelativeLayout? Learning RelativeLayout rules is one of the most important parts of learning about Android views. Switch to the XML view for your activity layout and notice the rules that are applied to position your views. Read more about this in our RelativeLayout Cliffnotes.

  • Did you use string resources for your text? In Android, you should always use string resources for your text rather than hardcoding string values in your layout files. See our using string resources for more details.

  • Do your EditText fields specify the expected input type? EditText fields should be sure to specify their inputType whenever applicable to help avoid invalid input and help the device select the correct soft keyboard i.e android:inputType="numberDecimal"

  • Does your application report correct tip values when each button is pressed? If I enter the total amount, can I select each amount and correctly see the tip displayed?

  • How did you attach click handlers to your buttons? In Android apps, you can attach click handlers using both Java with setOnClickListener or in the XML with android:onClick property. For these preset tip percent buttons, consider using the xml proprty for cleaner attaching of the click events.

  • How did you manage the click handler behavior for the three buttons? Did you avoid duplication? One common issue with the button handlers is avoiding duplication. You don't want to have three methods (one for each tip value) that all do the exact same thing. One strategy for click handling is to avoid having three different methods like "setTenPercentTip". Instead a common pattern in Android is to use android:tag which allow you to store metadata embedded in the view. Then you can use a single method for onClick for all three buttons and use the View v signature to differentiate the value based on id or tag. This is a way to reduce duplication and is a frequent pattern used for click handling. More details in this stack overflow answer.

  • Did you consider invalid input cases? Is your application robust to invalid input? What happens if I don't enter any value for total amount and hit one of the buttons? Your applications should always be robust to invalid input. Consider disabling the buttons until an amount is entered (optional) or checking if the amount is entered and displaying a Toast to let the user know to enter an amount.

Bonus

In addition, consider the following bonus (optional) feedback:

  • Did you consider the Soft Keyboard? On a real device, the tip calculator will have odd behavior surrounding the "soft" or virtual keyboard. On the emulator, no virtual keyboard is shown but if you are interested about how to manage the virtual keyboard on real devices, check out our Soft Keyboard guide.

  • Could you improve the UX? In all of these assignments, there are key places where you have the opportunity to improve the UI and UX of these projects. For example, it would be nice if as I updated the "total amount", the tip value would be automatically recalculated using a text changed listener or the onEditorAction listener.

  • Could you improve the UI? It might be nice for the user to be able to select a custom tip value in addition to the presets. Which view control might be well-suited for allowing the user to select any tip value from 1%-100%? NumberPicker might be one possibility but there are others. You also might consider trying a SeekBar instead. See what feels right for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment