Problem: When using the TimePicker & DatePicker objects in an AlertDialog (and probably anywhere else), the time & date seem to not to update when the user is editing the value using a keyboard (or soft keyboard).
Solution: Before calling the functions to get the date & time from the objects call TimePicker or DatePicker clearFocus() method.
I found few threads talking about this problem without a solution. I found the solution when I looked at the TimePickerDialog source code which did not suffer from this problem.
Friday, January 21, 2011
Android SQLite Alter Table
When upgrading SQLite database sometimes you need to change the tables scheme. The problem is that SQLite Alter Table SQL format does not support all the options you might need (specifically - dropping columns, changing column types, renaming columns).
One way around this issue is to create a new table & copy the data to the new table. There are few options here, but the best way (I think) is as follows:
1. Create new table in the new format.
2. Copy the data.
3. Drop the original table
4. Rename the new table
For example:
IMPORTANT: As far as I know 'execSQL' of 'SQLiteDatabase' will NOT run multiple commands. You should run each SQL command in a separate 'execSQL' call (the transaction can be handled from the SQLiteDatabase, not need for explicit SQL commands).
One way around this issue is to create a new table & copy the data to the new table. There are few options here, but the best way (I think) is as follows:
1. Create new table in the new format.
2. Copy the data.
3. Drop the original table
4. Rename the new table
For example:
BEGIN TRANSACTION;
CREATE TABLE t_new(a,b);
INSERT INTO t_new SELECT a,b FROM t;
DROP TABLE t;
ALTER TABLE t_new RENAME TO t;
COMMIT;
IMPORTANT: As far as I know 'execSQL' of 'SQLiteDatabase' will NOT run multiple commands. You should run each SQL command in a separate 'execSQL' call (the transaction can be handled from the SQLiteDatabase, not need for explicit SQL commands).
Thursday, January 20, 2011
Build.VERSION.SDK_INT on Android 1.5
It won't be long before all Android 1.5 devices will disappear, until then it's a good idea to support them. The problem is the 'Build.VERSION.SDK_INT' was introduced only on Android 1.6, and before that there were only string values.
Here's a work-around this issue - it will return the correct value for Android 1.5+:
Note: the internal class is required since the Java virtual machine checks if a class is valid before loading it. In our case, a java VM running Android 1.5 will not be able to load Build.VERSION.SDK_INT and will crash.
UPDATE: Added VerifyError catch to prevent exceptions on some weird Android 1.5 devices.
Here's a work-around this issue - it will return the correct value for Android 1.5+:
public static int getSdkInt() {
if (Build.VERSION.RELEASE.startsWith("1.5"))
return 3;
try {
return HelperInternal.getSdkIntInternal();
} catch (VerifyError e) {
return 3;
}
}
private static class HelperInternal {
private static int getSdkIntInternal() {
return Build.VERSION.SDK_INT;
}
}
Note: the internal class is required since the Java virtual machine checks if a class is valid before loading it. In our case, a java VM running Android 1.5 will not be able to load Build.VERSION.SDK_INT and will crash.
UPDATE: Added VerifyError catch to prevent exceptions on some weird Android 1.5 devices.
Labels:
Android
Subscribe to:
Posts (Atom)