Про PeerJS понял, спасибо. Мы используем WebSocket и таких проблем нет.
А вот зачем менять offer/answer руками не понял. Какая в этом может быть выгода?
После прочтения статьи возникло несколько вопросов. Можете ответить?
1. Чем плохи публичные STUN сервера? Например тот же stun.l.google.com:19302
2. На сколько я понимаю использовать STUN или TURN решает WebRTC. Если нет, то как это происходит?
3. Чем плохо указывать 2-3 STUN сервера?
4. Я не совсем понял проблему использования PeerJS. Сигнализация же ни как не связана с WebRTC и может быть любой. Что конкретно может пойти не так?
Про WebRTC информации очень много, но она рассчитана или на тех, кто с ним еще не работал, или очень мутная. Спасают только примеры от Google и исходники.
Из статьи можно понять, что для работы вам понадобиться два сервера (сигнальный + TURN). На этом полезная информация заканчивается… Протокол обмена offer, answer и candidates описаны в туториалах довольно подробно.
При этом не освященных нюансов очень много.
Например сложно найти информацию о том, что можно во время установленного соединения сгенерировать еще один offer для других MediaDevices и все будет ок. Или о том, что WebRTC под native iOS (еще не проверял на других платформах) позволяет создать виртуальную камеру и перенаправлять в нее потоки от задней и фронтальной без каких-либо проблем.
Жестко не хватает good practice по работе с WebRTC. Мы например пришли к StateMachine как на сервере, так и на клиентах. Она нас спасла от кучи проблем с коллизиями при встречных звонках.
Я последний год очень плотно работаю с WebRTC под iOS и если есть вопросы, то могу помочь. Было бы круто, если кто-то сможет поделиться инфой по вопросам:
1. Как быстро восстановить соединения при смене сети пользователем? Например телефон перешел из WiFi в сотовую сеть.
2. Как подружить RTCAudioSession, AVAudioSession и CallKit для воспроизведения сигнальных звуков.
Странная статья. Приводить пример небезопасности гит из-за возможности сделать force push, действительно странно. Очень многое притянуто за уши и выглядит как детская обида на git.
Тестовые задания отлично показывают чего стоит соискатель, но тратят его время. Я считаю идеальным вариантом, оплачиваемое тз. Пусть по не большому рейты, но за любую работу надо платить. На такие варианты я натыкался всего три раза. Они были объемнее и сложнее чем не оплачиваемые, но хорошо показывали уровень.
Когда надо быстро и дешево записывать большие объемы данных(например съемка спутников), то лучше магнитных лент пока ничего нету. А 60 ТБ за день соответствует скорости передачи данных по USB 3.0
Единственная проблема, читать данные возможно только последовательно.
С производительностью на удивление все хорошо. Единсвенная проблема — старые девайсы, у которых мало памяти. Если хотите их поддерживать то надо быть аккуратным с размером spritesheet'ов.
Facebook через Apportable никогда не прикручивал. Но у них есть свой, адаптированный ApportableFacebookSDK. In-App прикручиваются через StoreKit.
Еще из важного — возможность вписать любой Java код в приложение с помощью Bridge Kit. Так можно использовать фичи, присущие только андройду.
Что касается сторонних либ, то прикрутятся не все. На сайте заявлена поддержка: Adcolony, Chartboost, FlurryAPI, MobileAppTracker, MPLib / Mixpanel, Tapjoy, Vungle.
Если да, то это значит, что item будет находиться не по определенным координатам относительно точнки (0,0), а сдвигаться в зависимости от размеров спрайта puzzle. На разных по размеру экранах, эта точка будет разной.
Да, все так. Actor отправит два эффекта в редьюсер. Первый на отрисовку лоудера, второй с данными через несколько секунд.
Да, спасибо за замечание. Мне искать информацию в оригинальных терминах проще. Добавил еще вариант с локализованным вариантом.
В вашем комментарии все верно. Я просто не понял, зачем надо руками вмешиваться в эту работу.
А вот зачем менять offer/answer руками не понял. Какая в этом может быть выгода?
1. Чем плохи публичные STUN сервера? Например тот же stun.l.google.com:19302
2. На сколько я понимаю использовать STUN или TURN решает WebRTC. Если нет, то как это происходит?
3. Чем плохо указывать 2-3 STUN сервера?
4. Я не совсем понял проблему использования PeerJS. Сигнализация же ни как не связана с WebRTC и может быть любой. Что конкретно может пойти не так?
Из статьи можно понять, что для работы вам понадобиться два сервера (сигнальный + TURN). На этом полезная информация заканчивается… Протокол обмена offer, answer и candidates описаны в туториалах довольно подробно.
При этом не освященных нюансов очень много.
Например сложно найти информацию о том, что можно во время установленного соединения сгенерировать еще один offer для других MediaDevices и все будет ок. Или о том, что WebRTC под native iOS (еще не проверял на других платформах) позволяет создать виртуальную камеру и перенаправлять в нее потоки от задней и фронтальной без каких-либо проблем.
Жестко не хватает good practice по работе с WebRTC. Мы например пришли к StateMachine как на сервере, так и на клиентах. Она нас спасла от кучи проблем с коллизиями при встречных звонках.
Я последний год очень плотно работаю с WebRTC под iOS и если есть вопросы, то могу помочь. Было бы круто, если кто-то сможет поделиться инфой по вопросам:
1. Как быстро восстановить соединения при смене сети пользователем? Например телефон перешел из WiFi в сотовую сеть.
2. Как подружить RTCAudioSession, AVAudioSession и CallKit для воспроизведения сигнальных звуков.
А сколько на данный момент людей прошло квест?
Единственная проблема, читать данные возможно только последовательно.
После прочтения возник вопрос. Можно ли сделать из спрайта кнопку? Или только отслеживать через -touchesBegan?
Facebook через Apportable никогда не прикручивал. Но у них есть свой, адаптированный ApportableFacebookSDK. In-App прикручиваются через StoreKit.
Еще из важного — возможность вписать любой Java код в приложение с помощью Bridge Kit. Так можно использовать фичи, присущие только андройду.
Что касается сторонних либ, то прикрутятся не все. На сайте заявлена поддержка: Adcolony, Chartboost, FlurryAPI, MobileAppTracker, MPLib / Mixpanel, Tapjoy, Vungle.
то итем был бы ровно по центру мозайки.
А так он будет находится выше и левее центра при любом размере экрана.
Если да, то это значит, что item будет находиться не по определенным координатам относительно точнки (0,0), а сдвигаться в зависимости от размеров спрайта puzzle. На разных по размеру экранах, эта точка будет разной.