Привет. Правильно понимаю, что проверки выполняются локально прекомит хуком? Когда перед пушем делается пул чтобы поребейзить локальный комит, отметка о пройденных проверках остаётся или надо опять прогнать проверки? Ну и главный вопрос: + 10 минут на комит для контентмейкеров — легко ли они это приняли и точно ли оно того стоит?
Его не для игровой механики используют, а для всей обвязки вокруг. Хотя для MMO RPG игр подобная архитектура используется и для самого игрового мира. Для сессионных же всё, что не касается самого боя: авторизация, биллинг, матчмейкинг, состояние игрока и куча другой обвязки (ачивки, квесты, чат, соц связи, ивенты, нотификации, магазин и т.п.)
Спасибо за интересную статью! Есть несколько вопросов:
1. В статье не сказано про ослабление требований к качеству матча со временем (например, больше очков можно набрать) — применяется ли в каком-то виде или благодаря CCU нет необходимости?
2. Судя по графику у вас в очень большом промежутке CCU время сбора матча держится на уровне 5 секунд и только в момент минимального повышается до 10 секунд. Это могу объяснить только искусственным ограничением минимального времени сбора матча в 5 секунд (ну или гибкому изменению требований по качеству, но в это слабо верю), когда после 5 секунд ожидания матчи собираются обычно мгновенно для игроков. Но это приводило бы к увеличению очереди в момент пика CCU (каждый должен выждать 5 секунд — очередь линейно бы зависела от CCU). Т.е. не могу объяснить два этих графика одновременно — можете помочь? )
3. Длина очереди выходит на плато на уровне 300 игроков — это подозрительно много для игры 7х7. Это из-за очень сложных правил или есть какие-то банальные причины (несколько версий клиентов несовместимых на одном ММ, или входят разные режимы в эти 300 человек)?
4. Правильно ли понимаю, что стоимость сбора одного матча в таком вариант на несколько порядков выше, чем в предыдущем, поэтому пришлось так распараллеливать и во время пиковых значений ослаблять правила? Т.е. во время пикового CCU у вас начинала расти очередь И увеличиваться время ожидания игроков, т.к. ваш кластер ММ не мог подобрать грубо говоря больше 1 матча в секунду?
Ваше представление об MVP в корне неверно. Либо вы читали такие же некорректные статьи, либо некорректно интерпретировали. У вас даже на КДПВ нет ссылки от Model к View. Хотя и она неверна, т.к. связи должны быть односторонними, а в обратную сторону работа идёт через интерфейсы.
Так в Model вы и не знаете про View ни чего
Вы обманываете, т.к. эти ваши
edittext-а, а во втором из spinner-а
— это часть View.
каждая реализация оборачивает свои UI элементы в Model, представляя общий интерфейс доступа к данным.
Я не занимаюсь разработкой под Android, но в идеальном варианте ни Model, ни Presenter не имеют доступа ни то, что к View, но и к пакету android в принципе, т.е. они не знают, что работают под android'ом. И уж особенно нельзя нарушать правила разделения зависимостей между M, V и P — код в разных модулях и зависимости между ними настроены односторонне M<=P<=V, это принципиально.
MVP это про распределение обязанностей и зависимостей, в вашем случае реализация примера должна иметь следующий вид: Пакет Model:
класс с данными ExampleModel Пакет Presenter:
интерфейс ExampleView с методом updateResponse(String response)
класс ExamplePresenter'а с методами doRequest(String response) Пакет View:
класс-реализация интерфейса ExampleView
ExampleView дёргает ExamplePresenter.doRequest, ExamplePresenter устанавливает в ExampleModel данные запроса, и делает запрос на сервер, когда получает ответ, то устанавливает его в ExampleModel и дёргает метод интерфейса ExampleView.updateResponse.
Также важно выделять весь View в отдельный пакет и обращаться только через интерфейсы, т.к. это позволит делать unit тесты, подменив реализации на тестовые.
150 человек добавило эту статью в избранное — кто-то мог воспринять её серьёзно. Рекомендую удалить её пока, ознакомиться с темой более внимательно и написать действительно полезную статью. В качестве хорошей реализации MVP рекомендую ознакомиться с реализацией на www.mvcsharp.org (она на c#, но смысл от этого не меняется). Плюс там есть несколько статей на эту тему. Можете консультироваться, если будут вопросы.
Так как UI элементы в данном случаи будут выступать и как источник данных и элементы для отображение, то ссылки естественно возникают в реализации Model и View, Presenter связывает Model с View.
Нет, это уже не MVP и с ним общего ничего не имеет, кроме названий классов. Что вы будете делать, когда вам понадобится сделать версию под планшет, где, предположим, из-за особенностей UI придётся использовать совсем другие виджеты? Т.е. я ставлю вас перед фактом, что надо поддерживать два набора View с разным набором виджетов. Как вы это организуете в вашем варианте?
Так как Model и View используют одни и тебе виджеты (в нашем случае EditText и TextView) для своей работы, разумно будет реализовать содержащий их класс.ExampleViewHolder.java:
Недопустимо ссылаться на виджеты равно как на любую UI или Presenter специфик логику из модели, теряется весь смысл концепции MVP. В идеале части M V и P разделены на отдельные модули и имеют односторонние зависимости M <= P <= V.
В указанном примере задание @Nullable для переменной излишне, т.к. IDE и так знает, что метод findUserByName может вернуть null. Помечать необходимо все методы, параметры методов и поля классов. Тогда, как показывает практика, NPE уходит из вашей жизни почти полностью.
Интересующимся кодогенерацией по UML под .NET рекомендую глянуть в сторону фреймворка ECO. Он, правда, не ограничивается лишь этим, и включает в себя ещё ORM (лучшую, на мой взгляд). Использовали на прошлой работе и, реально, жалею, что под Java нет ничего подобного.
Привет. Правильно понимаю, что проверки выполняются локально прекомит хуком? Когда перед пушем делается пул чтобы поребейзить локальный комит, отметка о пройденных проверках остаётся или надо опять прогнать проверки? Ну и главный вопрос: + 10 минут на комит для контентмейкеров — легко ли они это приняли и точно ли оно того стоит?
Его не для игровой механики используют, а для всей обвязки вокруг. Хотя для MMO RPG игр подобная архитектура используется и для самого игрового мира. Для сессионных же всё, что не касается самого боя: авторизация, биллинг, матчмейкинг, состояние игрока и куча другой обвязки (ачивки, квесты, чат, соц связи, ивенты, нотификации, магазин и т.п.)
1. В статье не сказано про ослабление требований к качеству матча со временем (например, больше очков можно набрать) — применяется ли в каком-то виде или благодаря CCU нет необходимости?
2. Судя по графику у вас в очень большом промежутке CCU время сбора матча держится на уровне 5 секунд и только в момент минимального повышается до 10 секунд. Это могу объяснить только искусственным ограничением минимального времени сбора матча в 5 секунд (ну или гибкому изменению требований по качеству, но в это слабо верю), когда после 5 секунд ожидания матчи собираются обычно мгновенно для игроков. Но это приводило бы к увеличению очереди в момент пика CCU (каждый должен выждать 5 секунд — очередь линейно бы зависела от CCU). Т.е. не могу объяснить два этих графика одновременно — можете помочь? )
3. Длина очереди выходит на плато на уровне 300 игроков — это подозрительно много для игры 7х7. Это из-за очень сложных правил или есть какие-то банальные причины (несколько версий клиентов несовместимых на одном ММ, или входят разные режимы в эти 300 человек)?
4. Правильно ли понимаю, что стоимость сбора одного матча в таком вариант на несколько порядков выше, чем в предыдущем, поэтому пришлось так распараллеливать и во время пиковых значений ослаблять правила? Т.е. во время пикового CCU у вас начинала расти очередь И увеличиваться время ожидания игроков, т.к. ваш кластер ММ не мог подобрать грубо говоря больше 1 матча в секунду?
Вы обманываете, т.к. эти ваши — это часть View.
Я не занимаюсь разработкой под Android, но в идеальном варианте ни Model, ни Presenter не имеют доступа ни то, что к View, но и к пакету android в принципе, т.е. они не знают, что работают под android'ом. И уж особенно нельзя нарушать правила разделения зависимостей между M, V и P — код в разных модулях и зависимости между ними настроены односторонне M<=P<=V, это принципиально.
MVP это про распределение обязанностей и зависимостей, в вашем случае реализация примера должна иметь следующий вид:
Пакет Model:
класс с данными ExampleModel
Пакет Presenter:
интерфейс ExampleView с методом updateResponse(String response)
класс ExamplePresenter'а с методами doRequest(String response)
Пакет View:
класс-реализация интерфейса ExampleView
ExampleView дёргает ExamplePresenter.doRequest, ExamplePresenter устанавливает в ExampleModel данные запроса, и делает запрос на сервер, когда получает ответ, то устанавливает его в ExampleModel и дёргает метод интерфейса ExampleView.updateResponse.
Также важно выделять весь View в отдельный пакет и обращаться только через интерфейсы, т.к. это позволит делать unit тесты, подменив реализации на тестовые.
150 человек добавило эту статью в избранное — кто-то мог воспринять её серьёзно. Рекомендую удалить её пока, ознакомиться с темой более внимательно и написать действительно полезную статью. В качестве хорошей реализации MVP рекомендую ознакомиться с реализацией на www.mvcsharp.org (она на c#, но смысл от этого не меняется). Плюс там есть несколько статей на эту тему. Можете консультироваться, если будут вопросы.
Нет, это уже не MVP и с ним общего ничего не имеет, кроме названий классов. Что вы будете делать, когда вам понадобится сделать версию под планшет, где, предположим, из-за особенностей UI придётся использовать совсем другие виджеты? Т.е. я ставлю вас перед фактом, что надо поддерживать два набора View с разным набором виджетов. Как вы это организуете в вашем варианте?
Недопустимо ссылаться на виджеты равно как на любую UI или Presenter специфик логику из модели, теряется весь смысл концепции MVP. В идеале части M V и P разделены на отдельные модули и имеют односторонние зависимости M <= P <= V.
это их основная прелесть, обнаружение ошибки в рантайме может дорого стоит )
@Nullableдля переменной излишне, т.к. IDE и так знает, что метод findUserByName может вернуть null. Помечать необходимо все методы, параметры методов и поля классов. Тогда, как показывает практика, NPE уходит из вашей жизни почти полностью.