search

KomodoOpenLab / InputAccessLib

InputAccessLib is a library that enhances the compatibility of Android applications with a variety of alternative input devices such as external keyboards, adapted switches, hands-free kits and remote controls.
10 stars 16 forks source link

Implement internal detection of onPause/onResume events #8

Closed ijdoc closed 12 years ago

ijdoc commented 12 years ago

Can you think of a way to detect the onPause and onResume events internally given that you already have an instance of the Activity? It would be great if devs don't also have to understand/worry about making sure the intents get sent to the Tecla IME, besides, this represents extra work they may not be willing to do.

Maybe we can subscribe to window manager intents or notifications that we can then process to find out the state of the particular activity. The solution is already very elegant when only requesting devs to add an import statement and return our modified method for creating the menu object (only 2 lines!), so I am trying to keep it that way.

If all else fails, consider implementing a background service that makes this possible.

rishabhjain08 commented 12 years ago

I am still searching for ways to detect the onPause and onResume events internally but I wanted to highlight that implementing a background service wont be a nice idea because then the third party applications will have to add that service to their AndroidManifest.xml manually. I think current implementation is better than that. On Wed, Jun 6, 2012 at 1:50 AM, Jorge Silva < reply@reply.github.com

wrote:

Can you think of a way to detect the onPause and onResume events internally given that you already have an instance of the Activity? It would be great if devs don't also have to understand/worry about making sure the intents get sent to the Tecla IME, besides, this represents extra work they may not be willing to do.

Maybe we can subscribe to window manager intents or notifications that we can then process to find out the state of the particular activity. The solution is already very elegant when only requesting devs to add an import statement and return our modified method for creating the menu object (only 2 lines!), so I am trying to keep it that way.

If all else fails, consider implementing a background service that makes this possible.

Reply to this email directly or view it on GitHub: https://github.com/idrc/InputAccessLib/issues/8

ijdoc commented 12 years ago

ok, that makes sense. Hopefully there is a way to receive some kind of intent from the Window Manager (or similar component) directly into the library so it can be parsed and we can act accordingly.

rishabhjain08 commented 12 years ago

Added a listener for window related events and was able to reduce the number of required function calls to be made by devs to just one other than instantiating an object of InputAccess,