Comments 25
Действительно все подробно, но такой вопрос, а в ICS ни как нельзя добавить уведомлению цифру? Notification.number не работает… Может есть какой хак?
и ещё в том же ICS если обновлять уведомления, то оно всплывает, в предыдущих версиях если время уведомления не менять, то оно всплывает… Тоже как обойти?
синглтон с контекстом?? нет пути! скрепя сердцем поставил вам минус, хотя статья сам по себе хорошая, и пишите вы хорошо.

нельзя хранить статичные ссылки на активити, оно может быть разрушено в любой момент. тысячу раз эта тема поднималась уже. если так хочется синглтон с контекстом — юзайте сервисы. а вообще в вашем случае можно контекст как параметр передавать, либо как приватное поле этот класс инстанцировать.
Фишка в том, что мы каждый раз при вызове getInstance(Context context) передаем контект вызывающей активити. А следовательно, пока жива активити, в которой мы получили ссылку на инстанс — мы и используем этот контекст. А потом, когда начинаем в другой активити использовать NotificatonUtil — прередаем соответсвующий этой активити контекст.
Так то считаю притензию необоснованной
передавать-то передаём, но сохраняем его только в случае, когда instance==null. если же мы вызовем getInstance второй и более раз из другого активити, instance будет неравен null и будет использовать предыдущий контекст
исправил. даже если instance!=null обновляю ссылку на контекст. Теперь точно контекст будет всегда тот.
не хочу казаться буквоедом, но компилятор вроде не пропустит this.context
юзайте instance.context
Хотел о том же написать.

Я после одного проекта, где меня попросили лики убрать, стараюсь не использовать синглтон в Андроиде, потому что ненароком можно чего и сохранить. И вообще статические переменные нужно использовать с очень большой осторожностью и по возможности их избегать.

Если уже сильно хочется синглтон — передавать контекст приложения (getApplicationContext()), а в своем синглтоне проверять, что передаешь.
Можно еще WeakReference использовать, но тогда надо проверять есть ли активити. На мой взгляд это более правильный путь, чем даже сервис держать.
а я с этим толком не разобрался ещё. вы бы не могли в двух словах объяснить, как на основе WeakReference синглтон сделать?
Я имел в виду синглтон создавать как обычно, но контекст хранить WeakReference, тогда при смерте активити gc уберет контекст и все остальное.
Т.е. просто вместо поля
private Context context
написать
private WeakReference context
а когда активити разрушится, context будет равен null, так? как туда запихнуть новое значение? в getInstance проверку делать?
Да. Там придется проверить, если контекст null, то перезаписать его.
Зато это гарантированно спасает от того, что при смерти активити мы будем продолжать держать в памяти и использовать уже неактуальный контекст.
Таки путь есть — 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 — с какого сайта копипейстилось?
Все это как-то не вяжется с заявлением
Давно занимаюсь разработкой под Android
Боюсь данная статья больше вреда принесет неопытным разработчикам, чем пользы. Автор явно поспешил с ее публикацией.
Я очень надеялся увидеть как
схожие события складывать в одно уведомление, а не отображать на каждое событие своё.
по полученному id мы можем обратиться к нашему notification и чтонибуть в нем обновить
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? :)
Таки да, ошибка тут по 10, но вот про values-v9 — указано верно. Т.е. до 9 апи — юзать стили по-умолчанию, а до 9-го апи — это 2.2/Froyo и ниже, смысла создавать проекты с нижним СДК лвл 8 нет уже давно, таких девайсов в обиходе крайне мало осталось. Т.е. если нижний СДК лвл >=9, то это вообще не требуется, в общие стили сразу внести те, что в values-v9 и все.
Пока вы отвечали, рынок и правда изменился :) Оффтопик — API 9 в дикой природе почти не встречается, поэтому если ставить 9, то уже можно сразу 10. А еще лучше фиксировать старый APK и прыгать выше
Only those users with full accounts are able to leave comments. Log in, please.