Как сделать хранение данных в памяти между разными активити с возможностью observe?

Jacen11, чудик, как ты представляешь себе работу с сетью в потоке UI, если Android давным-давно это не позволяет?)))
А если никак, то зачем ты мне пишешь, что не надо это делать в потоке UI?)))
За оскорбления вообще модератору пожалуюсь.

Как сделать хранение данных в памяти между разными активити с возможностью observe?

Jacen11,

это что еще за бред, при чем тут потоки и ретрофит? ничего что ретрофит OkHttp использует?

Дочитай фразу до конца. Это не про потоки.

Как сделать хранение данных в памяти между разными активити с возможностью observe?

Jacen11,

Вы вообще откуда? Фрагменты все используют. Какие еще фреймы?

Да, фрагменты.

загрузку файла значит в главном потоке запускаешь?

Нет. Использую OkHttp, а не Retrofit, поскольку кроме загрузки файла фактически тут ничего и нет. Сам список файлов берется из SharedPreferences.

Как сделать хранение данных в памяти между разными активити с возможностью observe?

Jacen11,

а можно код такого?

А что тут такого, что аж код нужен?
Юзаю registerAdapterDataObserver. Все очевидно.

так никто не делает, все работают с сингл активити

Да? Все открывают диалоговые окна? Явно нет. Бывает, что в диалоговое окно просто не влезет куча данных.
Или хочешь сказать, что все используют единое активити и в нем фреймы? Ну так у них тогда возникнут сложности с аппбаром - придется как-то заставлять его показывать стрелочку "назад", когда открыт фрейм с конкретным элементом списка. И зачем так усложнять?

что ты там используешь для асинхронщины

Для какой асинхронщины?

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

Алексей Уколов, так ли уж непризнанного?) А если бы такое же самое решение, но уже в виде готовой библиотеки (речь не про библиотеку комментариев, а про библиотеку с этими iterable, срезами и т.д.) создали в какой-то крутой компании, выложили в корпоративный npm, написали об этом на хабре, наглядно показали, как они этим решают их проблемы, то оно могло бы набрать популярность или все равно реакция была бы такой же? :)

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

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

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

Алексей Уколов, я же описал, как можно делать срез. Не очень оптимально? Ну уж оптимальнее, чем конвертировать данные туда-сюда, не?
Тебе важно чтобы все канонам соответствовало или реальная оптимальность важнее? Мне - второе. А еще простота кода важна. А конвертации явно усложняют. Тогда как эта тема с итераторами - на редкость элегантная, за исключением 5-10 строчек, которые сам этот итерэйбл опишут под контейнер. Ну так их можно в библиотеку...

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

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

Во-первых, это занимает много времени. Что такое reducer (в Redux, например) знаешь?
Это такой обработчик некоторого события в фронт-енде. Обрабатывает событие, вносит какие-то изменения в стейт, и потом мы этот стейт рендерим в UI. В моем случае событие приходит по сети и нужно его обработать без перезагрузки страницы.
Функция, о которой тут речь, нужна, чтобы помочь сделать самое сложное: внести эти изменения в стейт. То есть она будет использоваться в редюсере. Ты представляешь себе редюсер, в котором происходит переконвертация туда-сюда? Это же лишние тормоза!

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

1. Описанное вами поведение абсолютно некорректно с точки зрения некоторых указанных структур данных и стандарта языка. У объектов, сетов, мапов и т.д. нет никакого range. То, что это можно закостылить не означает, что это стоит делать.

Почему не стоит?
Возьмем Map. И возьмем некоторое событие, которое бывает в 2 вариантах: применимое к одному элементу этой Map и сразу к range.
range - это "от" и "до". Идем по ключам-значениям в мапе от ее начала до ключа "от", затем идем до ключа "до" (обрабатывая каждый элемент), после чего выходим из цикла.
Да, костыль, мы же шли до "от" сначала, а это же лишнее действие! Однако это критично, только если элементов относительно много. А теперь вспомни, что это стейт, который мы прям щас рендерим в UI, и ре-рендерим. Если в нем будет элементов много, то огромные тормоза будут в любом случае.

А почему тут вообще Map? Почему не массив? Очень просто: в нашей системе ключи этих элементов могут не всегда быть последовательными и вообще не всегда числовыми. Поэтому в массиве мы бы тоже так гуляли по массиву в поисках нужного "от", потом бы шли к "до", а не пользовались индексами массива. Только мы еще и в варианте с одиночным обновлением тоже бы искали нужный "от", т.е. одиночный элемент, который надо обновить. А Map нам позволяет хотя бы в этом случае сэкономить.

Вообще доставляют вопли JavaScript'еров о том, какой это все бред. В C++, например, итераторы развиты гораздо лучше и местный Map.get(key) просто возвращает итератор, который позволяет строить от этого range.

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

Aleksandr-JS-Developer, какое чудо? Какие React и Angular в моей библиотеке? В ней не будет ничего специального для React и Angular.
Вот о том, что в ней будет:
Как на JavaScript сделать функцию, способную обрабатывать заданный «кусок» массива или любого другого контейнера?
Кто-то вообще видит этот комментарий? Или почему уже трое человек не могут его прочитать, и представляют себе не то, что там описано, а х... знает что?

Очень хорошая. Только подумайте, а эта библиотека вообще нужна? Нет ли аналогов и почему?

Здесь стоит уточнить, о какой библиотеке идет речь.

Я делаю библиотеку, которую описал тут:
Как на JavaScript сделать функцию, способную обрабатывать заданный «кусок» массива или любого другого контейнера?
Это библиотека - часть моего (нашего) продукта: мгновенные комментарии к темам. И суть продукта именно в том, что там нет ничего уже готового, никакого UI как такового, а только SaaS и логика для работы со стейтом в React, Angular, Vue или чем-либо еще.
И такой библиотеке, разумеется, аналогов нет. Обычно везде делают какие-то готовые компоненты, со своим UI (начиная от отдельных компонентов, скажем тот же чат, и заканчивая CMS), пользователю надо вечно что-то настраивать, писать какие-то плагины, в конечном итоге что-то не настраивается нормально и приходится править потроха кода... А у меня - каркас, который делает всю самую сложную работу (мгновенность комментариев, ее алгоритмы), а остальное пользователь сам реализует как считает нужным.

Но библиотека, в которой должен быть makeArrayIterable, это по-хорошему должна быть другая библиотека. Это должна быть библиотека уже общего назначения, которая просто умеет делать итерабли из контейнеров. Абстрактные итерабли из абстрактных контейнеров, и все.
А моя библиотека, которая для мгновенных комментариев, будет принимать эти итерабли и использовать их как описано в моем вопросе.

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

Aleksandr-JS-Developer,

В объекте ключи/значения не фиксированы по порядку.

Это было бы ценное замечание. Но я знаю.
По факту проблемы с гарантией порядка в Object встречал лишь тогда, когда есть разные ключи, которые начинаются то с цифры, то с буквы и т.д. Если же все ключи, допустим, будут числами, то все нормально. Во всяком случае во всех популярных браузерах + node.js.

Конечно, ещё надо понимать, какие задействованы будут структуры и типы.

В том-то и дело, что любые. Если ты внимательно читал вопрос и комментарии к нему, то уже знаешь, что эта функция должна легко вкатываться в любой проект на React, Angular или Vue, и в его стейт-менеджмент. А стейт - вчера делали на обычных Array/Map/Object, сегодня его делают на Immutable.js (List, Map, OrderedMap). Завтра напишут еще одну библиотеку, и мне придется в эту "масштабируемую функцию" добавлять поддержку этой библиотеки. Послезавтра еще одну и т.д. А у кого-то вообще свой велосипед крутится...

В общем, я так и не понимаю, почему ответило уже 3 человека, но все шарахаются от ES6 iterable/генераторов как черт от ладана. Встречал подобную холодность к ним и в статьях на Хабре... Но ведь они именно для таких вот вещей и предназначены!

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

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

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

Михаил, во-первых, функция в этом случае усложняется, итераторы\генераторы ES6 и форычи как раз для того и нужны, чтобы один и тот же цикл мог работать фактически с любыми контейнерами. А делая отдельную версию под каждый тип контейнера мы пишем "китайский код".

Во-вторых, в любой момент может появиться еще одна либа вроде Immutable и она не будет у меня поддерживаться, для пользователя (которому обещали любые контейнеры) это будет неожиданностью.

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

WbICHA,

Несколько разных функций? Либо много проверок внутри.

Можно, но код самой функции-то в этом случае как раз усложнится.
А с iterable, там будет всего-навсего:
for (var obj of range)
где range - параметр функции. range может быть Array, Immutable List, Map, Set, Object.entries...
А в случаях, когда range нужен не по всему контейнеру, а с такого-то ключа по такой-то и\или в обратном порядке, можно сделать генератор (почитай про генераторы ES6), и этот генератор и будет этим range. А помочь пользователю сделать генератор - это задача уже совсем другой функции...

Второе - и самое главное - если делать проверки, то в любой момент может появиться еще одна либа вроде Immutable и она не будет у меня поддерживаться.

Если у листа, сета и массива одинаковая структура (в значение передаётся значение), то мап передаёт в значение [key, value] и как ты это учтёшь?

Ну читай внимательнее-то вопрос! Вон же там третий параметр get, это arrow function, который и будет вот из этого:
for (let ВОТ_ИЗ_ЭТОГО of range)
получать нужные данные.
get напишется пользователем под тот контейнер, который и пойдет в range.

А если будет передан объект? А строка? И то, и то, итерабельно, но уже по своему.

Объект там нужен разве что в качестве этакой "мапы", а строка и вовсе не нужна, см. первый комментарий к вопросу, где я описываю, зачем вообще это нужно.

Как сделать функцию, способную обрабатывать заданный "кусок" массива или любого другого контейнера?

Михаил,

не слишком много ответственности на 1 функции?

А что можно с этим сделать? Функция будет в библиотеке, использоваться разными людьми в разных проектах. Это такая библиотека для написания форм обсуждения в комментариях, причем в реальном времени. Мы предоставляем пользователям не готовый "виджет", а только сам сервис (бек-енд) и вот эту библиотеку, чтобы в любом приложении можно было получить комментарии под такой-то темой (с помощью функции библиотеки), сложить их в стейт в том виде, в какой пользователь считает удобным (кто-то использует Immutable, кто-то нет, кто-то захочет Map, где ключом будет какое-то из полей объекта и т.д.), затем рендерить этот стейт с помощью React/Vue/Angular, а когда приходят какие-то события от бек-енда - применять их к стейту в реальном времени с помощью других функций библиотеки.
Алгоритмы непростые получаются, поэтому и нужна библиотека, чтобы не делали свои кривые велосипеды.

Является ли хорошей практикой в юнит-тестах всегда использовать === вместо ==?

Aleksandr-JS-Developer, "100.000 км не пердел" (c)
А юнит-тесты ты не пишешь или там у тебя тоже кругом ===?

Является ли хорошей практикой в юнит-тестах всегда использовать === вместо ==?

WbICHA, ну тесты - это вообще такой код, который пишется не идеально с точки зрения именно кода ) Ты еще ООП туда предложи ) и SOLID

Какие еще преимущества у юнит-тестов, кроме того, что они отлично обеспечивают регрессионное тестирование?

Saboteur,

Если с момента создания класса, к нему сразу есть юнит тест, это означает что больше этот код целиком вычитывать не нужно.

Глупость. Вот ты создал класс, и допустил в нем ошибку по невнимательности. Вот ты написал юнит-тест, прогнал его. А он, допустим, НЕ выявил эту ошибку, потому что она "черный лебедь". И вот ты имеешь код с ошибкой и юнит-тест к нему, который не находит эту ошибку.
И найти ее теперь можно, только вычитав код.

Есть и еще более прикольный вариант: это когда допускаешь ошибку не столько реализации кода, сколько самого проектирования алгоритма. И спокойненько пишешь тест... который проверяет работу реализации алгоритма... а реализация-то правильная.
В этом случае, возможно, ошибку удастся найти и без вычитывания, просто надо вернуться к этому коду спустя время и посмотреть на него с другой стороны А еще лучше - попросить коллегу сделать это. Но так или иначе, это тоже пример случая, где тест, написанный сразу вместе с кодом, не только не помогает обнаружить баг, но и мешает.

или в очень маленькой команде (3-5 разработчиков), а в проектах, над которым работает несколько десятков людей ты не работал.

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

ИМЕННО от этого и выручает автоматическое тестирование, первый шаг в котором это юнит тесты.

Это ты зачем написал? Чтобы я повторил для тебя, как для прапорщика? Ок.
Повторяю: нет, оно от этого не спасает. Я же тебе написал, почему оно не спасает. Потому что баг типа "черный лебедь" требует множества условий, чтобы проявиться. При автотестах невозможно создать такое, не зная заранее, что в коде есть баг. И при ручных тестах не создать. Только вычитыванием можно такой баг найти.
А еще раз повторить?

Какие еще преимущества у юнит-тестов, кроме того, что они отлично обеспечивают регрессионное тестирование?

Saboteur, видишь ли, чтобы написать юнит-тест не на "от...тесь", нужно фактически вычитать весь код, и вдобавок собственно написать юнит-тест.

То есть это ещё тяжелее и дольше, чем просто вычитать весь код. А ведь и просто вычитать весь код - это тоже отнюдь не просто. Это сложно, это тяжело.

Именно поэтому все юнит-тесты на самом деле пишутся на "от...тесь". И на самом деле они обладают гораздо меньшим покрытием кода, чем заявляют разработчики. Достаточно взять любой модуль, тестируемый ими, и попытаться испортить его так, чтобы баг был, но тесты не сломались. Самый простой, очевидный, смешной вариант - это воткнуть туда что-то типа:
if (random() == magic_number) crash();
Это, конечно, уже стеб, но в каждом стебе есть доля смысла. В данном случае это иллюстрация полной неэффективности тестов против багов типа "черный лебедь", например переполнений числовых типов, которые возникают лишь на больших значениях. И далеко не всегда это большие значения входных параметров модуля. Если там какие-то сложные расчеты, то х... ты покроешь это тестом, даже если поставишь цель - протестить вот здесь переполнение. А таких "здесь", с возможными переполнениями, может быть в каждом втором модуле, если не в каждом первом...

Ну, и еще одни момент: ты не совсем прав, когда говоришь, что если делать на "от...тесь", то будут баги. На самом деле баги еще характерны для, наоборот, очень трудолюбивых и увлеченных людей. У них от переутомления падает внимательность, а это верный способ наплодить самых жутких "черных лебедей", как и другие ошибки. И вот это уже никак не решить, кроме вычитывания и вообще перепроверки всего и вся.

В какой компаниях и отраслях программирования ценят не быстрое, не модное, а работающее как часы?

Вячеслав Шиндин,

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

Вот видишь. А ты к ошибке в моем вопросе придрался. Да, я не очень проверяю свои посты на отсутствие ошибок. И деловой этикет у меня тоже такой - где надо - там на высоте, где нет - там вот как с тобой.

Какие еще преимущества у юнит-тестов, кроме того, что они отлично обеспечивают регрессионное тестирование?

Алексей Уколов, в том, что тупо такое применение джунам находить, что и отметил в вопросе. Если в проекте а) зеленые джуны б) надо найти им применение, да еще чтобы создавали какую-то "часть-продукта", то проект - плохой, денег в нем - мало, и надо это понимать.