Привет! Зарегистрировался сам и друзьям рассказал. А что дальше? Никакого подтверждения никому не пришло. Так и должно быть и можно приходить? Или надо все же дождаться ответа?
В случае смены ориентации активити пересоздается заново. В вашем случае, если перед запуском игры устройство у пользователя было в портретной ориентации, то и активити начнет создаваться в портрете. Но, обнаружив в процессе создания ваш код, андроид пересоздаст активити уже в альбомном виде. Указание в манифесте позволяет сразу задать нужную ориентацию.
Вот здесь описана проблема, к которой может привести метод setRequestedOrientation() в onCreate().
Ладно, с хорошим тоном все ясно, а что насчет обилия «магических констант» в коде? Что все эти цифры означают? Вы сказали, что целью было показать, как написать свой генератор и даже выложили весь код, по которому якобы можно понять, как программа работает. Но, глядя в ваш код, все, что я понимаю, это что без чтения дополнительного материала (в том числе и по ссылке в тексте) ничего понять вообще нельзя.
Главный плюс: появился маркет и сторонние приложения (включая приложение, которое рисует на экране хардварные кнопки — домой, меню, назад и т.д.).
Из минусов:
— WinImage превратил 512 МБ sd-карту в 40 МБ. Хорошо не взял 2 ГБ из телефона. Пока не получилось восстановить емкость.
— Некоторые приложения не видят встроенной памяти (5 гигов), а могут работать только в SD-картой.
— Не могу устанавливать приложения из apk файлов, только через маркет
— Некоторые игрушки изменяют пропорции изображения и сужаются по горизонтали — в результате слева и справа черные полосы. Хотя и работают при этом без других глюков и падений.
Итого, с установкой дополнительных программ, типа Adobe Reader, Laputa, FBReader+ColorDict (чтобы читать книги на английском) функциональность Nook Color как читалки значительно улучшилась.
Я в Adobe Reader установил настройку View Mode -> Continuous Scroll. И больше не надо листать отдельно по страницам — я просто сдвигаю экран вниз. При этом никаких задержек не наблюдаю.
Прочитал на такой штуке уже несколько книжек в pdf, как нормальные eBooks, так и запакованные сканы. При этом не испытал проблем с дозагрузкой страниц, так как читаю я все равно медленнее, чем он отрисовывает.
Я знаю, что такое юнит-тесты, я знаю, какую пользу они приносят. Но я не пишу юнит-тесты, потому что хотелки заказчика появляются как грибы после дождя — в случайных местах и не всегда понятно, какой именно гриб перед тобой. Несмотря на всю формальность процесса (SRS, CR, итерации и т.д.) получается примерно следующее:
хотим, чтобы шрифт здесь был 10 — описано в SRS — сделано — а нет, у нас названия сюда не влезают, хотим 11 — заведен CR — сделано — прошел месяц — не, ваще не хотим здесь ничего, пусть это появляется там и настраивается через визард — заведен CR, но что именно нужно настраивать через визард еще не знаем, нет спеки — делаем что-то — оно им (не)нравится, и так несколько раз — нашли, что нужно — под уже готовый(!) функционал делается запись в SRS. На последних этапах этого «процесса» уже даже CRы не заводятся, зачем, все равно всем понятно, что никому ничего не понятно.
Это уже смело можно назвать BDD — Bug Driven Development =) Заказчик выдвигает абстрактные требования без какой-либо конкретики — разработчик делает что-то, процесс повторяется через заведение багов в JIRA.
В этом процессе на поддержку уже существующих юнит-тестов уходит 80% времени. Просто чтобы они удовлетворяли актуальному видению заказчика. Все это приводит к весьма плачевным результатам — старые тесты тупо удаляются, а новые не пишутся. В последствии что-то менять — смерти подобно.
Речь не о том, как моделировать передачу управления. Действительно, разницы между объектами-наблюдателями и вызовом метода из делегата .NET с точки зрения факта передачи нет никакой. На самом деле, делегат — это тоже объект. Названия выбраны скорее из идеологических соображений =)
Разница же в области видимости и связанности объектов. Посмотрите картинку про Неизвестность и SomeClass. В этом и отличие — событиями мы оповещаем неизвестных подписчиков, а вот через интерфейсные методы позволяем этим же незнакомцам управлять собой. Повторюсь, как эта идея реализована технически, разницы нет.
Наверное, все-таки название «объектный способ» выбрано неудачно и только запутывает. Может, кто подскажет более подходящее?
Отчего же не поверю? Я был уверен, что есть и другие способы =)
Спасибо за направление дальнейшего поиска. Если еще поможете конкретными авторами и их работами, то буду очень признателен.
Да, кинги Фаулера тоже будут, несомненно, полезны. Сейчас я как раз в процессе их изучения и не хочу рекомендовать то, что сам не прочитал. ГоФов и Буча вполне, имхо, достаточно, чтобы понять, что такое паттерны, и как их описывать на диаграммах классов.
Под статистикой я имел ввиду не модель, а контроллер, модуль, который занимается сбором и отображением статистики. Естественно, сами данные тоже должны где-то храниться, но то, как устроена модель не рассматривал специально, так как в примере хотел описать именно взаимодействие контроллера и представления.
Вот здесь описана проблема, к которой может привести метод setRequestedOrientation() в onCreate().
Ларчик-то просто открывался.
www.barnesandnoble.com/nookcolor/features/techspecs/index.asp?cds2Pid=35607
Главный плюс: появился маркет и сторонние приложения (включая приложение, которое рисует на экране хардварные кнопки — домой, меню, назад и т.д.).
Из минусов:
— WinImage превратил 512 МБ sd-карту в 40 МБ. Хорошо не взял 2 ГБ из телефона. Пока не получилось восстановить емкость.
— Некоторые приложения не видят встроенной памяти (5 гигов), а могут работать только в SD-картой.
— Не могу устанавливать приложения из apk файлов, только через маркет
— Некоторые игрушки изменяют пропорции изображения и сужаются по горизонтали — в результате слева и справа черные полосы. Хотя и работают при этом без других глюков и падений.
Итого, с установкой дополнительных программ, типа Adobe Reader, Laputa, FBReader+ColorDict (чтобы читать книги на английском) функциональность Nook Color как читалки значительно улучшилась.
хотим, чтобы шрифт здесь был 10 — описано в SRS — сделано — а нет, у нас названия сюда не влезают, хотим 11 — заведен CR — сделано — прошел месяц — не, ваще не хотим здесь ничего, пусть это появляется там и настраивается через визард — заведен CR, но что именно нужно настраивать через визард еще не знаем, нет спеки — делаем что-то — оно им (не)нравится, и так несколько раз — нашли, что нужно — под уже готовый(!) функционал делается запись в SRS. На последних этапах этого «процесса» уже даже CRы не заводятся, зачем, все равно всем понятно, что никому ничего не понятно.
Это уже смело можно назвать BDD — Bug Driven Development =) Заказчик выдвигает абстрактные требования без какой-либо конкретики — разработчик делает что-то, процесс повторяется через заведение багов в JIRA.
В этом процессе на поддержку уже существующих юнит-тестов уходит 80% времени. Просто чтобы они удовлетворяли актуальному видению заказчика. Все это приводит к весьма плачевным результатам — старые тесты тупо удаляются, а новые не пишутся. В последствии что-то менять — смерти подобно.
Разница же в области видимости и связанности объектов. Посмотрите картинку про Неизвестность и SomeClass. В этом и отличие — событиями мы оповещаем неизвестных подписчиков, а вот через интерфейсные методы позволяем этим же незнакомцам управлять собой. Повторюсь, как эта идея реализована технически, разницы нет.
Наверное, все-таки название «объектный способ» выбрано неудачно и только запутывает. Может, кто подскажет более подходящее?
Спасибо за направление дальнейшего поиска. Если еще поможете конкретными авторами и их работами, то буду очень признателен.
Под статистикой я имел ввиду не модель, а контроллер, модуль, который занимается сбором и отображением статистики. Естественно, сами данные тоже должны где-то храниться, но то, как устроена модель не рассматривал специально, так как в примере хотел описать именно взаимодействие контроллера и представления.