Notifications на основе билдера с кастомным лейаутом и картинкой

[recompileme]

Простите за минус от меня, но я не смог сдержаться. Все шло в принципе не очень плохо до активити-заглушек, isAppRunning, isActivityRunning…
Можно задавать логические связи между активити master — detail в манифесте, android:parentActivityName вот это вот все, чтобы автоматом открывать дочку с мастером из нотификейшен.
Лучше проверять авторизован ли юзер и редиректить на авторизацию, если нет, непосредственно в активити
Можно, например обновлять текущую активити из нотификации — PendingIntent.FLAG_UPDATE_CURRENT если юзер кликнул на нотификации вместо заглушек с isAppRunning
if (LoginActivity.isRunning()) — так делать тоже плохо

[recompileme]

вобщем я бы посоветовал пока снять статью с публикации и попробовать ее доработать с учетом замечаний — может получиться неплохая статья про всякие нюансы работы с уведомлениями.

[StanKo]

Во-первых, статья об уведомлениях и их билдере, и эту тему я раскрыл, за исключением клонирования темы уведомлений (стили для TextView и пр) согласно установленной темы на устройстве, о чем прокоментировал andkulikov.
Во-вторых, как я написал — так эту проблему я решил для себя и я не писал, что это правильно, но на самом деле, данная ситуация — это вообще отдельная тема, для статьи в тч. Можете попробовать написать, я так понимаю у Вас на эту тему больше опыта.
В-третьих, в моем частном случае юзер авторайзится лишь раз и получает «вечный» токен. Т.е. выяснить запущено ли приложение по факту авторизации я не могу. Идея с сохранением состояния в SharedPrefs, например, куда можно сохранить не факт авторизации, но факт запуска приложения (типа, а зачем нам кузнец isAppRunning()?), как Вы и предлагаете, мне не нравится и вот почему: если мы запишем туда true, что апп запущен, но по какой-то причине апп упадет, его грохнет система, его грохнет какой-то cleaner или антивирус, сядет батарея, случится внезапный ребут, вобщем разное может случиться, это же ведро, то там так true и останется, и тогда вся логика в пролете, потому что мы будем думать, что апп таки запущен. В моем же решении, как раз статик благополучно при этом умрет и в нем будет false, что и требуется. Да, нет защиты по поводу мультипоточности, это решаемо.

[andkulikov]

ещё когда задаешь кастомный лэйаут для уведомления надо самому возиться с устновкой правильного цвета текста для TextView. лучше всего сделать это через стили. например, чтобы если мы хотим эмулировать стандартное уведомление, которое состоит из двух строк — Title и Text, то первому TextView ставим стиль

style="@style/NotificationTitle"

второму

style="@style/NotificationText"

и теперь описываем стиль. если ещё поддерживаем 2.2, то для него примерно так:

    <style name="NotificationTitle">
        <item name="android:textColor">?android:attr/textColorPrimaryInverse</item>
        <item name="android:textStyle">bold</item>
    </style>

    <style name="NotificationText">
        <item name="android:textColor">?android:attr/textColorPrimaryInverse</item>
    </style>

для 2.3 и выше появился стандартный стиль для этих текстов

    <style name="NotificationText" parent="android:TextAppearance.StatusBar.EventContent" />
    
    <style name="NotificationTitle" parent="android:TextAppearance.StatusBar.EventContent.Title" />

а на android 5.0 сейчас заметил, что с этим стилем цвет опять стал не соответствовать стандартному цвету заголовка уведомлений, а фон уведомлений изменился с черного на белый и нужно и цвет текста поменять. поэтому пока для values-v21 написал так

    <style name="NotificationTitle" parent="android:TextAppearance.StatusBar.EventContent">
        <item name="android:textColor">@android:color/black</item>
    </style>

[StanKo]

Да, спасибо, об этом я действительно умолчал. Подозревал что есть изменения с 5м СДК, кстати это мб баг, который позже исправят и придется еще и values-v22 создавать.