Суть фабрики или фабричного метода в том, что класс возвращаемого объекта зависит от фактического класса объекта фабрики. А тут обычный кейс внутри. Это уж сервис локатор тогда какой-то и то я не уверен.
Кнопка же всегда там, как я понял? Зачем ее динамически создавать? В любом случае всегда можно просто убрать ее (gone). ИМХО динамическое создание вьюшек не очень хорошо.
И зачем в button.xml корневой LinearLayout? В нем же одна кнопка, почему нельзя просто кнопку добавлять? Ну в крайнем случае использовать?
Я так и не понял, почему они не сделали как в С#, в котором нет type erasure. Я вроде как бы верю, что там были какие-то проблемы с обратной совместимостью, но вот почему там нужна была эта совместимость сама по себе? Почему нельзя было просто дженерики рассматривать как самостоятельный поднабор типов?
Ну так все тоже самое работает и в случае специального вью. Код при этом совершенно не нужно в активити деражть.
А уж если заботиться о производительности, то фрагменты явно не лучший выбор. Вся иерархия вьюшек будет постоянно туда сюда некотролируемо кешироваться.
Все-таки «отрезок» это не «прямая». Как я понял, для вашего алгоритма надо предварительно выбрать подходящие отрезки, что бы пересечение гарантировано было внутри них. И весь смысл упрощений теряется.
Я к тому, что искать пересечение прямых (как в заголовке) это одно, а пересечение отрезков (как в статье) это другое немного.
А были\есть ли проблемы с детектированием попадания? Я так понял, что в качестве «пушки» испольжуются ИК-диоды. И, видимо, какие-то ИК-приемники.
У ребенка есть почти такие же, только побольше и из китая. Проблема «паразитными» попаданиями (чем дальше от танка тем больше конус попадания) просто убивает весь интерес к игре. А если рядом есть какие-нибудь «стены», то отражение вообще не дает играть.
Были ли у вас подобные проблемы и как вы их решили?
В очередной раз разбежался почитать про то, как использовать UML в проектировании… Со связными примерами хотя бы… А оказалось как обычно, намешано пару общеизвесных тезисов :(
Но разве не проще на велосепеде сдлать переключатели?
И, ИМХО, немешалобы обратную связь добавить. Какой-нибудь вибромоторчик в перчатку, что бы было понятно, что жест сработал.
Еще и обратная связь будет. Типа по положению переключателя видно, что «забыл» поворотник. А еще можно добавить контроль ный диодик, что сигнал вообще работает.
А так не понятно, ты рукой дрыгнул, а сработало оно там или нет, не ясно.
Ещё раз повторю: по ссылке черным по белому написано начинаться с глагола, ваш глагол is стоит не в начале.
Виноват. Почему-то я пробовал разные имена, и почему-то на момент написания прошлого коммента в голове засело isClickLocked.
Вы правы, в статье другое название. В любом случе это уже не важно.
Будем считать, что вы меня убедили.
Под обратной связью я имел ввиду либо другие подходы, но в рамках Java и без библиотек. Например, вариант с наследником OnClickListener мне в голову не пришел. Но он хорош!
Дело не в том, что вы посмели критиковать. Равно как и я имею право не соглашаться с чем-то.
Про дартаньяна и вокруг это вы придумали потому что вашу критику пришлось отстаивать а не сразу вам врот посмотрели?
Ну бывает. Ладно. В любом случае, позиции понятны. Расходимся :)
ЗЫЖ Я действительно согласен, что lockClick лучше.
А где фабричный метод то?.
Суть фабрики или фабричного метода в том, что класс возвращаемого объекта зависит от фактического класса объекта фабрики. А тут обычный кейс внутри. Это уж сервис локатор тогда какой-то и то я не уверен.
И зачем в button.xml корневой LinearLayout? В нем же одна кнопка, почему нельзя просто кнопку добавлять? Ну в крайнем случае использовать?
А как они сейчас поживают, кто-нибудь знает?
goessner.net/articles/JsonPath
Have you tried something similar? It looks like a user has to make to many things, in your case, to give you information about needed fields.
Я так и не понял, почему они не сделали как в С#, в котором нет type erasure. Я вроде как бы верю, что там были какие-то проблемы с обратной совместимостью, но вот почему там нужна была эта совместимость сама по себе? Почему нельзя было просто дженерики рассматривать как самостоятельный поднабор типов?
А уж если заботиться о производительности, то фрагменты явно не лучший выбор. Вся иерархия вьюшек будет постоянно туда сюда некотролируемо кешироваться.
Чем не угодил обычный setEmptyView()?
Я правильноп онимаю, что для этого нужен root?
Ну вы серьезно!? До этой фразы я правда надеялся про IPC почитать :(
Я к тому, что искать пересечение прямых (как в заголовке) это одно, а пересечение отрезков (как в статье) это другое немного.
Я пробовал бумажную трубку, но видимо она тоже сильно отражает.
А были\есть ли проблемы с детектированием попадания? Я так понял, что в качестве «пушки» испольжуются ИК-диоды. И, видимо, какие-то ИК-приемники.
У ребенка есть почти такие же, только побольше и из китая. Проблема «паразитными» попаданиями (чем дальше от танка тем больше конус попадания) просто убивает весь интерес к игре. А если рядом есть какие-нибудь «стены», то отражение вообще не дает играть.
Были ли у вас подобные проблемы и как вы их решили?
Но разве не проще на велосепеде сдлать переключатели?
И, ИМХО, немешалобы обратную связь добавить. Какой-нибудь вибромоторчик в перчатку, что бы было понятно, что жест сработал.
А так не понятно, ты рукой дрыгнул, а сработало оно там или нет, не ясно.
Виноват. Почему-то я пробовал разные имена, и почему-то на момент написания прошлого коммента в голове засело isClickLocked.
Вы правы, в статье другое название. В любом случе это уже не важно.
Будем считать, что вы меня убедили.
Под обратной связью я имел ввиду либо другие подходы, но в рамках Java и без библиотек. Например, вариант с наследником OnClickListener мне в голову не пришел. Но он хорош!
Дело не в том, что вы посмели критиковать. Равно как и я имею право не соглашаться с чем-то.
Про дартаньяна и вокруг это вы придумали потому что вашу критику пришлось отстаивать а не сразу вам врот посмотрели?
Ну бывает. Ладно. В любом случае, позиции понятны. Расходимся :)
ЗЫЖ Я действительно согласен, что lockClick лучше.