terminator-light, да, я забыл упомянуть, что у меня minSdkVersion 21 :) И тулбар у меня светлый в светлой теме, а в тёмной - тёмный. На всякий случай, вдруг кто-то возьмёт на вооружение.
evgdev, можно не хранить ссылку на SharedViewModel во фрагменте, ведь доступ к ней всегда можно получить через ViewModelProviders. Мой опыт мне показал, что фрагменты не должны делать ничего кроме отображения пользовательского интерфейса, поэтому я их максимально облегчил, а вся логика находится во ViewModel. Правда, я также не использую и SharedViewModel.
Вячеслав Грачунов, можно попробовать User Agent у браузера подделать на Windows 7, например. Видеозвонки должны работать и в браузере после установки плагина.
artem78, я так и делаю - все репы на VPS, работаю по SSH, но ведь это надо уметь настроить, а мы тут с самых азов начинаем. И это нужно, если вдруг сильно трясёшься за свои исходники. А если доверяешь Github, то он выступает как дополнительный надёжный бэкап всех проектов.
Роман, в предложенной мной схеме нигде не упомянут виртуалбокс ) На локальной машине только пишется код, коммитится через Github на сервер - и там тестируется сколько душе угодно.
По вопросу - в папке deploy надо сделать git pull. Все )
Меня сразу смутило в вопросе вот это - "Коды правлю удаленно, на VPS под Ubuntu 18.04". Это же неудобно. Работать надо на рабочей (домашней) машине в удобной IDE со всем комфортом, с нее коммитить в Github-репо, а с VPS соединяться по ssh, и там делать только git pull, то есть выкачивать на сервер с Github. Для этого вполне подойдёт и командная строка. То есть с рабочей машины код улетает на сервер через Github, не надо никакого FTP, он устарел.
Схема работы: рабочая машина -> Github -> сервер. Всегда в одном направлении.
На сервере уже можно в той же командной строке из папки, в которую прилетает из Github, клонировать в любые другие папки, а можно и прямо с Github, если не жалко трафика. В каждой из этих папок можно делать git checkout на нужный коммит.
Git тем и хорош, что это распределенная система контроля версий, можно построить любую схему работы. Однако, чтобы не запутаться и не страдать от конфликтов, работать проще всего в одном направлении, которое я указал выше. Сам делаю так, когда работаю в одиночку, никогда не приходится мерджить.
По советам ПО для Windows я не знаток, но когда приходится работать на этой ОС, пользуюсь Git For Windows. Это очень аскетичное ПО, но зато свободное. Там можно настроить git-команды, чтобы просто тыкать их мышкой из меню. Кто-то любит черепашку :)
1. По ходу обсуждения с заказчиком всё же работать в папке /home/user/repo, а в папке /home/user/deploy делать git pull для отображения заказчику. Переключаться между папками же не сложно, это буквально секунды :)
2. Деплоить прямо с гитхаба и делать git checkout на нужный коммит, тот который является стабильной контрольной точкой. В этом варианте можно работать прямо в этой же папке, но я бы рекомендовал первый вариант, он дисциплинирует и позволяет избежать конфликтов при слиянии.
P.S. Для работы на удаленном сервере по SSH рекомендую утилиту tmux, которая позволяет создавать несколько "окон" с разными папками и быстро переключаться между ними по горячим клавишам.
toha_man, про разницу модулей тоже не скажу, я делал реализацию на Java и с нуля, читая документацию VK.
Добавлю, что в идеале поллинг сервера должен выполняться в отдельном потоке, чтобы постоянно слушать события. А ответы можно слать в основном потоке. Я пока не знаю, может ли возникнуть обсуждаемая ошибка, если шлешь ответ и держишь соединение с Long Poll в одном потоке одновременно. Возможно, на время отсылки ответа нужно сделать паузу в опросе Long Poll, если программа однопоточная, то есть не делать несколько запросов сразу, а формировать из них очередь.
toha_man, в доках есть, просто доки не очень понятно и скудно оформлены. Приведу выдержку оттуда:
Новое сообщение от user_id=123456 с текстом "hello" и двумя вложениями (фото и аудио):
[4,2105994,561,123456,1496404246,"hello",{"title":" ... "},{"attach1_type":"photo","attach1":"123456_417336473","attach2_type":"audio","attach2":"123456_456239018"}]
Событие - это массив, в данном случае user_id находится на четвертом месте, то есть event[3]. Я на питоне не пишу, точную реализацию не подскажу, но должно быть понятно. Каждое событие надо распарсить таким образом, причём структура зависит от типа события, которое всегда находится на первом месте. В данном случае событие с номером 4 - новое сообщение. В других типах событий user_id может быть на другом месте.
Быстро посмотрел на repl.it и увидел, что там дают виртуалку с Linux. В ОС Linux комбинация Ctrl + C шлет системный сигнал SIGINT (прервано пользователем), а Windows 10, видимо, так не может ) Лечится переходом на ОС Linux для разработки, как более нативную среду для таких вещей как python )
В качестве решения быстро нашёл такой кусок кода на Stackoverflow:
toha_man, видимо ты использовал какой-то готовый фреймворк для своего бота?
Ошибка, скорее всего, возникает, когда какой-то прокси на канале между твоим ботом и сервером VK решит, что соединение живёт слишком долго и рвёт его. Это может быть твой провайдер. Именно поэтому VK и советует использовать таймаут 25 сек.
Либо покопайся в классе VKLongPoll и найди метод, где происходит запрос getLongPollServer (их, кстати теперь два groups и messages). Выглядит он так:
и проверь, что таймаут подходящий, либо не заморачивайся - сделай, как написано в первом комментарии от Дмитрий Шицков, т. е. при разрыве - просто соединяйся заново.
P.S. своим первым комментарием я просто хотел донести, что Long Poll - это не вечное соединение, это тот же постоянный опрос, просто каждый запрос держится сервером в ожидания событий для экономии трафика. НО соединение периодически завершается в любом случае (будь то возврат ответа с данными или сброс по таймауту без данных, либо ошибка, потому что какой-то прокси решил, что он главный), так что обрыв соединения с ошибкой - не такая уж и беда, просто соединяйся заново.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
