Frameworks: Heads up meets SlimKat....SlimKat meets Google IO meets Validus [1/4]

First introduced from apple, showed as android version on PA as hover
and now found
in android code as native implementation we want to do our
interpretation of this feature.
Especially thanks PA and CM for some of the UX ideas.

We have basically split this feature in two parts.

1. Googles native integration. We keep it as is and use the native flags
for it. Apps
(in our case Dialer, Mms, Email per account) can force show a heads up
notification
if the notification is important. So basically same what was shown on
Google IO the first
time to the public. Eg the dialer on SlimKat is doing exactly the same
now like google want it.
Due that we use same flags like google every future app with heads up
support will automatically
show as heads up.

2. Give the user an ability to enable heads up mode for third party apps
which do not have a native
integration. Well first thought was on which apps a user would usally
use it (keeping in minde the idea from google....heads up
is for important notifications and for nothing more)? Right on chat,
email
or social apps. On all other apps it simply does not make sense at all.
Which leads into the question why the
current integrations are handling blacklists or whitelists and enable it
per default for all apps. This
is from UX point of view an absolutely no go (just imagine the user
blacklists half of the 200 apps installed lol).
Aside that parsing long lists is a peformance problem.

So our attempt goes into another direction. Headsup for (native
integration is another story) apps is disabled
by default. We bind the information directly to the application package.
So each app carries the information itself.
The user can either enable it with a longlick in the notification drawer
on the notification or in Settings->app->App info
as well via a check box. As soon it is enabled for this app every
notification from this app will show as heads up as long
it is not an ongoing notification.

In general on system signed apps the user is not allowed to change the
heads up state. Thats nothing the user should
decide....the system should do. Aside that it prevends user to enable
heads up for eg IME selector etc etc.

Thats the basic concept behind. In addition to this concept following
things were done.

- Introduce a new expanded notification flag. Apps can send it via extra
metadata to force
a expanded heads up notification is it is needed (eg dialer).
- Add a user option to enable always expanded on heads up notification
- Add a user option to set the timeout for the heads up view.
- Introduce a snooze button. Every heads up notification has a snooze
button on the top right. If the user press it
heads up is disabled for a certain time (like a do not disturb mode).
The time length is user configurable in settings.
- We had a bunch of user which want to use heads up in a more intrusive
way. Current default behaviour is that a heads up
shows up if the user did not push the heads up of this app into
background. This is due that the system assumes if the user
put it into background he or she do not want to be disturbed by
notifications of this app at the moment. Of course in the moment
the user interacted with the background notification heads up is
activated again. This leads like google suggested in a very
good non intrusive way. Well but some user use it in another way
(especially on immversive mode) and want to be notified on every
notification update of this app via heads up. Due of this understandable
other user behaviour we add an option for it to allow
this scenario.
- Detect direction of the swipe. Left swipe will dismiss the
notification (if it is not a non clearable). Right swipe will just
hide the heads up and the notification is still in background accessable
in the notification drawer.

Other then that some fixes were done as well (eg utilize the back
button, correctly handle the hiding of the heads up,
handle action buttons on heads up view correctly, fix several expanded
desktop and immersive issues
and some other issues the AOSP implementation currently has)

To summarize...heads up this way is very non intrusive and especially we
do not need a bunch of settings or blacklists.
So it is pretty straight forward, fast, clean and user friendly.

Some visual examples:

https://plus.google.com/107859134357373490612/posts/bJABHs1aNMj