can't see minutes after phone call
poundifdef opened this issue · comments
Whenever a call ends, com/drfloob/VirginMobileMinutesChecker/call_trigger/MinutesService.java always shows a message saying that it could not log on to retrieve my minutes. This should be fixed or removed alltogether. It could be unreliable to fetch minutes immediately after a phone call.
I have this problem as well. It shows minutes at the beginning of the call correctly, but displays this problem at the end.
Glad you've taken an interest in this; I'm looking forward to seeing what you come up with!
Hah :) While I know Java, I know absolutely zero about Android dev (although I would be quite interested to find out), so I think my current pull request would just end up being the toast being commented out. Won't need to test it then :)
I think I'll leave this one to the professionals!
I think that's basically what the fix will be, at least for now. If you decide you have some time and want to create an enhancement as a "Hello Android World" project (making a widget is next in the hopper), feel free to push some code. All the best!
I'm having the same issue on the intercept. Even when I switch the two new options off, the app runs every time a call is made or received. If I don't close the app with a task manager it eventually slows the phone to a crawl. Is there any way to roll back the update?
Thought about this a bit more: is it possible that the query for the minutes is going out too quickly, so Android hasn't context-changed from voice to data? We know CDMA can't do both at the same time. What if you sleep the scraper for a couple of seconds after the call ends?
Is there anywhere I can download a version 1.2 or 1.1 apk of this app? I had to uninstall this version as it keeps locking up my phone.
@poundifdef: on my phone (Optimus V), it only asks for credentials if I haven't input them once (or if I've manually logged out). Once I've typed my info in once, it updates entirely in the background every time I end a phone call. I've never had it do otherwise, but maybe my phone is different. OTOH, if you oppose it checking your minutes when calls end, you'll just have to figure out when a better time to scrape is. Periodic may work, but you risk getting stale info the next time you receive a call, and hence making a poor decision about whether or not you have the minutes to take it.
@lewisham: that particular message displays (or is only supposed to display) if your login credentials are not stored on the phone (i.e. if you haven't logged in). If the web request fails entirely, the service just crashes (which it can do without harming the integrity of the cache/app in general). Changing the periodicity shouldn't affect that, per se.
@nobodyspecial: if you have the sdk, I believe the first version on poundifdef's github account is the pre-modified version. You can build it using ant or eclipse pretty easily. Otherwise, if you turn the service off, it is supposed to run and immediately quit, since I know of no other way to provisionally enable/disable broadcast receivers. It hasn't been a problem at all on my phone (again Optimus V) for the past week of usage. Do you have a log of the errors, by any chance?
I just noticed that end-call scraping was removed in your code as of commit 115ffb1 .
I don't think it's very clear from the prompts issued by the app, so FYI: if you don't login before your next call, the minutes displayed on an incoming call will probably be stale (i.e. you've actually used more of your minutes than it says you have). I'd personally rather it prompt me to login right then than make me find the app and do it manually (which I probably wont) ... my phone bill is not to be trifled with! Until that's sorted out, my fork has the scrape-on-end-call included. However, that's the only difference right now, so it should have all the other problems discussed in here, too.
@drfloob: I have merged all of your changes back in to the code and I also uploaded the widget, which needs some work. When I have both boxes checked (toast on incoming+outgoing calls), when I hang up, the screen-scrape fails and I get the "Cannot connect to server" toast or no toast at all, even if I am signed in. Do you not also get these quirks?
In fact, if I am logged in, I still get the post-call "Cannot load minutes" wherein it brings me to the ViewMinutes screen (because it intends to ask me to log in) and then successfully fetches the data!
tl;dr: no, I don't have those quirks. Can I see your log of the errors?
My phone is running my fork of the code, master branch HEAD. The diff between your current HEAD and mine looks primarily like the widget code and some print statements, which shouldn't affect the behavior we're talking about.
I tested a bunch of combinations of getting and making calls, answering and not answering them, logging in and out, putting my phone in "CDMA-only" radio band mode (1x vs 3g), and finally recompiling and installing the app with a fake URL (that wont resolve) to see what happens. (my tests were not exhaustive, but I tested a bunch).
The error toast I get with the fake URL is
Could not retrieve your usage information. Make sure you have a connection and that your username and password are correct.
I got no other errors during my tests. I can't find any string in the codebase that looks like "Cannot connect to server", so I'm not sure what that could be. There's a handful of error strings in the codebase ... knowing exactly which happened when will help a lot.
Can you plug your phone in to your computer and run logcat to see the errors it's throwing? Or install alogcat on your phone, if wiring in is not possible? That'd shed a lot of much-needed light on the situation. I'm stumped.
Also note: when logged in, getting no toast after ending a call is the expected behavior. It silently scrapes and caches when it works (though debug-compiled versions print some info to the device log on success).
Hi - sorry about that, I definitely should have been more specific. The error toast is exactly what you posted, "Could not retrieve your usage information..." I've been looking at DDMS logs and wasn't aware of logcat. I'll run that now and see if anything turns up, or provide more info about my setup to reproduce the error. (Thank you, incidentally, for not abandoning this! There is something amiss, since I get emails and Market comments about this. More to come.)
Okay, I posted a chunk of logcat's output here: 99488cc . Take a look at line 39. This might be what @lewisham was talking about - trying to access the network too soon after a call. Investigating.
Edit: added entire log file. More stack tracey goodness, since the part I posted had nothing to do with drfloob's service. doh. doh. doh. personal info. doing surgery on the repo.
Cool. We can also track the reason the user has been logged out. If it is due to inadequate connectivity, then we won't bring the user to the password screen. Otherwise it means they have a bad password and can bring them to that screen.
Awesome. You got this bug fix under control, then?
Yep, I'll give it a whirl. If I mess it up... well, y'all will be the first to know!