К сожалению - когда-то. Sybase продала Powerbuilder китайцам, потому что не развивала его больше 10 лет. Просто стригла деньги с него. Поэтому сейчас другие игроки на рынке средств разработки на БД.
Смешно считать PowerBuilder noname - основное средство 4GL для БД за рубежом. Правильнее сказать, это 1С просто ничто по сравнению с PowerBuilder. Когда то. Разработчиков на PowerBuilder требовалось на западе в десятки раз больше чем у нас 1сников. Бешеное количество библиотек под него под все случаи жизни. Лицензия стоила 15000 долларов (https://www.appeon.com/pricing).
Самое интересное - никто не сравнивал 1С и PowerBuilder. Хотя видел аналоги 1С, написанные на PowerBuilder. И в котором нет затыков 1С, но которые работали на порядок быстрее(https://infostart.ru/public/78413/).
Да что йога — скоро и цигун начнут учить по по смарту
Типа — научим макушечному усилию за 5 занятий
А реально — что делать с 30 летним искривлением позвоночника?
Или как почувствовать ци? Как меня учил хирург с 20 летним стажем — книги — это общие руководства и воспринимать их как истину — большая глупость
Уточнение — в потоковых системах (не реактивных и не во Flutter — это частные случаи реализаций) понятия состояние вообще нет. Это динамические системы. Всё течёт, всё меняется(Гераклит).
При создании копии активити остаются в памяти(в стеке) она сама, а также НЕНУЖНЫЕ ВСЕ объекты, которые связаны с ней. Вы должны каким-то образом удалять ВЕСЬ этот ненужный хлам. Если вы используете потоковую(реактивную) архитектуру это просто ее разрушает. Решение этого — Moxy или пилите свою службу доставки данных(actions) до конкретного получателя(View, Presenter). Кому как нравиться. В меня наверно 20 лет вдалбливали, что данные ВСЕГДА ПАССИВНЫ. UI активен. В потоковых(реактивных) структурах выборка данных всегда полностью отвязана от UI. В UI(Presenter) передаются либо оповещения о прошедших событиях либо неизменяемые данные — по сути архитектура Flutter. Т.е. архитектура выглядит как View->Presenter->Запрос->Выборка данных(бизнес логика)->Результат->Служба доставки->Presenter->View. Служба доставки это Moxy или самописка. Данная архитектура с легкостью льется на Flutter — да на что угодно.
ВСЕ ссылки на активити нужны при случаях создания ненужных копий активити(клики на уведомлениях, обработка Deep Link). И не надо говорить про singleInstance и прочие неработающие флаги(прибамбасы). Со всеми вытекающими последствиями c(над) LiveData. В правильной архитектуре LiveData — абсолютное зло.
Подскажите пожалуйста, что делать — простой переход с libs версий 23.4 (36000 references в приложении) — на 24.2 и мы получаем 85000 references — просто нажатие всего 1 кнопки обновить xamarin.android.support.v4
Вам бы найти спеца по Теории У-Син (5 элементов), и который может правильно интерпретировать события по шкалам. Тогда цены Вам и проге не было. А так красивые графики. Нету достоверного прогнозирования. Нет оценки человека внешних событий, в которой живет человек — он же не в вакууме(без взаимодействия) живет.
Вспоминаю — использовал я EventBus и забыл я что такое слушатели. Опыт использования Контроллера Прерываний при проектировании железа как никак был. И было все шустро и красиво. Но народ почему то плевался. Ну очень нравятся слушатели народу. И перешел я на Service Locator. И плевать мне, делим ли мы на View/Presenter/Router или не делим. И плевать мне на все, что выдумает Google, а завтра это же и обосрет. Главное — решает ли проблемы архитектуры андроид вкупе с задачами клиента или нет. github.com/shishkin1966/CleanArchitecture5
А чем сервис локаторы становятся хуже с ростом проекта. В окружающей жизни чем больше город, тем сервис локаторы все больше и изощреннее. И наоборот DI сходят на нет
В добавок — сервис сетевых запросов должен учитывать — потерю заказчика(приемника инфы/данных сетевых запросов) и последующую за этим отмену(или оставление выполнения) всех запросов заказчика. При этом должны быть продуманы средства доставки данных всех выполненных запросов заказчика при его появлении (например посредством аналога электронной почты).
Пример — сетевые запросы. SL должен предлагать:
— отслеживать наличие сети
— ранжирование запросов (картинки позднее инфы/контента)
— динамическое регулирование полосы (на 2G — 2 запроса одновременно, WiFi — 8)
— использовать кэширование или без
— группирование запросов — проект со 100 типов запросов это не одно и тоже что 1000 типов запросов
Можно конечно собрать спецов по всему этому и попробовать их объединить. Но уж лучше сразу иметь сервис — просто отправки запросов, который это делает на автомате
Пример — поклеить обои. Сервис локатор должен предлагать поклеить:
— бумажные
— винил
— флизелин
— стекло
— на российских шпаклевке/клее
— на импортных шпаклевке/клее
В модели с DI ты должен сам найти дядю Васю, который умеет все вышеуказанное
Автор поднимает вопрос разработки сложных (возможно даже динамических) систем. Я предлагаю перейти от модели «деревни» (где каждый знает о соседе все), к вышестоящей модели «города». Где потребитель сервиса ничего не знает о соседе, но может узнать о всех специалистах, который предоставляют сервисы. Модель DI и их аналоги — это модель «деревни». Например — нужно построить дом. В модели DI:
— ты должен знать их
— ты должен их пригласить
— ты должен поить/кормить/ублажать/убирать за ними
Модель Service Locator или «города»:
— связался с сервисом строителей
— ждешь результата
в модели с сервис локатором немаловажное место занимает подтверждение о работоспособности сервиса. Особенностью модели DI — это требование знать специалистов. С возрастанием(разрастанием) проекта (с увеличением кол-ва специалистов) — это становиться все сложней. В модели с сервисами нет явного учета специалистов(хотя он может быть добавлен) — там увеличивается глубина предоставления сервисов, приводящая к их увеличивающейся специализации.
К сожалению - когда-то. Sybase продала Powerbuilder китайцам, потому что не развивала его больше 10 лет. Просто стригла деньги с него. Поэтому сейчас другие игроки на рынке средств разработки на БД.
Смешно считать PowerBuilder noname - основное средство 4GL для БД за рубежом. Правильнее сказать, это 1С просто ничто по сравнению с PowerBuilder. Когда то. Разработчиков на PowerBuilder требовалось на западе в десятки раз больше чем у нас 1сников. Бешеное количество библиотек под него под все случаи жизни. Лицензия стоила 15000 долларов (https://www.appeon.com/pricing).
Самое интересное - никто не сравнивал 1С и PowerBuilder. Хотя видел аналоги 1С, написанные на PowerBuilder. И в котором нет затыков 1С, но которые работали на порядок быстрее(https://infostart.ru/public/78413/).
Типа — научим макушечному усилию за 5 занятий
А реально — что делать с 30 летним искривлением позвоночника?
Или как почувствовать ци? Как меня учил хирург с 20 летним стажем — книги — это общие руководства и воспринимать их как истину — большая глупость
С возможностью задания любых источников данных/любой стратегии, определяющей размеры начальной и последующих страниц — по умолчанию выбирается 20/40/80 записей. Для быстрого скрола по картам (сетевые запросы) оптимально 5/10/20 записей. Для больших БД в режиме не оптимизированного поиска 5/20/80. И пр. и пр.
github.com/shishkin1966/CleanArchitecture5
— отслеживать наличие сети
— ранжирование запросов (картинки позднее инфы/контента)
— динамическое регулирование полосы (на 2G — 2 запроса одновременно, WiFi — 8)
— использовать кэширование или без
— группирование запросов — проект со 100 типов запросов это не одно и тоже что 1000 типов запросов
Можно конечно собрать спецов по всему этому и попробовать их объединить. Но уж лучше сразу иметь сервис — просто отправки запросов, который это делает на автомате
— бумажные
— винил
— флизелин
— стекло
— на российских шпаклевке/клее
— на импортных шпаклевке/клее
В модели с DI ты должен сам найти дядю Васю, который умеет все вышеуказанное
— ты должен знать их
— ты должен их пригласить
— ты должен поить/кормить/ублажать/убирать за ними
Модель Service Locator или «города»:
— связался с сервисом строителей
— ждешь результата
в модели с сервис локатором немаловажное место занимает подтверждение о работоспособности сервиса. Особенностью модели DI — это требование знать специалистов. С возрастанием(разрастанием) проекта (с увеличением кол-ва специалистов) — это становиться все сложней. В модели с сервисами нет явного учета специалистов(хотя он может быть добавлен) — там увеличивается глубина предоставления сервисов, приводящая к их увеличивающейся специализации.
https://github.com/shishkin1966/CleanArchitecture3/blob/master/README.md
github.com/NewtronLabs/IpcEventbus?utm_source=android-arsenal.com&utm_medium=referral&utm_campaign=5710