Using EditText's inputType to control what type of keyboard is shown

As software developers, there are many circumstances in which you'll want to limit the input options available to your users. We've all seen situations along the lines of the person who enters 'two' in a field where we've only been expecting the number 2. Oh how that screws things up! Oh the laughs we've had eh?

Fortunately, in Android it's easy to gently shepherd our precious users to input the sort of data we're expecting, and we do that with the editText's inputType attribute.

You can set your editText inputType as ‘Phone’ for example, and the user can able to type only numbers. If it is ‘Time’ it will allow only time related characters to be entered. Handy eh?

There are many options, and I've included (what I think is) all of them at the end of this post for your pleasure.

In the meantime, here are some examples that will hopefully illustrate this option:

        <EditText android:id="@+id/etWidth1"
            android:hint="@string/widthLabel"
            android:minWidth="75dip"
            android:inputType="textCapWords"
            android:lines="1"
            android:layout_height="wrap_content"
            android:layout_width="wrap_content">
        </EditText>

notice the capitalised first letter of the each sentence, that happens automatically!

        <EditText android:id="@+id/etWidth1"
            android:hint="@string/widthLabel"
            android:minWidth="75dip"
            android:inputType="textCapCharacters"
            android:lines="1"
            android:layout_height="wrap_content"
            android:layout_width="wrap_content">
        </EditText>

        <EditText android:id="@+id/etWidth1"
            android:hint="@string/widthLabel"
            android:minWidth="75dip"
            android:inputType="text"
            android:lines="1"
            android:layout_height="wrap_content"
            android:layout_width="wrap_content">
        </EditText>

ok, so nothing special to see here..

        <EditText android:id="@+id/etWidth1"
            android:hint="@string/widthLabel"
            android:minWidth="75dip"
            android:inputType="phone"
            android:lines="1"
            android:layout_height="wrap_content"
            android:layout_width="wrap_content">
        </EditText>

        <EditText android:id="@+id/etWidth1"
            android:hint="@string/widthLabel"
            android:minWidth="75dip"
            android:inputType="textUri"
            android:lines="1"
            android:layout_height="wrap_content"
            android:layout_width="wrap_content">
        </EditText>

Remember, limiting the allowable input characters is only one part of good design.

You still need to run a sanity check on all fields that allow the user to enter data.

This is absolutely essential in many, many situations. Do a google search for 'sql injection' for more information on how unsafe fields can result in your entire system being vulnerable.

Here is (what I think is) the full list of EditText InputTypes available to you :

text
textCapCharacters
textCapWords
textCapSentences
textAutoCorrect
textAutoComplete
textMultiLine
textImeMultiLine
textNoSuggestions
textUri
textEmailAddress
textEmailSubject
textShortMessage
textLongMessage
textPersonName
textPostalAddress
textPassword
textVisiblePassword
textWebEditText
textFilter
textPhonetic
number
numberSigned
numberDecimal
phone
datetime
date
time

Using spinner.setSelection & finding the spinner doesn't show the selected item when closed?

Ok, I've just spent a couple of hours trying to figure this out, and now I have, I thought I'd share the incredibly simple solution with you.

The issue: I was needing to set a Spinner's selected item via code, but found when calling the Spinner's setSelection method and passing in the position to set it to, something odd would happen, the closed spinner would appear blank, yet, when clicking on it, the item I've asked to be selected would be correctly located at the top of the spinner.

It looks like a Spinner is not told to redraw when using .setSelection(position), what you have to do is call .setSelection(int position, boolean animate) unless you want your selection to happen silently behind the scenes.

Odd, but easily sorted out.

The incredibly simple solution:

This won't show the fact that the Spinner selection has been set:


spnIngredients.setAdapter(ingredientAdapter);
spnIngredients.setSelection(position);

This will:

spnIngredients.setAdapter(ingredientAdapter);

spnIngredients.setSelection(pos, true);

Hope that helps someone out there.
.. Happy Spinning.

Google App Inventor: Android for Beginners for absolute beginners!

Today Google announced a simple-to-use DIY app maker called Google App Inventor.

Google App Inventor brings Android development to non-programmers, employing a design scheme that relies on visual blocks rather than writing pages of code, the App Inventor -- In true Google style, still in Beta, of course -- has functions for just about anything you can do with an Android handset, including access to GPS and phone functionality.

I can imagine this would be fantastic in classrooms.

more information here: http://appinventor.googlelabs.com/about/
complete this form to apply for access: https://services.google.com/fb/forms/appinventorinterest/




Tre Cool!

How to tile a background image in Android

For one of the apps I'm working on I wanted to have a nice pixel pattern tiled behind my widgets.
After a little bit of hunting around I found this tutorial, and I thought I'd clean up the lessons within and show you how.

Here's the contents of my main.xml layout file,

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:background="@drawable/backrepeat"
    android:gravity="center_horizontal"
    >
<TextView  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:text="@string/hello"
    />  

</LinearLayout>

which is referenced in code in the standard way like this:

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

...// (rest of onCreate method continues here..)

Now note this line:

android:background="@drawable/backrepeat"


What's going on there?
.. Glad you asked!

Here's a quick screenshot of the contents of one of my drawable folders in my project:

What is this
backrepeat.xml?

Well, here's the contents of that file here:

<bitmap
xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/scale1"
android:tileMode="repeat"
android:dither="true" />


Can you see what's going on?
Backrepeat.xml defines an instance of the BitmapDrawable class, and that class references our simple scale1.jpg, located in the drawable-hdpi folder.

Simply by adding the:

<bitmap
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/scale1"
    android:tileMode="repeat"
    android:dither="true" />

line in bold, we are able to achieve results such as this:

Easy isn't it?

One thing to keep in mind is that you should have folders drawable-hdpi, drawable-mdpi & drawable-ldpi, you'll need to add this backrepeat.xml file and the relevant images to each of these to allow this functionality in high, medium and low dpi (dots per inch) screen sizes.

Enjoy.

Localisation & Internationalisation on Android, the easy way

You often hear about Internationalisation (internationalization in US English, or i18n for short), and Localisation (Localization in US English, or L10n for short) in software development circles... ever wonder what that's all about?

Of course you do.

Definitions vary, but the basic idea is generally easily summarised:

• Internationalisation is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes.

• Localisation is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text.

These two terms usually go hand-in-hand as the term 'globalisation'. See?
.. Course you do.


Each language is given a language code such as 'en-au' for Australian English, or 'en-us' for American English. These language codes are two-letter lowercase ISO language codes (such as "en") as defined by ISO 639-1.
But how do we use this? And how can we easily apply these concepts to our Android programming?

.. Good question!

Best practices in Android suggests defining all your string resources in a 'strings.xml' file (you're doing this already, right?) and placing that file in the 'res\values' folder in your project.

Localisation in Android is as simple as creating a new version of this file and folder, renaming the 'values' folder to 'values' + the language code you wish to support.

For example, all your Italian translations would be located in 'res\values-it\strings.xml', your Chinese translations in 'res\values-zh\strings.xml' as seen here:

If you don't happen to have a friend from whatever country you're trying to translate your app for, just use Google translate.

Once you're done your app is one simple step away from global domination.

All you need to do is copy those freshly translate strings back into a strings.xml file in Eclipse, and, as long as the folder the strings.xml file is located in has the name of 'values' + the language code you're wishing to support, magically any user who has their phone locale set to a locale that uses that language, your translated strings will be used.

No code changes are required.

Handy eh?