I think there might be better and easier ways to implement these kinds of an Android mobile form for different devices like Smartphones and Tablets because mine seems to me relative complicated and error-prone. Despite I want to share with you my implementation experiences, maybe my readers can leave me better solutions in the comments section and I can grow and learn.
First of all I start with the Layout implementation. LinearLayouts and GridLayouts I did already use for the Layout of the start screen in the Fitness Manager App. The GridLayout contains the raw design definitions for the Android mobile form. The fine tuning of the design is handled again by LinearLayouts using the layout attributes layout_sum and layout_weight. Additionally to the XML Layout definition the items of the View must be adapted to the display size of the Android device programmatically in the activity. Similar to the implementation of the start screen I added runnables to the layout queue. In these runnables I could request the width and height of single view elements, the DisplayMetrics of the Android device and set the LayoutParams of every view element. In the code snippet below the underlying ScrollView is resized within the runnable. The displayed example for view adaption was also useful for layout adaptions within onConfigurationChange and onResume. Still I'm not sure if this is the best and correct way to adapt views and layouts to different Android devices.
Additionally to the layout requirements I had different requirements concerning the behaviour of the single view elements.
1. The inputTypes of the EditTexts must be set. This is handled in the XML layout definition of the view elements. There are several options for inputTypes like TextCapSentences, TextAutoCorrect, TextMultiLine or number. The inputType of the Android EditText does influence the input of the EditText as well as the behaviour and display of the virtual keyboard.
2. The Save-Button should be only enabled and clickable if the user entered a name in the corresponding Android EditText. Furthermore the design of the button should be different in this two states. In the XML Layout definition I did set the corresponding attribute of the ImageButton android:clickable to false but this was not sufficient.
I also had to disable the Save-Button programmatically in the onCreate function of the activity.
Furthermore I had to implement an Android EditText addTextChangedListener that toggeled the ImageButton depending on the input of the EditText for the name. The implementation of the Android EditText addTextChangedListener is not necessary but the other option is to check the value of the EditText in every ActionListener of every single view element in order to prevent the user to save an object with an empty name.
3. If EditTexts are used in a mobile form, it is often necessary to check the value of the EditText when the user finished the input. This is handled by implementing an Android EditText setOnEditorActionListener. Therefore the XML Layout definition of the EditText must contain the attribute android:ImeOptions with it's value set to actionDone. The important issue concerning Android EditText setOnEditorActionListener is the handling of the virtual keyboard. The virtual keyboard must be closed programmatically within the ActionListener. This is realized by using the InputMethodManager.
4. Often the input of EditTexts is limited by constraints. In order to indicate the constraints of an EditText politely to the user, an Android AlertDialog can be used. An Android AlertDialog can contain one or more Buttons with different possible options for the behaviour of the activty.
If you have any questions, any improvement suggestions for the implementation (I mentioned that this is my first Android App) or any improvement suggestions for my English, I really would appreciate if you can leave me a comment.
Follow us onFacebook