абсолютно с вами согласен. если хочется запихнуть контекст в синглтон, то это явный признак того, что что-то не так сделано. а пихать контекст в аппликейшен — это какое-то уже совсем наколенное решение. тем более нет уверенности, что он не разрушится (даже если это конекст приложения)
Существенных преимуществ ни в том, ни в другом я на вскидку не вижу. По сути, у вас тот же медиатор, только статичный.
Давайте опишу несущественные. У вас:
— на 1 параметр больше в каждом методе
— дублируется код создания интента
У меня:
— нужно все активити от одного наследовать
— непонятно (как писали выше) как вызывать активити из сервиса (возможно, писать свой абстрактный класс от Service)
Существенных преимуществ ни в том, ни в другом я на вскидку не вижу. По сути, у вас тот же медиатор, только статичный.
Давайте опишу несущественные. У вас:
— на 1 параметр больше в каждом методе
— дублируется код создания интента
У меня:
— нужно все активити от одного наследовать
— непонятно (как писали выше) как вызывать активити из сервиса (возможно, писать свой абстрактный класс от Service)
Нет, ну нет же! Неверна сама идея. Колбеки нужно использовать в такой ситуации, и только их. А использование thread.wait() в 99% случаев неоправданно. А уж тем более для главного потока!
для новичка здесь, с одной стороны, слишком много лишней информации, а с другой — нет конкретных советов и рекомендаций. а для опытному разработчику это всё известно и так
ну вообще я уверен, что если синглтон с конекстом, то это явный признак того, что-то мы неправильно сделали с точки зрения архитектуры
1) если хранить постоянную ссылку на контекст, то получим утечку памяти
2) если сувать контекст параметром к каждому методу, то мы сделаем маленький шажок к говнокоду. Роберт Мартин писал, что такого рода параметры — плохо. а у меня нет оснований ему не верить))
Ага, я понял вашу мысль. Я привык к именно такому стилю именования классов, что бы понятно было не только что он делает, но и как. Например, всем известный StringBuilder — паттерн Builder, в Spring Framework есть ClientHttpRequestFactory — паттерн абстрактная фабрика, в MIDP реализации паттерна комманда назывались FooCommand и тд. Но синглтоны почему-то никогда постфиксом не обозначаются…
В общем, я привык к такому подходу, и пока проблем от этого не получил. Если проблемы возникнут, я поменяю подход.
1) ActivityMediator я использую в нескольких проектах, он у меня вынесен в библиотеку. Отсюда и разделение. Название с упоминанием имени паттерна мне кажется логичнее, так как соответсвует принципу наименьшего удивления — видишь в названии слова Activity и Mediator и уже примерно понимаешь, что класс будет делать.
2) Да, можно было и просто Context использовать. Но у Activity есть метод startActivityForResult. Я здесь выложил не все исходники, только необходимый минимум что бы показать суть. В реальном ActivityMediator у меня около десятка методов. В данном случае да, вы правы, можно было обойтись Context
3) source.android.com/source/code-style.html «Non-public, non-static field names start with m.»
а то бывает что для небольших экранов части контролов на лайауте нет
Давайте опишу несущественные. У вас:
— на 1 параметр больше в каждом методе
— дублируется код создания интента
У меня:
— нужно все активити от одного наследовать
— непонятно (как писали выше) как вызывать активити из сервиса (возможно, писать свой абстрактный класс от Service)
Давайте опишу несущественные. У вас:
— на 1 параметр больше в каждом методе
— дублируется код создания интента
У меня:
— нужно все активити от одного наследовать
— непонятно (как писали выше) как вызывать активити из сервиса (возможно, писать свой абстрактный класс от Service)
я уже сто раз убеждался, что понятия «просто», «правильно» и «работает» чаще всего появляются вместе.
1) если хранить постоянную ссылку на контекст, то получим утечку памяти
2) если сувать контекст параметром к каждому методу, то мы сделаем маленький шажок к говнокоду. Роберт Мартин писал, что такого рода параметры — плохо. а у меня нет оснований ему не верить))
В общем, я привык к такому подходу, и пока проблем от этого не получил. Если проблемы возникнут, я поменяю подход.
1) ActivityMediator я использую в нескольких проектах, он у меня вынесен в библиотеку. Отсюда и разделение. Название с упоминанием имени паттерна мне кажется логичнее, так как соответсвует принципу наименьшего удивления — видишь в названии слова Activity и Mediator и уже примерно понимаешь, что класс будет делать.
2) Да, можно было и просто Context использовать. Но у Activity есть метод startActivityForResult. Я здесь выложил не все исходники, только необходимый минимум что бы показать суть. В реальном ActivityMediator у меня около десятка методов. В данном случае да, вы правы, можно было обойтись Context
3) source.android.com/source/code-style.html «Non-public, non-static field names start with m.»
в википедии на инглише 2 статьи en.wikipedia.org/wiki/Cohesion_(computer_science) и en.wikipedia.org/wiki/Coupling_(computer_science), обе ссылаются на ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
нужно внимательно их прочесть, но завтра — утро вечера мудренее)
в википедии на инглише 2 статьи en.wikipedia.org/wiki/Cohesion_(computer_science) и en.wikipedia.org/wiki/Coupling_(computer_science), обе ссылаются на ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
нужно внимательно их прочесть, но завтра — утро вечера мудренее)