> Поставщики предлагают 100% аналоги UI
утверждение которое вводит в заблуждение.
в флаттере не 100% аналоги виджетов UI, к примеру в ios клавиатура уходит вместе с VC в NavigationController, в флаттере нет.
Насчет 100% замены iOS блюров тоже терзают сильные сомнения, беглым поиском не iOS приложения/демо с блюром что бы сравнить с нативным.
(если там тоже самое что и в андроидовском демо с cupertino, то это ужас и кошмар)
Понятно что у матрикса возможности шире, но мой поинт в том что имплементация была достаточно наивная, на питоне c blocking IO, если это же апи реализовать
более аккуратно и с non blocking IO было бы на порядки лучше.
> И причём 100 человек держал нормально
держал 100 человек которые активно взаимодействовали с апи и держали лонг пул соединения? у нас были уже большие проблемы с перформансом с кучей чатов 1 на 1 на отдельной машине без федерации к matrix.org
Верстка не меняется — имеется ввиду что никакие layoutParams не меняются, не добавляются вьюшки, не меняется иерархия.
В моем случае при повороте текущие вьюшки не пересоздаются, а просто меняют свои размеры и положения в соответствии с новым размером экрана.
пример: в приложениях Telegram/WhatsApp на экране списка чатов как раз этот случай — иерархия\layoutParams не меняются, а вьюшки растягиваются при повороте экрана.
Я согласен что пересоздание активити нужно учитывать, но в случае поворота экрана я на 100% предпочитаю не пересоздавать его, это удобнее и разработчику и пользователю (меньше тормозит апп, меньше мест где разработчик может допустить баг:) )
конечно такое поведение может не подойти некоторым приложениям где для разных ориентаций разные макеты, но при желании смену вьюшек\их расположения можно наколхозить и в onConfigurationChanged
для 10 людей проблем и не будет, просто даже на небольшом скейле до 100 человек онлайн какой-нибудь ejabberd будет на порядок(и) эффективнее про cpu/ram, понятно что протоколы различаются, просто матрикс был чудовищно неэффективен.
Особенно будет заметно если люди создают кучу чатов 1 на 1, а не сидят в глобальных.
Немного личного опыта: 3 года назад повелся на статью на хабре которая восхваляла матрикс, и мы переползли на него с джаббера в нашей сервисе чатика с поиском людей, поимев огромные проблемы с производительностью.
В момент анализа лично я анализировал только апи которое мне приглянулось как для разработчика клиента, а вот наш серверный человек\все вместе не протестировали производительность, что сильно аукнулось.
не думаю что дела с производительностью сейчас обстоят лучше, но 1.5 года уже не слежу за матриксом.
PS: моб клиенты 1.5/3 года назад были жутко деревянные и кривые, ни в какое сравнение с телеграмом не шли.
утверждение которое вводит в заблуждение.
в флаттере не 100% аналоги виджетов UI, к примеру в ios клавиатура уходит вместе с VC в NavigationController, в флаттере нет.
Насчет 100% замены iOS блюров тоже терзают сильные сомнения, беглым поиском не iOS приложения/демо с блюром что бы сравнить с нативным.
(если там тоже самое что и в андроидовском демо с cupertino, то это ужас и кошмар)
более аккуратно и с non blocking IO было бы на порядки лучше.
> И причём 100 человек держал нормально
держал 100 человек которые активно взаимодействовали с апи и держали лонг пул соединения? у нас были уже большие проблемы с перформансом с кучей чатов 1 на 1 на отдельной машине без федерации к matrix.org
В моем случае при повороте текущие вьюшки не пересоздаются, а просто меняют свои размеры и положения в соответствии с новым размером экрана.
пример: в приложениях Telegram/WhatsApp на экране списка чатов как раз этот случай — иерархия\layoutParams не меняются, а вьюшки растягиваются при повороте экрана.
конечно такое поведение может не подойти некоторым приложениям где для разных ориентаций разные макеты, но при желании смену вьюшек\их расположения можно наколхозить и в onConfigurationChanged
android:configChanges=«orientation|screenSize»
удивительно что вы это пропустили.
Особенно будет заметно если люди создают кучу чатов 1 на 1, а не сидят в глобальных.
В момент анализа лично я анализировал только апи которое мне приглянулось как для разработчика клиента, а вот наш серверный человек\все вместе не протестировали производительность, что сильно аукнулось.
не думаю что дела с производительностью сейчас обстоят лучше, но 1.5 года уже не слежу за матриксом.
PS: моб клиенты 1.5/3 года назад были жутко деревянные и кривые, ни в какое сравнение с телеграмом не шли.
fly(City to, float speed);
sleep(int hours);