Pull to refresh

Comments 15

Я думаю что если приложению не нужен офлайн режим, то это идеальное решение с точки зрения цена/качество.

«И причина была банальной: если при сборке мобильного приложения забыли поставить пару галочек»

Поделитесь пожалуйста этими галочками. Как раз намедни воевал с Самсунгами и тут раз и статья в тему.
У меня были две проблемы.
Во-первых, мобильный клиент работал с жестами. И как следствие, частично перехватывал управление. В итоге ребята из мобильной команды внедрили в клиент механизм, который для игр вообще отключал жесты. А для всего остального проверял эту необходимость по canScrollVertically.
Во-вторых, в самой верстке пришлось отказаться от overflow:hidden на корневых элементах. Это свойство препятствовало детектированию скролла в WebView.
Забавно, при этом весь код локально на десктопе всегда работал без запинки да? ))
И на десктопе. И в мобильных браузерах на реальных устройствах. И в эмуляторах. Все самое интересное начиналось при открытии в WebView. Мы даже тестовые веб-аппы делали только для проверки возможностей в реальных мобильных клиентах.
Сейчас для решения своих проблем копаюсь в интернете, и тут я вспомнил, а ведь есть такая штука как Crosswalk WebView Cordova Plugin (правда она для вас не подходит, а для меня в самый раз). Плагин тянет себе в apk свою версию хрома, увеличивая размер apk на 17 Мб, а размер установленного приложения на 50 Мб. Да крутой такой оверхед, но если задумываться о цене поиска и исправления всех будущих багов и глюков, то возможно можно и пожертвовать.

Хотя это такое себе решение, если все дружно так будут делать то общий оверхед зашкалит.

Возглас в пустоту: Ну почему тюнинговщики Андроида такие зас***цы и что-то там химичат со встроенным браузером (( Думаешь ну вот оно наступило счастье можно быстро и дешево делать приложения для мобильных устройств и тут такая подлянка.
10к RPS? А какого рода запросы (статика? динамика)? Бэк — нода? Это пик запросов или среднее значение (медиана?)? Если это относительно постоянная нагрузка, то как долго держится и на каком железе?
10К — это пиковое значение. Все запросы — динамические. Северная часть была написана на Node.js с использованием фреймворка Express.js. В качестве железа выступила пара инстансов Amazon EC2. Наибольшую нагрузку приложение получило сразу после публикации в основной ленте работ. Это вообще особенность всех наших веб-аппов — ощутимые нагрузки сразу же после публикации. И спокойная размеренная жизнь спустя пару часов.
А сколько длиться пик? И сколько это в RPS при размеренной жизни?
Пик длится 10-15 минут. Затем нагрузка плавно падает: пользователи смотрят контент и идут к следующему. К концу суток веб-апп стоит практически без нагрузки (менее 50 RPS).
Вот как раз с cordova сейчас воюю.

Приложение часть функционала подгружает с сервера (чтобы обновления выкладывать оперативно, без магазина, ничего незаконного всё честно).

Непонятные глюки были на самсунгах (Android 6), приложение подгружало первый скрипт с сервера но не выполняла его, хотя стояло событие на выполнение кода после полной загрузки скрипта. Порешал поставив таймаут в 2 секунды перед запуском кода загруженного скрипта, проблема исчезла.

Теперь вот сяоми (Android 6) тоже странности, в процессе работы меняется карточка питомца и подгружаются данные выбранного, дак вот данные успешно загружаются но на страницу применяются частично (часть данных остается от прошлого). Еще в процессе решения.

При этом весь код без проблем работает на десктопе в браузере Хром, вообще никаких глюков.

Вот теперь из статьи узнал что оказывается Самсунг какой-то свой браузер делают вместо встроенного.

P.S. В качестве фронта использую Framework7
Нет. Для наших задач эти решения были избыточны.
А чем вы тогда упаковывали приложения в WebView, своими силами через нативный код стандартными средствами разработки платформы Android, iOS?
iFunny — нативный клиент. Поэтому все делалось стандартными средствами.
Sign up to leave a comment.