draw() affecting onBackPressed() #59

Activity

1. joshgiesbrecht commented on Mar 29, 2014

   

   joshgiesbrecht

   on Mar 29, 2014

   Contributor

   More actions

   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).
2. Calsign commented on Apr 17, 2014

   

   Calsign

   on Apr 17, 2014

   More actions

   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().
3. nuss commented on May 1, 2014

   

   nuss

   on May 1, 2014

   More actions

   I can confirm the behaviour as described by Calsign. Any chance this bug will get fixed in a not too far future?
4. joshgiesbrecht commented on May 1, 2014

   

   joshgiesbrecht

   on May 1, 2014

   Contributor

   More actions

   Yeah I will look into this soon-ish.
5. nuss commented on May 29, 2014

   

   nuss

   on May 29, 2014

   More actions

   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).
6. joshgiesbrecht commented on May 29, 2014

   

   joshgiesbrecht

   on May 29, 2014

   Contributor

   More actions

   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.)
7. joshgiesbrecht commented on Jun 25, 2014

   

   joshgiesbrecht

   on Jun 25, 2014

   Contributor

   More actions

   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.
8. nuss commented on Jun 26, 2014

   

   nuss

   on Jun 26, 2014

   More actions

   Great news! Thanks a lot for your efforts.