Не знаю як говорять гуру, але в мене стосовно MVC наступна думка. Первинним є розділення view і model. Controller є вторинним.

Зокрема я вважаю що activity — це «товсте» view. Клас який є макетом використовуваних в аплікації даних — це model (тут як і всюди, нічого нового). А от контроллера може й не бути. Хоча якщо в аплікації є всякі сервіси, асинк таски, ресівери, то я розглядаю їх як елементи контроллера.

А в чем конкретно в данном случая проблема с «глобальностью стану»? Вы ее можете описать?

Багато чого наведено тут c2.com/...VariablesAreBad

Від себе додам ще таку річ. Давайте абстрагуємося і проведемо деяку паралель. Виклик activity замінимо на виклик метода, а передачу даних в activity — на передачу даних в метод.

}

}

}

АЛЕ це покращення можливе тільки в нашому спрощеному прикладі, бо тут ми оперуємо звичайним методом. У випадку ж з activity ми не можемо собі такого дозволити і залишаємося з гіршим варіантом — Варіантом 2. Але ми повинні розуміти що це дійсно нехороший варіант. І якщо нам тим не менше треба до нього прибігати, то значить ми свідомо йдемо на певні жертви. Хоча ці жертви можливо й оправдані (бо інакше ми просто не розв’язжемо поставлену задачу).

А в чем конкретно в данном случая проблема с «глобальностью стану»? Вы ее можете описать?

Інформація на цю тему доступна й в інтернеті. Якщо поцікавитеся, легко знайдете. Але я не кажу що глобальність тут є кінцем світу, просто напевно це все-таки недолік (хоча в деяких випадках можливо й оправданий).

Я его привел как альтернативу использования Parcelable

Я думаю що мейнстрімом для виклику activity є саме Parcelable. І якщо хтось буде використовувати описаний вами підхід в тій більшості випадків, де має бути використаний Parcelable, то це буде погано. Тобто наголос саме на цій ідеї.

А обсуждаемый вопрос фактически сводится к тому, как организовывать архитектуру работы с данными, и как выглядит MVC на этой платформе.

Це обговорення почалося з першого поста в якому звучало питання. Я особисто був трохи не згідний з постановкою питання. Бо постановка підрозумівала те що групу величин можна об’єднати в клас тільки для того щоб їх було легше передавати. Тоді як я кажу що те об’єднані величини в клас чи не об’єднані за великим рахунком не є НАСЛІДКОМ того чи вони кудись передаються. Об’єднання/необ’єднання величин в клас є по суті фундаментальним рішеням (ПРИЧИНОЮ) без якого взагалі не можливе існування правильної моделі даних в аплікації. (А розмова про все решта — то вже потім...)

В деяких випадках концептуально неправильно використовувати сервіс замість AsyncTask. Як на мене, не можна просто так взяти й використати сервіс просто тому, що так більше подобається. В сервіса й AsyncTask різні ніші. Тому питання про те, а якже правильно використати AsyncTask, є дійсно актуальним.

Дивіться, я не кажу що те що ви пропонуєте є поганим. Я кажу що можливо воно не таке вже й хороше. Тобто воно має свої недоліки (глобальність стану) і відповідно не може бути якоюсь панацеєю. Бо мені здалося що ви подаєте цей спосіб як мало не єдиноправильний у випадку одного процесу, хоча він напевно підходить все-таки для окремих ситуацій. [А глобальність стану полягає в тому що дані які ви хочете передати є глобальними в рамках аплікації а не локальними для activity.]

Есть масив, он глобальный

А це що по-вашому не варіація на тему глобального стану?

Над рештою подумаю.

Ні, ви неуважно читали той текст, на який я вказував. Не суть в тому, змінна це чи ні. І у вашому випадку глобальний стан звичайно ж буде. А аргументи проти (не всі, але більшість) підходять ще й як.

Тепер стосовно вашої задачки. Скажу так, що я ще не випрацював для себе канонічну стратегію поведінки в даній ситуації. Але це в мене на порядку денному. Як би там не було, я думаю, цією задачею ви ставите правильне питання. Хоча тема ця специфічна, і вона значно вужча ніж тема передавання даних в activity загалом. Деякі люди взагалі говорять що ідея перестворення activity при зміні конфігурації є невдалим архітектурним рішенням команди розробників Android.

Хм...

Ось тут наприклад є деякі аргументи за Parcelable і проти глобального стану:

stackoverflow.com/...tatic-variables

Та не в якості вибірки справа: мода і матсподівання тут не підходять в принципі.

Мода не має нічого спільного з відношенням порядку на множині. Про яке визначення середнього значення з множини за її допомогою можна взагалі вести мову? Запитання риторичне.

А матсподівання — це по суті узагальнене середнє арифметичне. Тобто у випадку зарплат, це було б мабуть середнє арифметичне зарплат всіх працівників, коли кількість працівників прямує до нескінченності. Причому може бути так, що абсолютна більшість працівників реально отримує зарплату меншу від цього середнього арифметичного, бо просто ті хто багато заробляє «витягують» це середнє арифметичне наверх. Тобто якогось практичного змісту в матсподіванні як критерії визначення середньої зарплати немає.

Медіана ж видається цілком нормальним інструментом. Вона чітко говорить, що одна половина працівників має зарплату не більшу від певного числа, а інша половина — не меншу.

Та не смішіть. У вас професіонал — це просто небезробітний. Може я неправильно зрозумів, але з вашого визначення, на мою думку, виходить саме так.

Когда тебя это беспокоит

Коли хвилює, це класно. Сувора правда життя полягає в тому, що час від часу треба робити те, що не є комфортним. Так можна досягнути чогось нового — «вийти з матриці».

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

Коли ти намагаєшся вийти з «матриці», все за її межами здається чужим. Для того щоб подолати цю ілюзію, потрібні певні зусилля. Це і є та ціна, яку треба заплатити за вихід. Але вийшовши з «матриці», ти стаєш частиною нового світу — там більше немає нічого чужого.

лучше быть самим собой, не так ли?

Yes.

Але деколи треба виходити за межі своєї зони комфорту, інакше не буде розвитку.

Так у кого будет скорее реальная, красивая, живая девушка?

Звучить як шантаж)))

Один я не понимаю к чему товарищ клонит?

Я теж не розумію))) Ви не один!!!!!!

Повторюю ще раз, перестаньте плакатися про якісь відпустки чи ще там щось. Мені це нецікаво та й мова йшла про інше. Не треба нікому тут замилювати очі.

Поясніть мені, в якій країні достатньою умовою для підвищення зарплати є народження дитини. Наперед дякую.

Та перестаньте утрирувати в надії викликати в когось сльозу. Не солідно якось, чесне слово.

Весь світ перед вами в боргу, ага. Всі вам щось винні. Ну признайтеся, любите ж халяву, любите, правда? Ну признайтеся))). Тягне ж вас до неї, рідненької. Ну так трошки, в глибині душі, але єеее). Правда? Ато, як же ж її можна не любити, тим більше якщо вона майже поряд). Иии, буквально на відстані витягнутої руки... Ви ж не робот, кінець-кінцем. На крайняк, можна зробити розумний вираз обличчя і сказати щось типу

А потім верещать що народжуваність гівно....

або якусь іншу фразу яка буде підходити до контексту розмови.

А ребёнок тут при чём?

А ніхто не знає при чому. Крім Ольги, звичайно. На її думку, компанія несе відповідальність за народження дітей в сім’ях працівників. Напевно це якось пов’язано з темою сексу на корпоративах із сусідньої вітки.

и в этом мы по одну сторону

От і добре)))

А щодо «жалюгідної обмеженості», ну, трохи грубо, згідний... Але хтось мусів це сказати. Як би там не було, давайте залишимо темні відтінки в минулому і будемо дивитися вперед. Я надіюсь в новому році на нас чекає дуже багато хорошого.

Ви, очевидно, будете здивовані, але ІНКОЛИ в займанні принципової позиції немає нічого поганого.