Status notification should occur after OmniHandler execution

[GoogleCodeExporter]

When OmniDroid catches an event that matches an OmniHandler and that
OmniHandler's actions are performed a status notification should show up on
the status bar.

Original issue reported on code.google.com by case.and...@gmail.com on 5 Jun 2009 at 9:47

[GoogleCodeExporter]

This should be part of a "Debug" mode option that users can enable/disable on 
the
"Settings" page.  Instead of a "notification" we may prefer a "toast" when this 
debug
option is enabled.

Original comment by case.and...@gmail.com on 1 Jun 2010 at 8:12

[GoogleCodeExporter]

so now there is "toast" in GMailService and SMSService. So should we change it 
all to notifications? or just add toast? when smsservice is triggered it shows 
some message(something like "smsservice started"), but the final message 
whether message was sent or not could be notification.

Original comment by sv767%ny...@gtempaccount.com on 1 Jul 2010 at 5:58

[GoogleCodeExporter]

Original comment by sv767%ny...@gtempaccount.com on 1 Jul 2010 at 5:58

• Changed state: Started

[GoogleCodeExporter]

Sorry, I didn't really think this through completely when I posted it.

I think by default a toast should occur for each rule that is applied.  Then if 
an action deems it appropriate to send it's own toast such as "SMS Sent 
Successfully" that fall on the Action object to perform that.  This issue is 
about implementing the former.

In addition I think it would be of benefit if we could have a "Send 
Notification on Rule" option in the Settings activity that instead of using a 
Toast it sends a Notification about that Rule being applied.

I think rules should default to Toasts to avoid unwanted notification clutter, 
but users should be able to toggle it in the event that they want to easily see 
that rules are being applied without having to sift through the logs or 
actively monitoring their screen.

Thoughts?

Original comment by case.and...@gmail.com on 1 Jul 2010 at 2:11

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 1 Jul 2010 at 2:15

[GoogleCodeExporter]

yeah we could have notification on/off in context menu(along with delete, 
delete all, enable/disable all, edit) in saved rules activity. but still think 
it should be enabled by default. you don't want users not being aware of that 
their phone is on silent and blaming omnidroid for missed calls. or we could 
have dialog box after you save a rule.

Original comment by sv767%ny...@gtempaccount.com on 1 Jul 2010 at 3:11

[GoogleCodeExporter]

Defaulting to on for notifications is fine with me as long as we have a way to 
turn it off.

Just to clarify, the options that apply to all rules (enable all, disable all, 
delete all, toggle notify on/off) should be on the options menu, while the item 
specific options (delete, edit, view, etc.) should be on context menus.

Original comment by case.and...@gmail.com on 2 Jul 2010 at 3:31

[GoogleCodeExporter]

I don't like idea of having both. 

Original comment by salomeju...@gmail.com on 2 Jul 2010 at 5:40

[GoogleCodeExporter]

You don't like having both an OptionsMenu and a ContextMenu or a both 
Notifications and Toasts?

Original comment by case.and...@gmail.com on 2 Jul 2010 at 10:03

[GoogleCodeExporter]

the menus. but this should be discussed somewhere else, we should open new 
issue about improving saved rules activity.

Original comment by sv767%ny...@gtempaccount.com on 2 Jul 2010 at 10:29

[GoogleCodeExporter]

Agreed.  For reference, Issue111 and Issue66 are about Saved Rules Activity UI 
changes.

Original comment by case.and...@gmail.com on 6 Jul 2010 at 1:21

[GoogleCodeExporter]

http://codereview.appspot.com/1726050/show

Original comment by sv767%ny...@gtempaccount.com on 9 Jul 2010 at 7:03

[GoogleCodeExporter]

committed r807

Original comment by sv767%ny...@gtempaccount.com on 13 Jul 2010 at 5:00

• Changed state: Fixed

[GoogleCodeExporter]

I just realized that this change looks like it only affects OmniActionServices. 
 I would think that the original desire would have been to have this applied 
during HandlerService processing or ActionExecutor instead of in the specific 
Action code.  That would allow these notification on all actions as opposed to 
limited to implementation by OmniActionServices.

Original comment by case.and...@gmail.com on 20 Jul 2010 at 1:33

• Changed state: New

[GoogleCodeExporter]

why only OmniActionServices?
but you're right, I will consider moving that code to ResultProcessor after i'm 
done with it, and also using UtilUI showNotification, but right now we couldn't 
have it in ActionExecuter because notification message depends on whether 
actions was successfully executed or not.

Original comment by sv767%ny...@gtempaccount.com on 20 Jul 2010 at 2:00

[GoogleCodeExporter]

Oh I see yes you're right it is included in the other actions as well.  I was 
just looking at that specific case.  But yeah, it should be moved into a more 
general location so 3rd party actions will be affected as well.  The 
ResultProcessor... that's part Issue92 that you're working on?  That seems like 
the perfect place for it.  Looking forward to it!  I'll re-mark this as Started 
and add blocked on 92.  Thanks!

Original comment by case.and...@gmail.com on 20 Jul 2010 at 2:12

• Changed state: Started

[GoogleCodeExporter]

I'm thinking notifications about failure shouldn't be sent until action is 
removed from failedactions table. otherwise we would get several notifications 
for one action. 

thoughts?

Original comment by sv767%ny...@gtempaccount.com on 28 Jul 2010 at 11:35

[GoogleCodeExporter]

I agree

Original comment by case.and...@gmail.com on 28 Jul 2010 at 11:45

[GoogleCodeExporter]

r839

Original comment by sv767%ny...@gtempaccount.com on 30 Jul 2010 at 4:09

• Changed state: Fixed