Kiss: Feature request: show badge count on app icons

[diego-suarez]

AFIK, there is no Android standard yet that apps can use to show badges on launchers, but many of them implemented their own solution. It would be good to reuse the implementation on most common launchers/apps, or, if not possible, implement a custom solution for KISS. The last solutiion requieres effort from app developers, so, I think that a good start is to research how apps are showing badges on other launchers nowdays.

[ntninja]

I did a quick survey of the problem space and found ShortcutBadger, which implements support for badges on about 15 different launchers currently. Considering that this library (and its several forks) is probably what most app developers use (who wants bother with this stuff, like are you kidding?!?), we could just try to implement support for the DefaultBadger.
Do to a certain quirk in the source code, this will not work on Zuk, Oppo, Vivo & ZTE devices however.

Therefor I'd propose the following action plan:

• Add ourselves as provider of the default API in ShortcutBadger (even if we don't have an implementation yet), so that our launcher will start working on the devices of before-mentioned vendors as well in the future.
• Implement the default shortcut API
• If it turns out that implementing the default API is not enough for any reason, also implement the API of some large device vendor (Sony, HTC, …, not Samsung theirs works only on devices with Samsung firmware)

Comments anybody?

[diego-suarez]

@alexander255
I just made an implementation using the default intent that you mention: android.intent.action.BADGE_COUNT_UPDATE
Here an screenshot:

Its working well, but the detail that I found on my code is that, if an app broadcasts the action to update the badge, im forcing to refresh the UI using dataHandler.reloadAll();.
This is a problem because if you are scrolling on the apps list, and there is a badge update, the list is recreated, and the scroll position is reset.
How can I contribute the work I had done? Because it is no stable due to this.
In a new branch? A pull request?
Thanks in advice!

[nmitsou]

Hi Diego, I would open a new pull request and mention there the issue with reloadAll.
Is it possible to update only the item that broadcasts the new count?

[diego-suarez]

Well, I did.
But now, there is something strange going on that it makes the list scroll to the end anyway.
I couldn't figure out where. I'm just updating a field on the pojo, and calling notifyDataSetChanged of the RecordAdapter on the UI thread, to redraw the list transparently.
I'm not recreating the list at any time (I think).

BTW, about the broadcast receivers used by the apps, I found that, for example, more apps that I use notifies the updates through a ContentResolver on the uri content://com.sec.badge/apps. This is a system used by samsung to display badges (described here). Maybe the apps notify based on the device brand, or installed packages. (I tested on a Samsung device, only with default launcher and KISS installed)

Using the android.intent.action.BADGE_COUNT_UPDATE intent, the apps reporting updates were fewer.

An approach that I did is to register a BroadcastReceiver to different intents, used by different brands/launchers, and parse the badge count and package name (taken from the same stack overflow question):

• com.htc.launcher.action.UPDATE_SHORTCUT
• android.intent.action.BADGE_COUNT_UPDATE
• com.sonyericsson.home.action.UPDATE_BADGE
• And a ContentObserver to listen to events on the Samsung uri content://com.sec.badge/apps

When a badge update arrives (from any of the above), the badge and package name are saved on a new table on the DB, and then notifies the UI, if is on foreground, to reflect the change.
Also, when the launcher is activated, it loads the db again. This is to reflect badge changes when the launcher was on background.

Im making a pull request with that.

So, it should be defined how to subscribe to badge updates:
If its ok to subscribe to many different intents, choose only one, or create a new for KISS.

If the option is to use many intents, an enhancement is to filter by app/time, because some apps could send multiple intents for the same badge update, making the launcher to refresh/save to db many times (once per intent). Right now, if this happens, it updates all the time an intent arrives.

Another approach is to subscribe based on the device manufacturer, or by the other launchers installed. For example, for Sony devices, subscribe only to com.sonyericsson.home.action.UPDATE_BADGE. BTW, I don't know if its ok to use broadcasts defined by other launchers/manufacturers? It's kind proprietary? The apps are broadcasting this info, so I think any other app can use that.. but don't know

[nmitsou]

Thanks for the long description and for implementing this. We would have to test it. Do you know how much the apk size grows?
BTW no one can put you on jail for such reason (not even Sony :-D )

[diego-suarez]

No, didn't measure app size.
So, if there is no problem using other launcher intents, the ideal approach I think is to implement as many intents are available, so most apps that reports badge are shown, independent of the device brand or other launchers installed.

[nmitsou]

Sorry, isn't the shortcutBadger mentioned above a way to avoid implementation for every intent?

[ntninja]

@nmitsou: Unfortunately not: shortcutBadger is for apps that want to display a badge, not for launchers that want to consume badges.

Since this issue is gaining traction and since there were no complaints when I put forward my original proposal, I will see towards adding us to their library at this point through.

[ntninja]

Done: https://github.com/leolin310148/ShortcutBadger/pull/219

[diego-suarez]

Wouldnt be useful to have a history option that shows the apps with "unread" badges first?

[Neamar]

I'm closing this issue for now.
I'll merge the PR once the comments in it have been addressed, but over all it does look good!

@diego-suarez feel free to open a new issue if you want for this other idea