static HashMap<> - являются ли добавленные данные статичными

[Mikhail_dev]

Это ответ на то, почему нельзя использовать статики и надо использовать динамики? Это как бы вообще несвязные вещи.

System.exit(0) убивает приложение
+
Убитое приложение теряет все статик ссылки
=
System.exit(0) убивает все статик ссылки.

Выключение телефона
+
убитое приложение теряет статик ссылки
=
выключение телефона убивает статик ссылки

Ну серьёзно, логики в словах нет. Я просил сказать почему статики плохо. Ты привёл пример, которому неважно, статики это или нет.

[klblk]

Рискну ответить, что KamiSempai имел ввиду, что хранить что-либо в статик ссылках плохо, и именно это он написал:

Я советую ни когда не использовать статик переменные, если в них хранится какая, либо нужная информация. Логику в статике можно хранить, но ни как не данные.

Т.е. статик ссылки не плохо в общем, но плохо в этом случае (топик).
А представленный код симулирует процесс убивания приложения системой, и следовательно потерю данных в статик ссылках.

[KamiSempai]

Слава семи богам! Наконец-то появился человек который меня понимает!

[Mikhail_dev]

Да вы троллите что ли меня??

Рискну ответить, что KamiSempai имел ввиду, что хранить что-либо в статик ссылках плохо

Плохо потому что сегодня зима? Или плохо потому что я сегодня проспал? А быть может потому что рубль падает? Конкретики - ноль!

Т.е. статик ссылки не плохо в общем, но плохо в этом случае (топик).
А представленный код симулирует процесс убивания приложения системой, и следовательно потерю данных в статик ссылках.

В каком конкретном случае? Это фигня, а не конкретный случай. Вы вызывает код, который убивает всё! а не конкретные статик ссылки. Причем тут статик ссылки вообще? Если я выключу телефон (по секрету расскажу я вам), статик ссылки тоже затрутся. Неожиданно! Не правда ли?

[KamiSempai]

И так, постараюсь привести пример не разумного применения статиков и как мой ранее приведенный код может в этом помочь.

Есть активность.
[syntax=java]public class MainActivity extends ActionBarActivity {

public static String sStaticString;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
setTitle("MainActivity");

sStaticString = "Static Text";
}

public void onClick(View view) {
startActivity(new Intent(this, SecondActivity.class));
}
}[/syntax]Все предельно просто. При создании записывается значение в статик ссылку, по нажатию на кнопку запускается второе активити.

Вот разметка
[syntax=xml]<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical" android:layout_width="match_parent"
android:layout_height="match_parent">

<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="New Button"
android:id="@+id/button"
android:layout_gravity="center_horizontal"
android:onClick="onClick" />
</LinearLayout>[/syntax]

Второе активити
[syntax=java]public class SecondActivity extends ActionBarActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

setTitle("Static string length = " + MainActivity.sStaticString.length());
}

public void onClick(View view) {
Thread systemExitThread = new Thread() {
public void run() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
return;
}
runOnUiThread(new Runnable() {
public void run() {
System.exit(0);
}
});
};
};
systemExitThread .start();
}
}[/syntax]Разметку новую делать не стал взял из главной ативити. По нажатию на кнопку запускается код по убиванию приложения через 5 секунд. Статик ссылка здесь используется для присваивания заголовка.

Это весь код. Теперь запускаем приложение, жмем на кнопку, открывается второе активити, жмем еще раз на кнопку во второй активности, и сворачиваем приложение. Ждем 5 секунд и разворачиваем. Итог - падение всего приложения.

И не надо говорить, что ошибка в примере глупая и нужно на null проверять. null в статике может быть запрятан так далеко, что сразу и не поймешь.
Кстати, всем советую делать такую проверку для все активити в своих приложениях. Так как ни кода не угадаешь как поведет себя приложение если система его убьет.
У меня количество неизвестных ошибок в баг репортах снизилось в разы, после того как я начал применять этот подход.

В заключение:
Если закомментировать строку: setTitle("Static string length = " + MainActivity.sStaticString.length());
ошибок не будет. И даже стек активностей сохранится. Если нажать кнопку назад, мы вернемся на главное активити. То есть, приложение ведет себя так, будто и не было убито.

[altwin]

Хранить статическую строку -это конечно круто, но надуманные примеры изначально не корректны. Почему бы не использовать статики к примеру для больших массивов, которые после проведения вычислений и переходе в другое активити именно благодаря тому, что они статики будут уничтоженны? Собственно плюсов и минусов от использования и не использования static полей и методов более чем достаточно и сомневаюсь я что вопрос использовать или нет имеет правильный ответ. Изачально любой ответ - не верен. Всегда есть место где от использования чего то можно получить профит, или проблемы. static - это просто топор из которого не нужно пытаться варить кашу... но и рубить дрова без него пытаться тоже не нужно, оно того не стоит.

К примеру я всегда ( почти ) любой тип массива делаю статичным, ровно как и методы не привязанные к activity, а просто выполняющие какую то вспомогательную обработку данных. Также я часто использую inner классы, статичность которых меня полностью устраивает.

А по поводу переменных... трудно сказать я вообще в них нчиего не храню. Переменные используются как промежуточное средство при выполнении какой -либо операции и опять таки ну очень часто мне нужно, чтобы они были статичны. Я НИКОГДА не провожу переменную по коду, т.е. если я в нее что -то записал но куда то ушел без чтения - она мне не нужна и я что -то делаю не так, пусть лучше она будет уничтоженна. Как по мне это ну очень странно хранить переменные в ожидании что где то или кто -то к ним обратится.

[KamiSempai]

Хранить статическую строку -это конечно круто, но надуманные примеры изначально не корректны. Почему бы не использовать статики к примеру для больших массивов, которые после проведения вычислений и переходе в другое активити именно благодаря тому, что они статики будут уничтоженны?

Разве статик переменные уничтожаются? В любом случае нужно будет позаботиться о том, что бы не наткнуться на нулл. Временный массив - это то что не относится к текущему случаю, автор топика хранит в статике важную информацию.

К примеру я всегда ( почти ) любой тип массива делаю статичным, ровно как и методы не привязанные к activity, а просто выполняющие какую то вспомогательную обработку данных. Также я часто использую inner классы, статичность которых меня полностью устраивает.

Мы говорим про статичные переменны

А по поводу переменных... трудно сказать я вообще в них нчиего не храню. Переменные используются как промежуточное средство при выполнении какой -либо операции и опять таки ну очень часто мне нужно, чтобы они были статичны. Я НИКОГДА не провожу переменную по коду, т.е. если я в нее что -то записал но куда то ушел без чтения - она мне не нужна и я что -то делаю не так, пусть лучше она будет уничтоженна. Как по мне это ну очень странно хранить переменные в ожидании что где то или кто -то к ним обратится.

Именно к этому я и клоню.

Мои варианты для использования статик переменных:
- Ленивый Синглтон, который сможет восстановиться в случае уничтожения;
- Пулы и кеши.
Все больше я ни чего придумать не могу, все остальное - это статик константы, но они к данному вопросу не относятся.

[Foenix]

Временный массив - это то что не относится к текущему случаю, автор топика хранит в статике важную информацию.

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

[Mikhail_dev]

Проверю на следующей неделе пример Дениса. Точнее узнаю почему оно так.
altwin, меня интересует почему именно статики плохи, а динамические переменные хороши. Я хочу понять причину сего дела.

[Foenix]

http://stackoverflow.com/questions/7026 ... dered-evil

[KamiSempai]

http://stackoverflow.com/questions/7026 ... dered-evil

Тут рассказывается о том, чего плохого в статик переменных у java. В Андроиде даже private static может повлечь за собой проблемы не описанные в том посте.

[Mikhail_dev]

Если статик переменные зло, то синглтон подвержен уничтожению? Получается что и синглтоны зло, потому как могут заново инициализироваться?

[Foenix]

а что мы теперь, на джаву исключительно через призму андроида смотрим?

и я никогда не использовала private static, наверное)) ну разве константы строковые
я думаю, того, что там описано вполне достаточно.
Опять же - автор темы пытается заменить глобальную переменную статической - то же что и описывается в ссылке и не раз.

однако вот тут
http://developer.android.com/guide/faq/framework.html
говорится, что использовать статики можно для этих же целей

A public static field/method

An alternate way to make data accessible across Activities/Services is to use public static fields and/or methods. You can access these static fields from any other class in your application. To share an object, the activity which creates your object sets a static field to point to this object and any other activity that wants to use this object just accesses this static field.

[Foenix]

Если статик переменные зло, то синглтон подвержен уничтожению? Получается что и синглтоны зло, потому как могут заново инициализироваться?

я вообще нигде не читала, что синглтоны это классно, тока наоборот.
Я вообще удивлена, что вы их так часто используете.
Там тоже по сути можно хранить только легко восстановимую информацию.

[Mikhail_dev]

Если наоборот, то почему этот паттерн такой известный, и почему он также фигурирует в паттернах банды четырёх?
И да, а как поступать в ситуациях:
1. когда мне в приложении надо единожды инициализировать что-то путём сетевого запроса и в дальнейшем это использовать в коде?
2. к примеру я пишу трек местоположений. Как мне без кеша тут справиться?
Сохранять в физическую память - слишком частые обращения к внешней памяти. Как тут без кеша работать, я не знаю. Либо как кеш сделать без синглтона, тоже не понимаю.

[altwin]

Если наоборот, то почему этот паттерн такой известный, и почему он также фигурирует в паттернах банды четырёх?
И да, а как поступать в ситуациях:
1. когда мне в приложении надо единожды инициализировать что-то путём сетевого запроса и в дальнейшем это использовать в коде?
2. к примеру я пишу трек местоположений. Как мне без кеша тут справиться?
Сохранять в физическую память - слишком частые обращения к внешней памяти. Как тут без кеша работать, я не знаю. Либо как кеш сделать без синглтона, тоже не понимаю.

Вообще все, что плохо иногда бывает хорошо, ровно как и наоборот. Ну а если по теме основная беда синглтона в lazily инициализации и контекстах. Конечно если ты используешь глобальный контекст то все ок, но не ясно зачем тебе вообще синглтон. Ты можешь вообще никаких инстансов не создавать. Другое дело с тем, что делать если этих самых scope много. В случае lazily инициализации ты не всегда можешь корректно проверить существование объекта и getInstance будет вызванно в разных контекстах несколько раз.

[altwin]

Проверю на следующей неделе пример Дениса. Точнее узнаю почему оно так.
altwin, меня интересует почему именно статики плохи, а динамические переменные хороши. Я хочу понять причину сего дела.

Основная беда в том, что статики инициализируются вместе с классом и уничтожаются с ним и переопределенны могут быть в другом месте. Но опять же я не говорил, что это плохо, я просто говорил, что это по разному. Вся суть в том, что в java есть три сегмента памяти, это Стек, Куча и Код, если стек содержит локальные переменные и ссылочные, а куча только созданные в рантайме объекты с значением их полей, то код -это именно то место где компилируется байт код и в память загружаются переменные. И именно тут может быть очень много неуловимых ошибок. Работа со static переменными чем то даже похожа на работу с памятью в плюсах ( если конечно ты хочешь реально контролировать низкоуровневую оптимизацию ).

[Mikhail_dev]

А что же касается кучи? Она не выгружается сама? Беру тот факт, что на объект кто-то ссылается.
Допустим у меня есть класс NetworkHelper (singleton), в нём есть обработчик, который "слушает" наличие интернета, и при изменении меняет флаги, есть ли интернет или нет. Также в нём реализован паттерн обсервер. Т.е. мы можем зарегистрироваться на получение информации о том, что интернет появился или исчез. Я сделал данный класс как синглтон (а как еще его можно сделать??). Если instance переменная статическая, то по тому что ты говоришь, она может быть без проблем выгружена. Значит что мы можем по сути потерять всех обсерверов, которых мы оповещаем? А в некоторых случаях еще и утечку получить, ведь динамические объекты не удалятся и будут висеть?
Как вообще тогда надо реализовывать паттерн обсервер?

[KamiSempai]

А что же касается кучи? Она не выгружается сама? Беру тот факт, что на объект кто-то ссылается.
Допустим у меня есть класс NetworkHelper (singleton), в нём есть обработчик, который "слушает" наличие интернета, и при изменении меняет флаги, есть ли интернет или нет. Также в нём реализован паттерн обсервер. Т.е. мы можем зарегистрироваться на получение информации о том, что интернет появился или исчез. Я сделал данный класс как синглтон (а как еще его можно сделать??). Если instance переменная статическая, то по тому что ты говоришь, она может быть без проблем выгружена. Значит что мы можем по сути потерять всех обсерверов, которых мы оповещаем? А в некоторых случаях еще и утечку получить, ведь динамические объекты не удалятся и будут висеть?
Как вообще тогда надо реализовывать паттерн обсервер?

Очевидно, что NetworkHelper должен инициализироваться при попытке получить инстанс. В качестве заведующего обсервером должен выступать объект имеющий жизненный цикл, например, Activity. Регистрироваться она будет в onCreate а отписываться от регистрации в onDestroy. Про утечки беспокоиться не стоит, так как при убивании процесса теряются не только статики но и динамика.

[Mikhail_dev]

Денис, ты не понял. Что если NetworkHelper очистится в момент, когда у него УЖЕ ЕСТЬ объекты, которые ему стоит уведомлять? Тогда мы потеряем их. И к тому же, мы их можем не то что бы потерять, а потерять на них только ссылку, и получим утечку. И утечка будет, потому что процесс не умирает при появлении утечек. Он умирает лишь тогда, когда памяти нет. А памяти может и хватать, только вот тормозить будет.