![]() |
| Could not open the editor. |
![]() |
| Problem Solution |
![]() |
| Could not open the editor. |
![]() |
| Problem Solution |
package com.blogspot.android_by_example.notepad;The code looks quite big but actually there is nothing special here. We create static subclass of SQLiteOpenHelper and implement abstract methods onCreate() and onUpgrade(). The onCreate() method is invoked when there is no database available for our app, so in this method we have to execute all the statements to create our database. onUpgrade() is invoked when the version of the current database version is smaller than new version (database version is provided when SQLiteOpenHelper subclass instance is created and this version is passed as a parameter to a superclass constructor).
import android.content.Context;
import android.database.SQLException;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
import android.util.Log;
public class NotesDbAdapter {
public static final String COLUMN_TITLE = "title";
public static final String COLUMN_BODY = "body";
public static final String COLUMN_ID = "_id";
public static final String TAG = NotesDbAdapter.class.getSimpleName();
private DatabaseHelper mDbHelper;
private SQLiteDatabase mDb;
private static final String DATABASE_NAME = "notes.db";
private static final String TABLE_NAME = "notes";
private static final int DATABASE_VERSION = 1;
private static final String DATABASE_CREATE =
"create table notes (_id integer primary key autoincrement, "
+ "title text not null, body text not null);";
private final Context mContext;
private static class DatabaseHelper extends SQLiteOpenHelper {
DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(DATABASE_CREATE);
Log.d(TAG, "onCreate() database");
}
@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
db.execSQL("DROP TABLE IF EXISTS notes");
onCreate(db);
Log.d(TAG, "onUpdate() database");
}
}
public NotesDbAdapter(Context context) {
this.mContext = context;
}
public NotesDbAdapter open() throws SQLException {
mDbHelper = new DatabaseHelper(mContext);
mDb = mDbHelper.getWritableDatabase();
return this;
}
}
package com.blogspot.android_by_example.notepad;
import android.os.Bundle;
import android.app.Activity;
public class NotesListActivity extends Activity {
private NotesDbAdapter mDbHelper;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_notes_list);
mDbHelper = new NotesDbAdapter(this);
mDbHelper.open();
}
}
/data/data/<package_name>/databases/<database_name>So in our case the database will be located at:
/data/data/com.blogspot.android_by_example.notepad/databases/notes.db
| Database file location |
C:\Users\Taras Osiris>adb shell
root@android:/ # sqlite3 /data/data/com.blogspot.android_by_example.notepad/databases/notes.db
.android_by_example.notepad/databases/notes.db <
SQLite version 3.7.11 2012-03-20 11:35:50
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>adb [-d|-e|-s <serialNumber>] shell
sqlite> INSERT INTO notes (title, body) VALUES ("Title1", "Body1");
INSERT INTO notes (title, body) VALUES ("Title1", "Body1");
sqlite> INSERT INTO notes (title, body) VALUES ("Title2", "Body2");
INSERT INTO notes (title, body) VALUES ("Title2", "Body2");
sqlite> INSERT INTO notes (title, body) VALUES ("Title3", "Body3");
INSERT INTO notes (title, body) VALUES ("Title3", "Body3");
sqlite> SELECT * FROM notes;
SELECT * FROM notes;
1|Title1|Body1
2|Title2|Body2
3|Title3|Body3![]() ![]() |
| ListView and Spinner of planets |
<?xml version="1.0" encoding="utf-8"?>Now let's create a layout file (res/layout/activity_planets.xml) which contains a single ListView:
<resources>
<string-array name="planets_array">
<item>Mercury</item>
<item>Venus</item>
<item>Earth</item>
<item>Mars</item>
<item>Jupiter</item>
<item>Saturn</item>
<item>Uranus</item>
<item>Neptune</item>
</string-array>
</resources>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"And finally our PlanetsActivity.java :
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical" >
<ListView
android:id="@+id/listViewPlanets"
android:layout_width="match_parent"
android:layout_height="wrap_content" >
</ListView>
</LinearLayout>
package com.blogspot.android_by_example;And don't forget to include the activity into your AndroidManifest.xml file.
import android.os.Bundle;
import android.app.Activity;
import android.widget.ArrayAdapter;
import android.widget.ListView;
public class PlanetsActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_planets);
ListView listViewContacts = (ListView) findViewById(R.id.listViewPlanets);
ArrayAdapter<CharSequence> adapter = ArrayAdapter.createFromResource(
this, // context
R.array.planets_array, // source of data
android.R.layout.simple_list_item_1); // layout file to make views
listViewContacts.setAdapter(adapter);
}
}
package com.blogspot.android_by_example;Note that in this example ListView can be substituted by any AdapterView (Spinner, GridView)
import java.util.Arrays;
import android.os.Bundle;
import android.app.Activity;
import android.widget.ArrayAdapter;
import android.widget.ListView;
public class PlanetsActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_planets);
ListView listViewContacts = (ListView) findViewById(R.id.listViewPlanets);
String[] planets = getResources().getStringArray(R.array.planets_array);
ArrayAdapter<String> adapter = new ArrayAdapter<String>(
this, android.R.layout.simple_list_item_1, Arrays.asList(planets));
listViewContacts.setAdapter(adapter);
}
}
This article details accessibility gestures in Jelly Bean and is a follow-up to Jelly Bean Accessibility Explained. It gives a conceptual overview of the 16 possible gestures and describes how they are used. The interaction behavior described here holds for all aspects of the Android user interface, including interactive Web pages within Chrome and the Android Web Browser.
Placing a finger on the screen speaks the item under the finger by first placing Accessibility Focus on that item. Moving the finger triggers touch exploration which moves Accessibility Focus.
To generate any of the Accessibility Gestures discussed below, one moves the finger much faster — how much faster is something we will tune over time, and if needed, make user customizable.
To remember the gestures, think of the four directions, Up, Down, Left and Right. In addition to these four basic navigational gestures, we defined an additional 12 gestures by picking pairwise combinations of these directional flicks, e.g., Left then Down — this gives a total of 16 possible gestures. In what follows, left then down means swipe left, and continue with a down flick. Note that in performing these additional gestures, speed matters the most. As an example, it is not essential that you make a perfect Capital L when performing the Down then Right gesture for instance; speed throughout the gesture, as well as ensuring that the finger moves some distance in each direction is key to avoid these being misinterpreted as basic navigational gestures.
Accessibility Focus is moved using the four basic directional gestures. For now we have aliased Left with Up, and Downwith Right; i.e., both Left and Up move to the previous item, whereas Down and Right move to the next item. Note that this is not the same as moving with a physical D-Pad or keyboard on Android; the Android platform moves System Focus in response to the D-Pad. Thus, moving with a D-Pad or trackball moves you through the various interactive controls on the screen; moving Accessibility Focus via the Accessibility Gestures moves you through everything on the screen.
In addition to the basic navigation describe above, we define the following gestures for common actions:
Gestures Down then Left, Up then Left, Down then Right and Up then Rightare user configurable; their default assignments are shown below.
Gestures for manipulating and working with Accessibility Focus are an evolving part of the Android Accessibility; we will continue to refine these based on user experience. At this point, you are probably saying:
But wait, you said 16 gestures, but only told us the meanings of 12 of them
You are correct — we have left ourselves some gestures to use for future features.
We announced a number of accessibility enhancements in Android Jelly Bean — see our Google IO 2012 announcements and our Android Accessibility talk from I/O 2012. This article gives a user-centric overview of the Jelly Bean interaction model as enabled by touch exploration and navigational gestures. Note that as with every release, Android Accesssibility continues to evolve, and so as before, what we have today is by no means the final word.
First, here's some shared vocabulary to ensure that we're all talking of the same thing when explaining Jelly Bean access:
The combination of random access via touch exploration, backed up by linear navigation starting from the point the user just explored enables users to:
As an example, when using the Google Play Store, I can use muscle memory with touch exploration to find the Search button in the top action bar. Having found an application to install, I can once again use muscle memory to roughly touch in the vicinity of the Install button; If what I touch is not the Install button, I can typically find it with one or two linear navigation steps. Having found the Install button, I can double-tap anywhere on the screen.
The same use case in ICS where we lacked Accessibility Focus and linear navigation would have forced me to use touch exploration exclusively. In instances where muscle memory worked perfectly, this form of interaction was highly effective; but in our experience, it also tended to lead to breakdowns and consequent user frustration in instances where users almost found the control they were looking for but missed by a small amount.
Having introduced accessibility focus and linear navigation in Jelly Bean, we decided to eliminate the ICS requirement that the user tap on or near a control to activate it — we now enable users to activate the item with accessibility focus by tapping anywhere on the screen. To eliminate spurious taps --- especially on tablets, we made this a double-tap rather than a single tap. Note: based on user experience, we may optionally bring back single tap at some point in the future as an end-user customization.
Android Accessibility continues to move forward with Jelly Bean, and will continue to evolve rapidly along with the platform. Please use the Eyes-Free Google Group to provide constructive feedback on what works or doesn't work for you --- what is most effective is to objectively describe a given use case and your particular experience.
We showcased a number of exciting advances in accessibility on Android and Chrome during IO 2012. With these advances, blind and low-vision users can leverage Google applications and services on Android and Chrome to collaborate effectively with their peers and to obtain on-the-go access. Advances include out-of-the-box access on Android (JellyBean), a new set of gestures that enable fluent interaction on touch-screen devices, Braille support on Android, an extension framework for ChromeVox, and a new, high-quality voice for use with Web applications on Chrome.
double-tapping anywhere on the screen activates the item with AccessibilityFocus .
With these enhancements in Android access, blind users can use a combination of touch exploration and navigational gestures to access any part of the Android user interface.
As an example, I typically use the Android Play Store by touching the screen around the area where I expect a specific control; quick flicks of the finger then immediately get me to the item I want. With these touch gestures in place, I now use touch exploration to learn the layout of an application; with applications that I use often, I use a combination of muscle memory and gesture navigation for rapid task completion.
Chrome OS comes with ChromeVox pre-configured — ChromeVox is our Web Accessibility solution for blind users. With the new high-quality voice that is being released on the Chrome Webstore, ChromeVox now provides smooth spoken feedback in Chrome on all desktop environments. Finally, we announced a flexible extension framework that enables Web developers leverage ChromeVox from within and outside of their own Web applications to provide rich, contextual spoken feedback.
To help developers better leverage Web Accessibility, we are releasing a new Accessibility Audit tool that enables Web developers detect and fix commonly occuring accessibility errors. This tool has been integrated into Chrome's Developer Tools and helps Web developers ensure accessibility while working within their normal workflow.
Catch these on Youtube in the next week if you weren't able to attend I/O this week.