Sometimes alert keeps sending despite ribbon color

[jmatsushita]

and it's also not showing the "Stop Alarm" button.

[jmatsushita]

Hi @niccs Testing with some phones it seems clear that there are several instances of various activities that are running which is I think a problem that you've already mentioned before. In addition to solving the problem, could we also look at being "defensive" with the coding of the Ribbon and the Home screen when the alarm is sending? By that I mean, can we test if there are any ongoing processes that might be currently sending?

[niccs]

Hi @jmatsushita ,

A possible quick solution is -- In mobile device-- go to settings--> developer options--> Dont keep activities --> this should be turned off

If this option is turned on, everytime we open a screen or we press back, a new screen is stacked over the previous one, and so several of various activities can cause possible issues,and so the option should be turned off.

To ideally solve this problem, is like re-designing and implementing the app completely new, as the communication is the base of the design. I dont see this to feasible at this point. However, I will look into the coding of ribbon and the defensive style, as you suggested.

If I can get the steps to re-produce the issue, will be lot easier to look into. So the devices where you were facing the issue, please let me know the steps o re-produce it.

[jmatsushita]

Hi @niccs,

Thanks for the workaround, but that's not really viable for users.

Let's think about the redesign later indeed.

For now can you indeed think about ways we can identify that multiple instances of the alert service are running and ensure that the ribbon color is checking if several Alert services are running (and displays red if any service is sending), end that the Stop Alarm button stops all Alert services running.

With regards to phones, this happened on pretty old phones which were really slow. I think that what might happen is that the app takes time to change between screens and that it registers button presses several times, which spawns several activities. It might be then that when users go to the calculator, they're seeing a duplicate activity that is looking at the wrong context where the service isn't running.

Maybe a way to address this is to prevent double clicking buttons with this click time approach:
http://stackoverflow.com/a/16514644

Also could we mark some of our activities as single instance or single task as suggested here?
http://stackoverflow.com/a/4001465

Please also propose any other solutions you might have in mind!

Jun

[jmatsushita]

Some more thinking after looking at http://developer.android.com/guide/components/tasks-and-back-stack.html

I wonder if we could print the content backstack and the background tasks in the debug log to help understand what's going on?

Do you think that our views get into different tasks? In which case I guess that singleTask should work? But I don't know what the usability implications are given that the doc states:

singleTask and singleInstance — are not appropriate for most applications, since they result in an interaction model that is likely to be unfamiliar to users and is very different from most other applications.

Otherwise this recommendation about preventing the Main activity to be launched several times might be worth implementing as a defensive measure. Could it be applied to the Wizard activity and Main activity to make sure they are the only instances running?

This is related to #138

1. Turn on the developers option " don't keep activities" and PB application does not behaves appropriately.
2. From every fragment , during transition to another screen,every time a new Activity is instance is loaded, using startActivity(), which can stack of the activities and may give reliability issues.

And also related to #73.

[niccs]

Hi @jmatsushita ,

1. In PB app, the trigger service is started only once(as soon as the setup is finished). so multiple instances of it getting created is completely ruled out.

2)Now the other case is of stacking of activities.

There are two independent flows:--
a)Setup through wizard activity and
b)triggering of alert from MainActivity

Now for case a)-- stacking of activities is no way interfering in alarm process, as once the setup is completed and after the last "Finish" screen, the hardware trigger service is started and post that , the complete activity stack is destroyed. So we can rule out the case a.

Case b)

Ideal work flow:--
As per the expected and ideal flow, once the alarm is triggered, a flag is maintained properly across the application context(in shared preferences), which is independent of activity stack.
And for starting and stopping the alert, this flag is used.So even there are multiple activities stacking, we always have a single application context throughout the app flow.

So if the "Stop Alert" button is visible and pressed, the alert should be stopped, as this is independent of activity screen or activity stacking.

And while starting the main activity, it checks the same flag, if this is turned on--"stop alert" button is displayed.

Possible issues:-
1)The other case is, alert is triggered from power button and "stop alert" button is not visible.So user is not able to stop it.( need to replicate this).

Right now, I am trying to identify more cases.

So from alpha users, I need the actual steps of the use-cases, where we are facing issues, then only I can think of possible causes from the existing design point of view.

Also from developer options- we need to switch off the "do not keep activities" flag. This is not a work around. By default, this flag comes off with a device. This is for developers to turn On and test the app in all possible cases(which seems is not done in PB app development)

[jmatsushita]

Could it be a result of the update process as described in the link above?
On 10 Feb 2016 06:28, "Neetika M" notifications@github.com wrote:

Hi @jmatsushita https://github.com/jmatsushita ,

1. In PB app, the trigger service is started only once(as soon as the
   setup is finished). so multiple instances of it getting created is
   completely ruled out.

2)Now the other case is of stacking of activities.

There are two independent flows:--
a)Setup through wizard activity and
b)triggering of alert from MainActivity

Now for case a)-- stacking of activities is no way interfering in alarm
process, as once the setup is completed and after the last "Finish" screen,
the hardware trigger service is started and post that , the complete
activity stack is destroyed. So we can rule out the case a.

Case b)

Ideal work flow:--
As per the expected and ideal flow, once the alarm is triggered, a flag is
maintained properly across the application context(in shared preferences),
which is independent of activity stack.
And for starting and stopping the alert, this flag is used.So even there
are multiple activities stacking, we always have a single application
context throughout the app flow.

So if the "Stop Alert" button is visible and pressed, the alert should be
stopped, as this is independent of activity screen or activity stacking.

And while starting the main activity, it checks the same flag, if this is
turned on--"stop alert" button is displayed.

Possible issues:-
1)The other case is, alert is triggered from power button and "stop alert"
button is not visible.So user is not able to stop it.( need to replicate
this).

Right now, I am trying to identify more cases.

So from alpha users, I need the actual steps of the use-cases, where we
are facing issues, then only I can think of possible causes from the
existing design point of view.

Also from developer options- we need to switch off the "do not keep
activities" flag. This is not a work around. By default, this flag comes
off with a device. This is for developers to turn On and test the app in
all possible cases(which seems is not done in PB app development)

—
Reply to this email directly or view it on GitHub
#196 (comment)
.

[niccs]

@jmatsushita ,
No in our case, the launch activity is always HomeActivity and there is no view of it.
The problem for us comes after LoginActivity.
Also, in case there is a crash due to activity stack, and changed activity context, we will get exception via crashlytics.

1. So i need exact steps, where we face the probable reliability issues, to think and proceed further.
2. devices, and the android versions running on it and the status of "do not launch activities flag" on those devices.
3. Other use cases, which you think, can cause trigger issues.