Comments 25
Действительно все подробно, но такой вопрос, а в ICS ни как нельзя добавить уведомлению цифру? Notification.number не работает… Может есть какой хак?
и ещё в том же ICS если обновлять уведомления, то оно всплывает, в предыдущих версиях если время уведомления не менять, то оно всплывает… Тоже как обойти?
и ещё в том же ICS если обновлять уведомления, то оно всплывает, в предыдущих версиях если время уведомления не менять, то оно всплывает… Тоже как обойти?
По поводу номера уведомления: code.google.com/p/android/issues/detail?id=21477
Если уведомление создано с помощью билдера, то достаточно вопользоваться методом setNumber()
Если уведомление создано с помощью билдера, то достаточно вопользоваться методом setNumber()
синглтон с контекстом?? нет пути! скрепя сердцем поставил вам минус, хотя статья сам по себе хорошая, и пишите вы хорошо.
нельзя хранить статичные ссылки на активити, оно может быть разрушено в любой момент. тысячу раз эта тема поднималась уже. если так хочется синглтон с контекстом — юзайте сервисы. а вообще в вашем случае можно контекст как параметр передавать, либо как приватное поле этот класс инстанцировать.
нельзя хранить статичные ссылки на активити, оно может быть разрушено в любой момент. тысячу раз эта тема поднималась уже. если так хочется синглтон с контекстом — юзайте сервисы. а вообще в вашем случае можно контекст как параметр передавать, либо как приватное поле этот класс инстанцировать.
быстрофикс «скрепя сердце»
Фишка в том, что мы каждый раз при вызове getInstance(Context context) передаем контект вызывающей активити. А следовательно, пока жива активити, в которой мы получили ссылку на инстанс — мы и используем этот контекст. А потом, когда начинаем в другой активити использовать NotificatonUtil — прередаем соответсвующий этой активити контекст.
Так то считаю притензию необоснованной
Так то считаю притензию необоснованной
Хотел о том же написать.
Я после одного проекта, где меня попросили лики убрать, стараюсь не использовать синглтон в Андроиде, потому что ненароком можно чего и сохранить. И вообще статические переменные нужно использовать с очень большой осторожностью и по возможности их избегать.
Если уже сильно хочется синглтон — передавать контекст приложения (getApplicationContext()), а в своем синглтоне проверять, что передаешь.
Я после одного проекта, где меня попросили лики убрать, стараюсь не использовать синглтон в Андроиде, потому что ненароком можно чего и сохранить. И вообще статические переменные нужно использовать с очень большой осторожностью и по возможности их избегать.
Если уже сильно хочется синглтон — передавать контекст приложения (getApplicationContext()), а в своем синглтоне проверять, что передаешь.
Можно еще WeakReference использовать, но тогда надо проверять есть ли активити. На мой взгляд это более правильный путь, чем даже сервис держать.
а я с этим толком не разобрался ещё. вы бы не могли в двух словах объяснить, как на основе WeakReference синглтон сделать?
Я имел в виду синглтон создавать как обычно, но контекст хранить WeakReference, тогда при смерте активити gc уберет контекст и все остальное.
Т.е. просто вместо поля
написать
Т.е. просто вместо поля
private Context contextнаписать
private WeakReference context
Таки путь есть — Application Context является очень даже синглтоном. В статье же использован Base Context, да еще и в статик-поле хранится — это недопустимо.
А особенно это недопустимо для человека, который заявляет что
Давно занимаюсь разработкой под Android
Странное дело, но в статье:
— в первом методе создания уведомления оно создается с помощью билдера, но при этом в конце используется deprecated метод getNotification() вместо build();
— метод создания уведомления с произвольным отображением написан с использованием deprecated методов, вместо билдера, как предыдущем методе;
— утечки и много попаболи на 100% обеспечены благодаря хранению ссылки на активити в статик-поле;
— хранение lastId и notifications в обычных полях практически бесполезно в разрезе перезапуска приложения при активных уведомлениях, а notifications в статье вообще никак не используется;
— со styles.xml напутано;
— android:launchMode=«singleTop» может привести к неожиданным последствиям, его назначение не раскрыто полностью, хотя это и не цель статьи;
— * This source code was highlighted with Source Code Highlighter — с какого сайта копипейстилось?
Все это как-то не вяжется с заявлением
— в первом методе создания уведомления оно создается с помощью билдера, но при этом в конце используется deprecated метод getNotification() вместо build();
— метод создания уведомления с произвольным отображением написан с использованием deprecated методов, вместо билдера, как предыдущем методе;
— утечки и много попаболи на 100% обеспечены благодаря хранению ссылки на активити в статик-поле;
— хранение lastId и notifications в обычных полях практически бесполезно в разрезе перезапуска приложения при активных уведомлениях, а notifications в статье вообще никак не используется;
— со styles.xml напутано;
— android:launchMode=«singleTop» может привести к неожиданным последствиям, его назначение не раскрыто полностью, хотя это и не цель статьи;
— * This source code was highlighted with Source Code Highlighter — с какого сайта копипейстилось?
Все это как-то не вяжется с заявлением
Давно занимаюсь разработкой под AndroidБоюсь данная статья больше вреда принесет неопытным разработчикам, чем пользы. Автор явно поспешил с ее публикацией.
Я очень надеялся увидеть как
схожие события складывать в одно уведомление, а не отображать на каждое событие своё.
по полученному id мы можем обратиться к нашему notification и чтонибуть в нем обновить
Notification notification = notifications.get(notificationId);
notification.setLatestEventInfo(context, contentTitle, contentText, contentIntent);
manager.notify(notificationId, notifications.get(notificationId));
Notification notification = notifications.get(notificationId);
notification.setLatestEventInfo(context, contentTitle, contentText, contentIntent);
manager.notify(notificationId, notifications.get(notificationId));
Думаю стоит обосновать, почему «одиночка» в данном случае вообще не подходит. Дело в том что жизненный цикл создаваемых уведомлений привязан к конкретному контексту. Поэтому сущность, отвечающая за показ или скрытие уведомлений должна жить в рамках одного контекста. Ваш класс не отвечает на вопрос: что будет с уведомлением после смерти контекста.
По хорошему должен быть один экземпляр, привязанный к активити или к сервису. Скорее всего вам не понадобится создание уведомлений для «дочерних» активити, следовательно разумно привязать экземпляр к классу приложения.
По хорошему должен быть один экземпляр, привязанный к активити или к сервису. Скорее всего вам не понадобится создание уведомлений для «дочерних» активити, следовательно разумно привязать экземпляр к классу приложения.
> А для поддержки API >10 Создаем файл res/values-v9/styles.xml и вписываем:
Так все-таки, в каком апи оно было введено, 9 или 10 или 11? :)
Так все-таки, в каком апи оно было введено, 9 или 10 или 11? :)
Таки да, ошибка тут по 10, но вот про values-v9 — указано верно. Т.е. до 9 апи — юзать стили по-умолчанию, а до 9-го апи — это 2.2/Froyo и ниже, смысла создавать проекты с нижним СДК лвл 8 нет уже давно, таких девайсов в обиходе крайне мало осталось. Т.е. если нижний СДК лвл >=9, то это вообще не требуется, в общие стили сразу внести те, что в values-v9 и все.
Sign up to leave a comment.
Android Notifications. Оповещения через Status Bar