SECURITY ISSUE: I don't now how it happens, but readers of this questions come up with idea that solutions to this problem is a security threat. So please keep in mind, all data I am interested in is measuring time of user in/activity. That's all. What user did -- I am NOT interested at all!
What I need is very simple concept, but I cannot find a solution. I would like to run a process (in the background) and have a listener to user interaction.
So, user touches screen --> my method is triggered.
User unlock phone --> my method is triggered.
User types on physical keyboard --> my method is triggered.
So in short my method is NOT triggered when the phone lies still on the table :-) Please note, that the interaction is with entire phone, not with my app, and I am not interested that user typed letter "K", I am not even interested that user typed something, all I care is the user used the phone in some way.
Btw. the state when user is walking listening to music (phone in the pocket) -- it is NOT interaction.
What I am looking for is a trigger -- something like INTERACTION_DETECTED, or (conversely) a callback method which is set like reportInactiveUser(10*1000) and it would be called if user was inactive for 10 seconds.
QUESTION how to detect user interaction?
Purpose: to measure the time of using manually the phone.
(lack of) PROGRESS
I found out that BatteryStatsImpl could hold the data I need. The instance of it is kept by BatteryStatsService, which however does not let any access to it, only IBatteryStats which in turn has only one interesting method -- getStatistics and the output does not include user activity counters (or they are all zeros; I set all permissions on). So, so far -- bad luck.
All calls have to be made by reflection, because those classes are not available anyway ;-).
You want to intercept physical interactions with the phone for that.
For screen touches, this package will come handy. *You can use this to listen for gestures on the screen.
For physical button touches, I suggest you have a look at this.
Related
I want to allow users to lock the device in a sports activities tracking app, to avoid unintentionally leaving the app while exercising.
Therefore I provide a button which locks the input controls of my app and in addition provides the option to lock also the home and overview button, by calling Activity.startLockTask().
I know, that I can call ActivityManager.getLockTaskModeState() later on to find out, whether the user accepted the lock or not.
But what is the best time to do that, or in other words, is there a reliable event that is called, when the popup provided by the system is accepted or rejected by the user?
I checked already that onResume of my activity is not called.
I also found DeviceAdminReceiver.onLockTaskModeEntering/Exiting. But this is meant for administrated devices only and I don't think it can be used without a lot of additional hassle (if possible at all).
I also hoped that the view, which is temporarily hidden by the system popup, gets any of its onWindowFocusChanged, onWindowVisibilityChanges or any other "onWhateverChanged" methods called. But no breakpoint was hit in the methods I tried to overwrite.
I have a rather peculiar case on my hands, and Im surprised that noone seems to have written about it/something similar for Android (or my Google skills suck)
Situation #1:
User can input text into field1 and field2.
User can also re-arrange items in a list (displayed in a RecyclerView)
Whenever the user does any of the edits, the UI is already showing the updated data (e.g. editing field1 will show the text as the user types it, and the list of items will show them in the new order as the user re-arranges them).
Saving the data right away here will trigger the UI to refresh (to display the same thing) and give the user a bad experience (field1 focus will shift to the first letter, and the app might crash if the user quickly re-arranges list items).
So it makes sense to store the edits and execute them at a later point.
Situation #2:
User can tap plus/minus buttons to increase/decrease a value
User can input text into field3.
As in situation #1 above, editing the field will already have the UI in the updated state. But, in this case - tapping the plus/minus button will also update the data, but the UI will not be updated (unless the data is saved, and the query ran again...).
Problem:
If data is saved immediately as the user performs an edit, besides doing a lot of saves, it makes for a bad user experience as the UI will refresh in some cases whereas its already up to date.
If the edits are tucked away and performed at a later point, the UI wont refresh.
Im using MVVM, so all performed actions are sent to the viewmodel and it decides what to do. I find myself looking for a solution that works differently across different screens of the app, but I know that would just be shooting myself in the foot and then jumping off a bridge. Surely, there must be someone out there that has come across this challenge and had some insights around it?
Ideal solution: One solution that just works for all the different screens. Do you have it? Please let me know.
/ Desperate Android Dev
First of all, let me start by stating that I don't think there is a correct answer here, but you should consider what your own app does and then determine what you need to do.
Let me explain. Consider two application, one that saves TODO items and the other is a banking application.
I will now explain what I think could work for your application, since you have not mentioned explicitly any requirements that contradicts that.
In situations like that, I believe being optimistic is a good idea. Assuming that things will not fail, and when they do, try to back out. What does that mean?
That means, for example, in the scenario you mentioned, user enters something in a field. You should let the UI update automatically (Nothing we do here, that's just Android), when that happens you save those changes either locally, or to a server, doesn't matter.
Of course, you can optimize, instead of saving each letter, throttle the input somehow, but you get the idea.
This can either be a succeed or a failure, because we are optimistic, we let the UI update and the user get the feel that our application is lighting fast. You don't need to reload anything, or refresh anything. The UI should match your Model state now already.
What if the things go south, and your HTTP request or DB update fails for some reason, then you need to take action. But try to keep your reaction appropriate.
You can handle that failure in so many ways, again, depending on how critical what you are doing in your app really is.
You can just show a Toast, or even do nothing if the user action was so trivial.
You can show the user something a bit more concrete if the action is of some significance, maybe a Snakbar with retry and explanation of what happened.
You kill your process and finish all activities -kidding don't ever do that- but showing a very intrusive pop-up and possibly reverting the UI value to the correct one, if what the user was doing is quite critical.
Now this approach doesn't just give the feel that the app is really fast, but it also keeps things simple.
Another advise is don't try to solve problems that don't exist yet, that means don't start implementing background services and job queues for some local persistence jobs that never outlive a view, and could never will.
Instead, use measurements, log those errors and failures with some tool, and use those stats to know what needs to be fixed -if any-
Back to our two applications, this approach might be perfect for a TODO app, however this might not be too good for a banking app.
Assume the user transfers money, we say immediately, ALL GOOD MATE! and then the request fails and your user's landlord kicks him out for never paying rent.
So it all comes to how sensitive the operations your're doing.
I am wondering how to handle user input forms in my app. (real budget lite). Right now this is what I am doing, but I am not sure if this is the best practice:
I have two soft buttons on most of my activities that take user input: "save" and "cancel".
"save" captures the user input and then finishes the current activity
"cancel" abandons any user input and finishes the current activity
Hitting the back button on the device does the same thing as "save"
It still bothers me a little that the back button performs the function "save and go back". Users who are new to android phones are probably used to web browsers, where the back button means "forget about this page and go back to the previous page". If you were buying something online and you got to the final "purchase" page, you would not expect the back button to complete the purchase, would you? But it seems like that behavior is the way that the built-in applications work, so I am not inclined to do it differently.
Anyway, I have looked through the official documentation and I cannot find this behavior explicitly spelled out. Can someone point me to the right place, or at least provide some guidance as to best practice?
The choices as I see them are:
Do it the way I am doing it now.
Get rid of the "save" button and count on the users knowing that back equals save.
Get rid of both buttons and provide a cancel feature from the menu key.
The google contacts app provides the buttons "done" and "revert", by the way. I guess "revert" means cancel; is there a difference? Maybe I should have my buttons labeled "done" and "revert" instead of "save" and "cancel"? In gmail, the menu button provides the choices "save draft" and "discard". It seems to me that we would be doing the users a favor if we had some consistency here.
Thanks in advance.
But it seems like that behavior is the way that the built-in applications work, so I am not inclined to do it differently.
The only built-in application that does this, that I can think of, is the contacts app, and I find that UX to be lousy. I was just cursing at it yesterday, as it happens.
Perhaps other built-in apps do it too, but I haven't encountered it yet, at least not that I recall.
Anyway, I have looked through the official documentation and I cannot find this behavior explicitly spelled out.
There are no UX guidelines of this nature in the documentation. Unfortunately.
It seems to me that we would be doing the users a favor if we had some consistency here.
You would get no argument from me.
Personally, I think of the BACK button as behaving as a "cancel", or whatever the negative choice would be. Dialogs typically behave this way on Android, for example.
If you have existing users, and you have established communications with them (newsletter, support Google Group, etc.), I'd poll them and see what they think. In the end, it is what your users want that matters most.
In a pinch, make it configurable. Ideally, for something like this, there is One True Right Answer, and therefore configurability would be pointless. However, if your poll indicates a split vote, and in the absence of Android platform UX guidelines, a setting might be the right solution for you.
UPDATE: I wrote a blog post about this issue, as I think it is reasonably important and worth a bit more prose.
I highly recommend you following the model used by the standard Android and apps, where editing always happens in place. That is, there is no "save" button -- the changes you are making are effectively being saved as they are being done. (The implementation may of course be slightly different, but to the user this should not be visible.) Following that model, your buttons should be something along the lines of "done" and "revert". This helps with the user's mental model of what is going on, that leaving the activity would not be likely to turn into a "revert" operation.
One reason for using this data editing model is that you will run into many fewer bad edge cases. If you try to present a more traditional model where the user explicitly saves, then any path the user may take out of your activity is a potential cause of data loss, which then leads you to want to protect them from that, and thus trying to show dialogs to confirm that they really want to lose their data. This is a losing battle, and you will never be able to catch all of the holes out, and your UX will suffer for it. (Consider for example if they receive an incoming phone call, this is just not the time to put up a dialog to first ask them if they want to save their data, nor would you be able to anyway.)
So start with your basic model being edit in place. This is consistent with the convention the standard platform uses, and this was deliberately chosen in the platform design because overall it results in a much simpler and more consistent and comprehensible UX. Design your UI flow to emphasize this model, by avoiding explicit "save" actions.
For me, I always feel 'unsafe' without a save option. For example, in GTask, when you create a new task, hitting 'back' (hard button) will save the stuff and back to prev screen. There's no soft button BTW. But I always frustrated about this.
For your app, I think you need to consider two things before deciding which way did the back button perform:
How critical is your 'save' operation (like it will place orders!)
Did your user expected to cancel stuff?
Obviously, if the save is long-processed and critical, an explicit control must be taken. (and back would not save); and for the second point, I guess GTask considered jotting notes should be quick and simple, and it should feel like jotting on paper --- it's saved, once you wrote.
Referring to what you said, back in web browser is go back and forget everything. But at the same time, Google (e.g. Google Docs) is also doing auto, background save, that it's not 'forgotten' when you back.
Trying to decide a universal action for when the user presses back makes this question a lot more difficult (if not impossible).
A much simpler approach is thinking about the context, and I see two main situations: the user is interacting with a dialog and the user is interacting with a regular activity.
Interacting with a dialog
If an user presses back in a dialog (for instance date time picker dialog) it's because he doesn't want to see that dialog or change that information.
While in a dialog, the user doesn't expect changes to apply until he says so (by pressing "Ok").
Interacting with an activity
For example, the user is seeing the details of some item that your application provides (contact information). Pressing back after some changes could mean "now take me back to the list of contacts". Anyway, this is not 100% clear. So including options to save and discard changes (call it whatever you like) could be a good option.
My thoughts as an android user
The behavior in a dialog is simple and clear. I think we have no doubts about it.
In activities, I'm used to have the back key to save data and send me to the last activity. Whenever I want to discard my changes, I find myself pressing the menu button and looking for a button to cancel.
If you want to something better, include the default behaviour as a preference and/or display a toast when you cancel or save the information.
Cancel vs revert
In practice, they do the same thing. Cancel should, herr, cancel what you are doing right now (editing something). This should/could take you to what you were doing before (list activity).
Revert will change the state of what you are seeing to the way it was before you started doing changes. This may not take you to the previous activity. It could simply update the UI to the original values.
Experiments with contacts application
Pressing back while editing a contact will save the changes.
Pressing home while editing a contact will discard changes
Is it possible to detect touch events from within another application, specifically swipes? I'd like to be able to detect if the user has swiped left or right (even with 2 fingers - but not required). Perhaps there is a service or broadcast I can listen to.
or failing that, is there some API perhaps that I can poll say 10 times a second to get the touch state and I can compute the rest (why, I remember writing a mouse driver strobing the COM1 port with IN OUTs in 8086 assembler coded in a TSR on a XT...)!
Anyway, any help appreciated. (I think it could be done by hijacking the primary Launcher and having a transparent click-through on-top activity, but that's seriously fraud with danger!)
Is it possible to detect touch events from within another application, specifically swipes?
Fortunately, no.
or failing that, is there some API perhaps that I can poll say 10 times a second to get the touch state and I can compute the rest
Fortunately, no.
I think it could be done by hijacking the primary Launcher and having a transparent click-through on-top activity
Fortunately, no.
You are welcome to write your own home screen application, in which case you can track your own touch events on your own home screen. You are welcome to write an ordinary application and track your own touch events on your own activities.
so i was wondering if its possible to for an application that i would write to be constantly running in the background and alter regular phone operations. For example this could be something like as soon as you receive a text from anyone you forward it automatically to another number. Is something like this at all possible?
Just to be clear I don't want to solve that particular problem through some other means, just want to know if apps can accomplish that.
Also if that is possible is it possible for an app that i write to alter more immediate and instant things, like an incoming call.
thanks all for reading this, and hopefully a helpful response :)
It depends on how far you want to go, but I would expect that what you want to achieve probably isn't possible.
The Android OS does reserve some actions and prevent them from being doing programmatically. For example, you can display the Dialer with a number filled in but the user has to press the call button to make a call. Similarly, you can display the SMS app with a message already written but it is up to the user to send the message.
I don't know for sure, but I assume this is for security. For example, let's imagine you could write an application which could start a call with no user interaction. I would release my Super-Handy-Dialer application which makes quick calls for you making you life easier, but what it also would do is wait until 2am and call my premium rate phone line every night for 3 hours.