Develop Reference

Local datastore write methods do not return (e.g..: pin(), pinAll(), unpin(), unpinAll())

I'm building an android app using the Android Parse SDK, which gets all data from Parse at initialisation and stores it locally. Later, it will only update those entities (ParseObjects) which need so. I'm not getting any return from some Pin() operations, and similarly no callback when I use PinInBackground() and variants. Same happens with Unpin().
My code is something like the following. I have a list of ControlDate, a ParseObject which contains updated_at and updated_locally_at for each Parse data table. I use it to decide if I should query a given table (reducing number of queries). I iterate over this list when I perform a data update, in an IntentService, like this:
protected void onHandleIntent(Intent intent) {
for(ControlDate d : mUpdateQueue) { // mUpdateQueue is the list of ControlDate
if(d.entityNeedsUpdate()) { // returns true if updated_at > updated_locally_at
updateEntity(d);
}
}
private boolean updateEntity(ControlDate d) {
String tableName = d.getTableName();
Date lastLocalUpdate = d.getLastLocalUpdate();
ParseQuery<ParseObject> qParse = ParseQuery.getQuery(tableName);
qParse.whereGreaterThan("updated_at", lastLocalUpdate);
try {
// update the entities
List<ParseObject> entities = qParse.find();
ParseObject.pinAll(entities); // SOMETIMES GETS STUCK (no return)
// update the associated ControlDate
d.setLastLocalUpdate(new Date()); // updated_locally_at = now
d.pin(); // SOMETIMES GETS STUCK (no return)
}
catch(ParseException e) {
// error
}
}
}
Those operations SOMETIMES do not return. I'm trying to find a pattern but still no luck, apparently it started happening when I added pointer arrays to some of the entities. Thus, I think it may be due to the recursive nature of pin(). However it is strange that it sometimes also gets stuck with ParseObjects which do not reference any others - as it is the case with d.pin().
Things I've tried:
changing the for loop to a ListIterator (as I am changing the list of ControlDates, but I don't think this is necessary);
using the threaded variants (eg.: PinInBackground()) - no callback;
pinning each entity individually (in a loop, doing pin()) - a lot slower, still got stuck;
debugging - the thread just blocks here: http://i.imgur.com/oBDjpCw.png?1
I'm going crazy with this, help would be much appreciated!
PS.: I found this https://github.com/BoltsFramework/Bolts-Android/issues/48
Its an open issue on the bolts library, which is used in the Android SDK and may be causing this (maybe?). Anyway I cannot see how I could overcome my problem even though the cause for the pin() not returning could be an "unobserved exception" leading to a deadlock.

Native crash trying to execute SQLite update

I'm trying to increment the value of an integer column in all rows of a SQLite table. Let's say the table name is items and the column name is value. The code looks like this:
SQLiteDatabase db = getDatabase();
db.execSQL("update items set value = (value + 1)");
The code is running in a unit test, and the entire test suite halts completely with the following message:
Test failed to run to completion. Reason: 'Instrumentation run failed
due to 'Native crash''. Check device logcat for details
Here is the entire crash dump from logcat.
I have verified in a SQLite shell that the update statement above does indeed work as written and will increment the value of the column. I've also tried these variations, resulting each time with the same crash:
// variation 1
String sql = "update items set value = ?";
String[] sqlArgs = new String[]{ "(value + 1)" };
db.execSQL(sql, sqlArgs); // crashes
// variation 2
SQLiteStatement statement = db.compileStatement();
statement.execute(); // crashes
// variation 3
// Near as I can tell, below is what execSql does under the hood
SQLiteStatement statement = db.compileStatement();
statement.executeUpdateDelete(); // crashes
Has anyone run into something like this before? How can I execute an update statement like the one above without crashing?
EDIT
This crash appears to happen only within an Android JUnit test. In an actual running application, the execSQL() call with the update statement above executes successfully. I'd still like to know what causes it, but at least production code appears not to be affected by it...

I also faced the same problem with my app.
In my app we have around 30-40 packages and we tested each and every class together.
The test cases are failing in between randomly giving below error:
Test failed to run to completion. Reason: 'Instrumentation run failed due to 'Native crash''. Check device logcat for details
Its a memory Issue while executing the test cases together for all the test classes you create.
So, just override the onTearDown() method in each test class and release the memory by nulling the objects used in that test class.
For Example:
protected void tearDown() throws Exception {
super.tearDown();
mActivity = null;
mInstance = null;
}
where mActivity and mInstance are the Instance variable used by all the test methods.
This overriding tearDown() and relealing object solved my problem.

Android Sqlite SQLiteAbortException does not work

My application uses some complex sql statements so I've gotten in the probably bad habit of using execsql often, even when I could/should probably use something like insert or update for simple things(below).
However, I am wondering why this is not working
String query = "UPDATE OR ABORT " + myTable + " SET " + .... column names and values + WHERE ...
try {
db.execSQL(query);
} catch (SQLiteAbortException e) {
Log.i(TAG, "error in the update");
I've tried this with data that should clearly fail (ie, there is no matching record to update) but I am not hitting the catch. Initially I had used UPDATE OR FAIL and a SQLiteConstraintException but when that was not caught I tried the SQLiteAbortException which specifically states
An exception that indicates that the SQLite program was aborted. This
can happen either through a call to ABORT in a trigger, or as the
result of using the ABORT conflict clause.
What am I missing here?
Update: just adding this for reference on INSERT/UPDATE OR ABORT/FAIL If SQLiteAbortException is not the way, how to catch an update abort/fail?

I just tried to find an explanation for that behavior in the Java source code part of Android API level 19, but the only place where SQLiteAbortException is (re-)thrown is in a static helper class named DatabaseUtils. It gets originally thrown from native code using a method in android_database_SQLiteCommon.cpp. It is thrown when SQLite returned error code 4, which is named SQLITE_ABORT and documented as:
/* Callback routine requested an abort */
I strongly assume a C callback function is meant with that. You can register callbacks with SQLite and they seem to have some level of control. So it appears to me that error code which gets translated into an SQLiteAbortException has little to do with an SQL ABORT clause. in fact, I highly doubt that that exception ever gets thrown, since I don't think that the native part of Android's SQLite database driver hooks callbacks into SQLite that abort requests.
The SQLite documentation of ABORT is also specific which kind of error code to expect:
ABORT
When an applicable constraint violation occurs, the ABORT resolution algorithm aborts
the current SQL statement with an SQLITE_CONSTRAINT error (...snip)
So according to the documentation of SQLite and what the native Android source code actually does, the SQLiteConstraintException is to be expected in that case and apparently Android's documentation of SQLiteAbortException is not entirely correct.

How to handle SQLiteException in Android activity?

I am looking at how to handle exceptions in Android.
In the update() function in the sample code for the Notepad Content Provider, it calls getWriteableDatabase(), which can potentially throw an SQLiteException.
I notice that the NoteEditor Activity saveNote() function has the following code:
// Commit all of our changes to persistent storage. When the update completes
// the content provider will notify the cursor of the change, which will
// cause the UI to be updated.
try {
getContentResolver().update(mUri, values, null, null);
} catch (NullPointerException e) {
Log.e(TAG, e.getMessage());
}
What happens if an SQLiteException occurs?. I want to be able to catch this exception in the Activity and display an appropriate message to the user (via a toast or something similar).
I thought I could do by adding an extra catch for SQLiteException. However, I read the following info in the Google docs:
"Remember that the Android system must be able to communicate the Exception across process boundaries. Android can do this for the following exceptions that may be useful in >handling query errors:
IllegalArgumentException (You may choose to throw this if your provider receives an >invalid content URI)
NullPointerException"
So I am now confused - can I catch the SQLiteException or not?

Whenever possible, you should catch the Exception in the class or component in which the Exception occurred. Use some sort of broadcast mechanism or return value semantics to report errors across processes.
It's admittedly a tricky situation. Some people say that if an SQLite (or other Exception) occurs in a ContentProvider, the provider should propagate the exception upwards instead of returning null in the Cursor. However, this generally won't work across processes! On the other hand, returning null doesn't give you a lot of information.
A limited set of Exceptions do traverse process boundaries, but SQLiteException isn't among them - still they might be useful/appropriate.

Android Throw Exception

In my application, I use SQLiteOpenHelper class and it has insertOrThrow method. I want to learn that will this method close my connection before throw an exception? And it is written on definition of method that "the row ID of the newly inserted row, or -1 if an error occurred "
When throw an exception how it has a return value? Something is wrong. Explanation or throw ?
This is how I use InsertOrThrow.
I want to know when I declare throws Exception to my method, is it necessary to use try-catch (If I don't have any special thing to do in catch like my exp.)?
public long insert(ContentValues cv) throws Exception {
try
{
long rowId = getWritableDatabase().insertOrThrow(_tableName, null, cv);
return rowId;
}
catch (Exception ex) {
throw ex;
}
finally{
Close();
}
}

It depends; if this.Close() can throw an exception, then it still needs to be declared as being thrown, or caught. Often times this is wrapped up in a small utility method.
It's not mandatory to use a catch, you can simply try/finally.
Regarding return values: methods that exit due to an exception don't have a return value.
Exceptions should encapsulate enough information to either:
allow the caller to do something useful with the exception, e.g., retry the operation, or
assist the developer in understanding the problem and lead him/her to a resolution.
I'd encourage you to follow standard Java naming conventions to avoid confusing readers of your code: non-final variables should begin with a lower-case letter. Method names should also begin with lower-case letters.
Also, you do not need to preface methods (or variables) with this when there is no need to disambiguate the property you're accessing.

When throw an exception how it has a return value? Something is wrong.
Yes, you're right. The documentation seems wrong.
insertOrThrow doesn't return -1 , instead, it will throw SQLException if the query failed. There's a another method called insert which would return -1 if the query failed, and newly created rowID if success.