Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
В дополнение к комментариям к первой части ещё скажу, что мне GameCanvas никогда особо не нравился по разным причинам, ибо вроде как толку особого нет в нём, а сам подпакет lcdui.game какой-то тяжёлый. Конкретно игрушек я много не писал, но точно могу сказать, что многие игроделы предпочитают свои реализации лееров, спрайтов итд по той же причине.
Ещё мелкая придирка — технология называется Java ME, а не J2ME очень давно уже)
Ещё мелкая придирка — технология называется Java ME, а не J2ME очень давно уже)
Да, знаю. Просто Java 2 Micro Edition постоянно на языке вертится. Не знаю, почему. :)
Не, я всегда пользуюсь javax.microedition.lcdui.game. Декомпилируйте исходники игры от Ubisoft или Gameloft и вы цдивитесь — они используют именно этот пакет. Скажем наше громкое «НЕТ!» велосипедостроению. :)
* удивитесь
Ты-то сам их декомпилировал? Или ты настолько уверен в превосходстве GameCanvas, что даже не сомневаешься в том, что его используют крупные компании? Когда-то давно я этим вопросом интересовался. Декомпилировал 5 или 6 самых качественных и высокотехнологичных Java-игр которых знал, и там таки использовался обычный Canvas.
Для чего сделали GameCanvas вообще непонятно. Несколько куцых методов с фиговой реализацией, которые в серьезной игрушке ничего толком сделать не могут — вот и все что он предлагает.
Хотя в любом случае, это уже история.
Для чего сделали GameCanvas вообще непонятно. Несколько куцых методов с фиговой реализацией, которые в серьезной игрушке ничего толком сделать не могут — вот и все что он предлагает.
Хотя в любом случае, это уже история.
Да, смотрел. Поищу исходники — куда-то я их положил. Согласен, и обычный холст используют.
Вот именно, что «когда-то давно». Сами хоть игры писали для данной платформы? Насчет «куцых методов» и прочего — вы не правы.
Когда-то давно — да :D Году эдак в 2006-ом. Хотя даже тогда ME начинала устаревать.
Я могу привести тысячу аргументов против GameCanvas, но мне лень это делать. Просто поверь, что они есть.
Хотя в любом случае это не имеет никакого значения, т.к. платформа уже мертва, а ты (без обид) врядли пишешь (или когда-либо писал) какие-то коммерческие проекты на Java 2ME. А в качестве хобби сойдет и Canvas, и GameCanvas и вообще все что угодно :)
Я могу привести тысячу аргументов против GameCanvas, но мне лень это делать. Просто поверь, что они есть.
Хотя в любом случае это не имеет никакого значения, т.к. платформа уже мертва, а ты (без обид) врядли пишешь (или когда-либо писал) какие-то коммерческие проекты на Java 2ME. А в качестве хобби сойдет и Canvas, и GameCanvas и вообще все что угодно :)
Скажем наше громкое «НЕТ!» велосипедостроению. :)Ха ха, ну всё верно, конечно. Однако в таких вещах, типа программирования на Java ME, очень часто приходится идти на компромисс с отвращением к некоторым приёмам программирования. Вплоть до нарушения красивости ООП (не смотря на то, что кажется, будто бы Java всё же). А уж сколько велосипедов делается, чтобы работало по возможности везде, я уж вообще молчу)
> очень часто приходится идти на компромисс с отвращением к некоторым приёмам программирования. Вплоть до нарушения красивости ООП
А что мешает придерживаться строгих принципов ООП в J2ME?
> уж сколько велосипедов делается, чтобы работало по возможности везде
«Гранулированность», разделение аппаратов по поддерживаемым ими API и даже особенностей реализации стандартных API заставляет задуматься над вопросом, почему же их раньше Sun не прищучила и раздавала ялык Java2™ Micro Edition направо и налево без качественного тестирования конкретных реализаций.
А что мешает придерживаться строгих принципов ООП в J2ME?
> уж сколько велосипедов делается, чтобы работало по возможности везде
«Гранулированность», разделение аппаратов по поддерживаемым ими API и даже особенностей реализации стандартных API заставляет задуматься над вопросом, почему же их раньше Sun не прищучила и раздавала ялык Java2™ Micro Edition направо и налево без качественного тестирования конкретных реализаций.
А что мешает придерживаться строгих принципов ООП в J2ME?В основном — зачастую огромное увеличение объёма байткода, только за счёт лишних наследований, не говоря уже о «правильных» геттерах-сеттерах повсеместных. В последнее время было менее актуально, конечно, но чуть пораньше тщательно ужимать код и ресурсы было обычным делом.
Гранулированность итд после появления midp2 было значительно менее актуально всё же, но раньше это был просто адъ. Тут и сами производители виноваты были, хотя всё было только уже сверх стандартов, конечно.
> не говоря уже о «правильных» геттерах-сеттерах повсеместных.
Хотелось бы узнать, что вы подразумеваете под "«правильными» геттерами-сеттерами повсеместными"?
При следовании парадигме ООП не нужну выставлять «напоказ» внутренние сущности, в частности, — поля через методы доступа к ним. Они не должны использоваться без чётко определённого «протокола» взаимодействия с объектом. Иначе такой объект не будет отличаться от обычной структуры данных в стиле структурного программирования (где инкапсуляция данных не защищает их), от чего стремиться уйти ООП. Здесь, видимо, и кроется недостаток понимания смысла ООП большинством J2ME-разработчиков и бездумное использование геттеров-сеттеров по принципу «пусть будут, авось пригодятся».
Без понимания сути объекта, его нужности в определённом и только в определённом слое программной абстракции, он превращяется в неизвестно во что, в хранилище хлама без чёткого собственного поведения. Внешние объекты могут его буквально «сбивать с толку», посылая ему бессвязные сообщения (в терминах ООП Smalltalk), конечно, после этого увеличится объём кода такого странного объекта, чтобы обеспечить его собственную непротиворечивость и сохранение консистентного состояния.
Хотелось бы узнать, что вы подразумеваете под "«правильными» геттерами-сеттерами повсеместными"?
При следовании парадигме ООП не нужну выставлять «напоказ» внутренние сущности, в частности, — поля через методы доступа к ним. Они не должны использоваться без чётко определённого «протокола» взаимодействия с объектом. Иначе такой объект не будет отличаться от обычной структуры данных в стиле структурного программирования (где инкапсуляция данных не защищает их), от чего стремиться уйти ООП. Здесь, видимо, и кроется недостаток понимания смысла ООП большинством J2ME-разработчиков и бездумное использование геттеров-сеттеров по принципу «пусть будут, авось пригодятся».
Без понимания сути объекта, его нужности в определённом и только в определённом слое программной абстракции, он превращяется в неизвестно во что, в хранилище хлама без чёткого собственного поведения. Внешние объекты могут его буквально «сбивать с толку», посылая ему бессвязные сообщения (в терминах ООП Smalltalk), конечно, после этого увеличится объём кода такого странного объекта, чтобы обеспечить его собственную непротиворечивость и сохранение консистентного состояния.
javax.microedition.lcdui.game иногда может быть полезным, но часто в играх используется настолько извращенная специфическая оптимизация, что лучше изобрести велосипед.
Кстати, для корректного отображения изображений в GDI тоже применяется двойная буферизация (с созданием нового DC через CreateCompatibleDC и CreateCompatibleBitmap). Правда, теперь это применяется разве что в мелких игрушках типа «тетрис в 4 килобайта».
Хм. А у меня и прошлая не тормозила… можно новый Jar? обновлюсь ^_^
Было великим счастьем переключиться с j2me на android.
Для кого как. У меня есть и то, и то. Первое — как звонилка и поиграть в старые добрые игрушки, а вторая — просто для поиграть.
Я с точки зрения программиста :)
Ой, не скажи. Когда только начал писать для Андрюши, то столкнулся с множеством проблем, одной из которых была ничем иным, как непонимание того, зачем там наворотили столько классов. У МЕ с этим проблем нет. Следовательно, по «входному порогу» выигрывает как раз-таки МЕ.
Богатый инструментарий не есть проблема. Поначалу тяжело, но там почти всё, что имеется, оправдано.
Опять же, проблема относительна. Некоторые SE/EE программисты гневаются по поводу того, что всё в андроиде порезано, а то, что осталось — извращено.
ME — это говно мамонта. Как ZX-SPECTRUM или ATARI 65XE/XL. Вспомнить приятно, но эксель на него никто не написал пока.
Опять же, проблема относительна. Некоторые SE/EE программисты гневаются по поводу того, что всё в андроиде порезано, а то, что осталось — извращено.
ME — это говно мамонта. Как ZX-SPECTRUM или ATARI 65XE/XL. Вспомнить приятно, но эксель на него никто не написал пока.
Издеваешься? На Java ME давно Excel есть, правда название приложения не помню, но оно стояло когда-то и я им пользовался: создавало, сохраняло, открывало… Так что поищи…
Было великим счастьем переключиться с j2me на android.Ой, ну не знаю… android тоже та ещё «конфетка».
Ну, там главное использовать то, что наворотили разработчики и изобретать как можно меньше собственных велосипедов.
А что тебе не нравится в андроиде больше всего?
А что тебе не нравится в андроиде больше всего?
Заранее приношу извинение, что не в тему. Стою перед выбором изучать J2ME или нет. Может подскажете, насколько java me сегодня актуальна?
В тему. Смотря для чего. Вообще — уже устаревшая достаточно платформа. Коммерция — однозначно нет. Хобби — можно попробовать. Но, если говорить об актуальности и популярности платформы, то они стремится к нулю.
Лучше сразу Java SE, параллельно с вниканием в Android.
Ибо ME — это изуродованная и кастрированная Java, которая может только осложнить изучение чего-либо актуального.
Ибо ME — это изуродованная и кастрированная Java, которая может только осложнить изучение чего-либо актуального.
Хочу заняться java, а тут подвернулся толковый учебник по j2me, Моррисона. Вот и возник вопрос, хотя, сама технология, как я понял умирает
Да, умирает.
Нет, не умирает, а продолжает активно использоваться.
Oracle в скором времени может переключиться на мобильный сегмент и занять весомую нишу за счёт наработок в этой области и доведения до ума аппаратной части, которая может тянуть код Java SE, в частности, JavaFX.
Конечно, если только Ларри Эллисона это заинтересует всерьёз, как его приятеля Стива Джобса в своё время. Я думаю, что с уходом из Apple харизматичной личности, будущее видение технологий мобильных органайзеров за Oracle, как это ни странно звучит.
Oracle в скором времени может переключиться на мобильный сегмент и занять весомую нишу за счёт наработок в этой области и доведения до ума аппаратной части, которая может тянуть код Java SE, в частности, JavaFX.
Конечно, если только Ларри Эллисона это заинтересует всерьёз, как его приятеля Стива Джобса в своё время. Я думаю, что с уходом из Apple харизматичной личности, будущее видение технологий мобильных органайзеров за Oracle, как это ни странно звучит.
Ибо ME — это изуродованная и кастрированная Java, которая может только осложнить изучение чего-либо актуального.Ну всё не так совсем ведь, что уж Вы. Если понимать что такое Java и что такое профили, платформы итд итп, то всё не так страшно выглядит. Изучать Java ME явно надо (было) после обычной Java и тогда понимание только улучшается, плюс приходят скилы оптимизаций и прочих выкрутасов. Честно говоря, мне очень жаль, что Java ME померла, технология на самом деле для того времени развития устройств-её-носителей была крайне продуманной, удобной и полезной.
Человеку, который знает, что такое генерики и for-each, очень тяжело жить без генериков и for-each.
Присоединяюсь. МЕ стоит поучить хотя бы для общего развития.
«В рейтинге мобильных систем лидирует Apple iOS — 52.10%, на втором месте Java ME — 21.27%, на третьем Android — 16.29%, на четвёртом Symbian — 5.76%, на пятом BlackBerry — 3.51%. Рейтинг Net Applications построен на основе анализа статистики 160 миллионов посещений примерно 40 тысяч web-сайтов на которых установлены счетчики HitsLink Analytics и SharePost.»
Из новости: www.opennet.ru/opennews/art.shtml?num=32745
Из новости: www.opennet.ru/opennews/art.shtml?num=32745
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Двойная буферизация или Назад в прошлое. Часть вторая