Work around for an Android 2.0 bug - gravity=right make EditText hint disppears

At lease in Vista/Android2.0/Simulator, the hint text you set for an EditText will disppear unexpected if you set the gravity=right at the same time.

I searched on the web and found no solution for it. But some guys thought it's a bug of Android 1.5+.

I tried and found that if the following attribute set at the same time, the hint will come back.
my_edit_text.setSingleLine(false);

But android:singleLine(false) doest not have the same effect.

Layout trick: use layout_weight to strech the view to fill up the screen

My intent was to put a ListView in the top of the screen, 2 buttons in the bottom of the screen.
I hope the 2 buttons could stay put at the bottom, no matter whether List was too short to fill the space left, or too long to have to be scrolled.

The trick was to use layout_weight="1" for the ListView.

<linearlayout android="http://schemas.android.com/apk/res/android" layout_width="fill_parent" layout_height="fill_parent" orientation="vertical">
<listview id="@+id/lv_his_list" layout_width="fill_parent" layout_height="0dip" layout_weight="1" stackfrombottom="true" transcriptmode="normal" choicemode="singleChoice">

<tablelayout layout_width="fill_parent" layout_height="wrap_content" stretchcolumns="0,1">
<tablerow>
<button style="" id="@+id/btn_his_list_modify" text="@string/modify_str">

</button></tablerow>
</tablelayout>

</listview>

Another testing of mine was for TableLayout, it also made sense.

Marquee feature of TextView in Android 1.1R1

In the newest release, Android 1.1 R1, android.widget.TextView begins to support marquee feature.
It provides a value, marquee, for android:ellipsize, and a new attribute, android:marqueeRepeatLimit.

However you could not make the TextView scrolling if you only set these 2 attributes.
According to my testing, at least the following 3 attributes shall be set:
android:ellipsize="marquee"
android:focusable="true"
android:singleLine="true"
And the TextView shall be focused while running.

Moreover, I found 2 limitations in current marquee implementation:

1. Never scroll if the TextView does not get the focuse;
2. The scrolling is odd because the round of scrolling begins from the left side while end at the right side. It looks like the animation is reset.
   

So far, I think my implementation of ScrollTextView is better for the marquee feature. :)

Browse Android Java source codes online

Sometimes, it's necessary for developer to check the implementation of an API when the SDK documentation is not enough for understanding.
However, Android source codes are approximately 2.1G in size. It's not handy to download and browse them in local PC.
Fortunately, source.android.com supports GitWeb for web browsing of the source codes though it's not intuitive to find out which git ball the java code is in.
Some guy find out the path. It is
[platform/frameworks/base.git] / core / java /

Technical Key Points of Androidmine Project

Here are the techincal key points I learned from the open source project, androidmine.
Its current version is 0.7.

1. Customize the activity theme (window without title)
AndroidManifest.xml

<activity android:name=".Main" android:theme="@style/Theme.Game">
...

res/values/styles.xml
<style name="Theme.Game">
<item name="android:windowNoTitle">true</item>
</style>

2. Set the conent view for the activity
Use android.app.Activity.setContentView(View view) to set the activity content to an explicit view. This view is placed directly into the activity's view hierarchy. It can itself be a complex view hierarhcy. By this way, you can switch any view you want to show.
Overwrite onLayout, onDraw to customize the view
Overwrite onKeyUp, onKeyDown and onTouchEvent to handle the user input
Call invalidate in the UI thread, or postInvalidate in the non-UI thread to make the onDraw called

3. Use android.os.Handler to send and handle messages, schedule an action in the feature

4. Use android.media.MediaPlayer to play background music in a separated thread

Dimension Values of Android API

The document of Android API 1.0 rc2

You can create common dimensions to use for various screen elements by defining dimension values in XML. A dimension resource is a number followed by a unit of measurement. For example: 10px, 2in, 5sp. Here are the units of measurement supported by Android:
px
Pixels - corresponds to actual pixels on the screen.
in
Inches - based on the physical size of the screen.
mm
Millimeters - based on the physical size of the screen.
pt
Points - 1/72 of an inch based on the physical size of the screen.
dp
Density-independent Pixels - an abstract unit that is based on the physical density of the screen. These units are relative to a 160 dpi screen, so one dp is one pixel on a 160 dpi screen. The ratio of dp-to-pixel will change with the screen density, but not necessarily in direct proportion. Note: The compiler accepts both "dip" and "dp", though "dp" is more consistent with "sp".
sp
Scale-independent Pixels - this is like the dp unit, but it is also scaled by the user's font size preference. It is recommend you use this unit when specifying font sizes, so they will be adjusted for both the screen density and user's preference.

My understanding
px, in, mm and pt are all absolute units.
px is based on the resolution of the screen.
in, mm and pt are based on the physical size of the screen.
dip/sp can accommodate size with the resolution to make it appear exactly the same size.

Here's the comment got from reply in the android developer group:
[Romain Guy]

If you specify, in your application, a button with a width of 100
pixels, it will look at lot smaller on the 640x480 device than on the
320x480 device. Now, if you specify the width of the button to be 100
dip, the button will appear to have exactly the same size on the two
devices.

You can easily see this happen when you compare the T-Mobile G1 with
the Android emulator. Computer monitors usually have low/medium pixel
densities. For instance, the monitor I'm using to write this email has
a density of about 100 pixels per inch, whereas the G1 has about 180
pixels per inch. This means that when I compare my application on the
G1 with my application on the Android emulator on my computer, the
version on my computer appears a lot bigger to me.

It is very important that you use resolution independent units like
dip when you create your UI. This well help make your application run
on future Android devices that may or may not have the same pixel
density as the G1.
If you specify, in your application, a button with a width of 100
pixels, it will look at lot smaller on the 640x480 device than on the
320x480 device. Now, if you specify the width of the button to be 100
dip, the button will appear to have exactly the same size on the two
devices.

You can easily see this happen when you compare the T-Mobile G1 with
the Android emulator. Computer monitors usually have low/medium pixel
densities. For instance, the monitor I'm using to write this email has
a density of about 100 pixels per inch, whereas the G1 has about 180
pixels per inch. This means that when I compare my application on the
G1 with my application on the Android emulator on my computer, the
version on my computer appears a lot bigger to me.

It is very important that you use resolution independent units like
dip when you create your UI. This well help make your application run
on future Android devices that may or may not have the same pixel
density as the G1.

The conclusion is that you should use dip/sp as many as possible unless you have solid reason to use the other dementions instead.
In development you can also telnet to the simulator (telnet localhost 5554) to use the 'window scale' command to change the screen density to verify if your application can accomadate with various screens.

References:
1. http://vod.sjtu.edu.cn/help/Article_Show.asp?ArticleID=308&ArticlePage=11.
2. http://baike.baidu.com/view/49853.html
3. http://fbljava.blog.163.com/blog/static/26521174200871383754608/#
4. http://groups.google.com/group/android-developers/browse_thread/thread/978813b2998ef439/f63e4e51bdb2e2d5#f63e4e51bdb2e2d5

find out the version of ksh/dtksh in Solaris

It took me quite some minutes to find out in Google how to find out the versions of ksh and dtksh in Solaris.

1. Start a shell
$ ksh
or
$ dtksh
2. Enter vi mod
$ set -o vi
Note: The option is letter 'o' , not number zero "0".
3. Press ESC to enter command mode
4. Press Ctrl-V

Here are outputs in Solaris 8 & 9
$ Version M-11/16/88
$ Version M-12/28/93