Prompt at the end of a trip to report incidents #229
Comments
|
Step 1:
Tests:
|
|
Without force killing android, notifications are generated correctly. Checking logs on android. |
|
Logs are at: Yeah, the trip end was detected. Receiver received it - invoked service. Clearly no local notification was received. Need to add more logging to see exactly what happened. Will the more sophisticated bridge launch the webview? Need to experiment with it... |
|
Even on iOS, noticed big differences with control phone. Noticed that there were big gaps in collection. This is consistent with crashes and then restarting tracking again through significant location changes. Let's see if there are any crashes reported on the phone.
|
|
Yup! Crash roughly 30 mins.
|
|
Exception: |
|
Failure is here: |
|
Able to get there with the debugger. Let's see what's going on now. Didn't crash when connected to the debugger. |
|
Ah, this time, for the |
|
Yup! data = crashed! Solution is to not listen to the |
|
Added additional logging in the cordova broadcaster code. Installed version with additional logging. I force killed the app to avoid having it in the background. Next call to the TripDiaryStateMachine is at 7:32. Maybe that was when I turned Launched again |
|
First instances of LocationChangeIntentService are at: before the geofence exit (at 9:56). Unsure they got started, but it looks like they ran for a while and then we detected that the trip stopped. What about the trip to school? |
|
here are the additional logs from the broadcaster. Note that they only start after |
|
Added additional logging in the cordova broadcaster code. Installed version with additional logging I force killed the app to avoid having it in the background. Next call to the TripDiaryStateMachine is at 7:32. Maybe that was when I turned Launched again The only time the new logging was triggered was at around 7:30 |
|
Let's confirm that data collection settings are all set correctly. Looking at the diary from yesterday, after turning duty cycling on, the data was pushed and processed correctly. I now see 5 trips yesterday, including one from 10:44 -> 10:52 and one from 12:29 -> 12:41. Let me see what the logs show about data collection at that time. |
|
The first LocationChangeIntentService in the logs was at 19:27. Let me export the emission logs instead... |
|
Walking around makes it so that we can't really set breakpoints, etc. In the meanwhile, I wrote a separate test case in a separate, temporary project. I can confirm that running the test causes this breakpoint in |
|
We don't know whether the local broadcast manager will be invoked when the app is killed, so let's also add a callback in the broadcast manager, which we know will work. Works.
|
|
Now, I kill the app and re-run the test. Logs are here. It is pretty clear that Working caseHere's a working case from the previous successful run at 11:25 Not working caseHere's the not working case from the last run. Note no calls from the plugin. |
|
Experimenting with making the plugin a full broadcast receiver to see if that will help. with I suspect this will not work, because the receiver will be killed, but let's see :) |
|
Ok, so that worked without killing. I changed the plugin to use the non-local receiver, and then I changed the TripDiaryStateMachine receiver to stop broadcasting to local broadcast receiver and we still got a notification. |
|
As expected in https://github.com/e-mission/e-mission-phone/issues/191#issuecomment-265260569, Successful runKilled, last instance of CDVBroadcasterNot relaunched |
|
I then tried to add an entry for this in the
the plugin currently uses an anonymized inner class. last check to see whether a non-anonymized inner class will work. |
public, non-anonymized inner class compiles. |
but doesn't run. It fails with exception In spite of adding a noarg constructor I think that the problem is that as an inner class, it needs to be instantiated using an instance of the outer class instead of being instantiated directly. |
|
Yup. from the android source code at https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/ActivityThread.java, we see that the class needs to be instantiated using |
|
Hm, but calling new on an inner class seems to work just fine. |
|
This is a known issue apparently, with instantiating inner classes from the |
|
The workaround is to use a static class. I can confirm that using a static class works. But then we can't access any of the cordova stuff inside the inner class because it is not static in the outer. |
|
I think we need to have the following structure:
Question: Second question:
Let's start with this and add more as needed :) |
|
One interesting thing to note is that on android, the mapping from the local notification to the javascript callback happens as follows:
When I see what happened to the Can we do something similar to call javascript from the background in android, and make it easier to compose plugins? Need to investigate further. |
|
Also, swiping away the notification without clicking on anything leads to a "cancel" event. I have added a callback for it as well (#a858446ed8eabadc2e69a424bcb85a3bbccbcb4f) |
|
Usercache changes to support local storage: |
Now that we are passing in the correct notification with a real category and actions, we no longer need to forcibly set them. https://github.com/e-mission/e-mission-phone/issues/191#issuecomment-265659578
|
Some more testing indicates that there are subtle changes between iOS 9 and iOS 10. iOS 9.2: iOS 10.1:
I wonder if this is because of this change: |
Yes. Fixed with an easier commit Manually ported the fix as |
|
There also appear to be minor differences between iPhone 7 and iPhone 6 for the same OS version (10.1). This is really bizarre. Does the OS really check which hardware it is running on for something as simple as showing notifications? Here are screenshots from various emulators, run without changing the code in any way. It looks like on iPhone 7, actions are not displayed correctly ( at least according to the emulator).
|
|
This appears to be a regression in Have filed a customer support issue with Apple.
|
|
Changes to help debug this issue |
|
Broken on iPhone 6s as well. Basically all the phones that only run iOS 10. |
|
Quickly checking how this https://github.com/e-mission/e-mission-phone/issues/191#issuecomment-266335713 works to see if we can try to do sth crossplatform anyway. Start with a killed app Check 1:
Check 2:
It looks like basically there is a difference between activities and processes. |
|
Note that when we cancel, we use the
Start:
Broadcast event
Click on event
Let's try again without using the debugger |
|
At any rate, it seems possible to launch an activity directly into the background, the way the Should not be too hard to get it to work for now using native code. |
|
Let us first understand this better and then do it in native code for now. |
|
Note that when we cancel, we use the
Start:
Broadcast event
Click on event
Let's try again without using the debugger |
This is just because I hadn't updated the app. After re-installing, we were That makes it trickier to use it to run javascript in a crossplatform way. In |
|
Let's see how long it sticks around if it doesn't launch another app. Answer is: a little longer (~ 1 minute) |
|
Only two launches detected. Dunno which two. Nothing running. Click yes. Then launch gmail. Gmail running. Click yes. Gmail running. Click yes. Click home button. |
|
Now, launching the |
|
Launching the |
|
If we want to test this again, we need to change both instances of |
|
So I made changes directly to the native code to fill in On android, the data is returned as JSON to javascript. Note how the data is a JSON object when the notification is posted but is a string on return. It should be possible to reconstruct a JSON object from the string before
|
|
This should never happen in the real world, but it sometimes happens in testing |
|
Some other notification stuff from stackOverflow that might be useful to explore later. http://stackoverflow.com/questions/32338514/ionic-background-to-foreground-using-local-notification |
|
version 1.7.0 added this functionality and version 1.8.0 fixed some minor issues with it on iOS, notably prompting while in the foreground on android. concretely, native code plugin is at: javascript changes are from |
|
closing the issue! |
While its great to have the ability to report incidents, that's already in see-click-fix and other such platforms. What happens is that the incident happens, and then you get back and you forget to record it. We want to start prompting people to record incidents at the end of a trip.
The text was updated successfully, but these errors were encountered: