draw() affecting onBackPressed()

[ghost]

Processing version 2.1
Android minSDK 8

Overridden onBackPressed() button gets consistently called if there is no draw() method, however, the application always exits (without onBackPressed ever being called, most of the times).

[joshgiesbrecht]

I just tried a very minimal example with onBackPressed() implemented, once with a draw() method included and once without a draw() method. The app calls onBackPressed() in both cases and doesn't exit the application.

(Your description was sort of contradicting itself, but I assume that was the problem?)

Code I used:

void setup() {
}

void draw() {
}

void onBackPressed() {
  // don't quit!
  print("back pressed!");
}

and then I commented out draw():

void setup() {
}

//void draw() {
//}

void onBackPressed() {
  // don't quit!
  print("back pressed!");
}

Neither of these examples should let the app exit by pressing the back button. If they do, please let us know what Android version you're running, and if it's a device with a hardware back button (vs one of those virtual buttons that newer Android moves around on the screen).

[Calsign]

I have tested both sketches above with Processing 2.1.2 on a Samsung Galaxy S4 running Android 4.4.2 (the S4 has a hardware back button) and with the standard Processing emulator (Android 2.3.3 with a simulated hardware back button). Both devices had the same behavior.

Without draw(): onBackPressed() is called and the sketch doesn't exit (this is normal).
With draw(): onBackPressed() is not called and the sketch exits (this is incorrect).

It appears that the presence of the draw() function completely breaks the onBackPressed() functionality for my device / emulator, but it behaves as expected without draw().

[nuss]

I can confirm the behaviour as described by Calsign. Any chance this bug will get fixed in a not too far future?

[joshgiesbrecht]

Yeah I will look into this soon-ish.

[nuss]

I've received an update on this thread via email which doesn't appear here on this page:

Ok, I can confirm this bug in the released download of Android Mode. But if I grab the newest github master and run the release build and use that, the bug is gone.

Is the Android Mode download up to date? If so, I'm not sure what to look for next here.

I've just checked if my Android-mode is up to date. I.e. I removed and reinstalled it again via "Add Mode..." in the modes-dropdown. Processing itself is version 2.2.1 (Linux). I'm not sure how I would build Android-Mode from source (i.e. clone the repo from github and build manually).

[joshgiesbrecht]

Hi, yeah I posted that yesterday and then deleted it because I was having some issues with my build environment and I wasn't 100% confident of my results. (It's been a while since I've built Android Mode from source and I've had to deal with crusty old Java apps requiring old versions of the JRE in the meantime.)

I'm not really recommending building from source as a solution, I'm just trying to sort out what's causing the problem. Currently running into something else breaking the build but I'll roll that change back and see if I can get this tested properly. (Later, when I have time, hopefully today, maybe.)

[joshgiesbrecht]

Ok, cleaned up and confirmed everything on my end. There's a fix for this bug already submitted, it's just waiting to be included in the next release.

[nuss]

Great news! Thanks a lot for your efforts.