Здесь уже был ответ, просто я его в тот момент не заметил. IKVM делает именно это, только с явовским родным байт-кодом. Соответственно, можно сделать аналог, принимающий на вход байт-код Dalvik.
Есть достаточно профанский вопрос… Разве нельзя изменить реализацию, например, Dalvik'а таким образом, чтобы примитивные явовские типы стали value-типами, а коллекции стали нормальными, а не кастуемыми? На крайний случай, можно заменить цепь сборки Андроид-приложений и дополнить байт-код, старые приложения конечно придется пересобрать для поддержки новых фич и иметь по 2 версии APK, но ведь тоже вариант.
Не факт что находит смысл, скорее работает на более глубоком уровне, поближе к системе удовольствий.
Возможно даже и о жизни не мечтает, просто потребляет картинку.
Скорее всего, возможности приблизиться не имеет. Ни при каком старании.
Однако, это тем не менее не значит, что она делает, то, что нужно делать. Даже «красивая жизнь», видимая ей в сериалах, не является тем, что нужно делать.
Общественная установка говорит о том, что потреблять — это нормально. Про созидание же — ничего. Конечно, многие все же созидают — их к этому тянет. Но есть у меня подозрение, что если бы нормальной общественной установкой было именно созидание, то и остальные бы вполне себе могли заниматься конструктивной деятельностью. Хотя бы, как минимум, спортом вместо сериалов.
Нет, не сводить, а смотреть в сторону. Метки — чтобы было на что прицеливаться, когда поворачиваешь глаза. Просто так пытаться повернуть глаза до упора сложнее, чем смотреть на что-либо.
Можно сделать в принципе небольшую программу для этого. При перескоке глаз с одной пары шариков на другую глаза могут сбиться, если же те же самые шарики будут сдвигаться-раздвигаться, будет попроще.
Вот кстати фраза, которая мне лучше всего прочистила мозг и поставила мысли на место. Не в юнит-тестах соль, а в требованиях. Вот их точно нужно для каждого момента формулировать. Не обязательно в коде тестов, хотя бы просто на бумаге нужно иметь список формальных требований. Проверять соответствование требованиям можно по-разному, главное — они сами, не писать код с бухты-барахты, а определиться с условиями, вариантами, случаями и граничными состояниями его работы и под это уже писать.
Хочу поделиться кое-чем, что мне удалось вычитать-надергать-проверить при разбирательстве, почему на андроиде ICQ-клиенты, не использующие C2DM либо какой-то свой протокол (чаще всего с поллингом, причем только при включенном экране), очень активно съедают батарейку. Пришел к такому выводу:
По всей видимости, блокирующее чтение из сокета создает неявный wakelock, т.е. процессор устройства не уходит в сон, но при этом Timer'ы и Handler'ы, использующиеся в приложении, останавливаются и не срабатывают. Не факт конечно, что это происходит на всех устройствах, но попробовать использовать неблокирующее чтение, пробуждающееся периодически при помощи AlarmManagera, думаю, стоит.
У вас клиент, открывающий соединение и поддерживающий показали равные результаты, по-видимому, на разных устройствах это реализовано по-разному. Либо, возможно, где-то в вашем клиенте либо в целом в процессе тестирования закрался wakelock, хотя полагаю, что вы это проверили.
Второй момент, к C2DM и андроиду в целом не относящийся, касается жестких фильтров соединений у сотовых операторов. В ходе небольшого опыта установил, что в среднем Мегафон в моем городе разрывает TCP-сессию без уведомления обеих ее сторон (последующие попытки передать что-либо по этому соединению также не приводят ни к каким ошибкам, приходится ждать таймаута), если более полутора минут не было передачи данных в обоих направлениях, т.е. просто слать на сервер сообщения не катит, нужно получать ответ. Пинги, соответственно, тоже бесполезны, т.к. проверяется состояние каждого отдельного соединения. Есть подозрение, что это одна из причин, почему C2DM столь ненадежно работает — соединение постоянно убивается провайдером, при этом клиенты об этом не знают.
Подробной проверки на спектре устройств не проводил, так что на истину не претендую, так, информация к размышлению.
А я-то думал, как все эти антивирусы работают. А оказывается можно получить доступ к файлам не только своего приложения, но и любого другого. (За ненадобностью тему не копал просто).
Вообще, многообразие возможностей в Андроиде порой поражает. А в документации многие из них не то чтобы совсем не описаны, но нужно очень внимательно сопоставить написанное в одной части документации с написанным в другой, при том, что это на первый взгляд не очень-то взаимосвязанные вещи.
В любом случае, никаких новых технологий эти экраны не содержат. Никакого качественного изменения в этих дисплеях нет. Имеется только количественное.
Однако же, это количественное изменение таки приводит к качественному изменению результата восприятия, переход количественного изменения в качественное тут происходит не в дисплее, а в человеческом глазу.
Термин Retina Display был создан маркетологами для защиты простого потребителя от этой тонкости, чтобы тот мог ясно отличить экран, обладающий таким качеством, от экрана, таковым не обладающего.
В публицистике допустимо назвать Retina Display технологией, однако здесь, на сайте с более-менее научно-популярным характером содержимого, в среде специалистов различных профилей, это уже некорректно. Просто маркетинговый термин, но никакая, на самом деле, не технология.
Переводить Retina Display как «сетчаточный» нельзя хотя бы потому, что «сетчаточный», а вернее, ретинальный экран — это retinal display, дисплеи, проецирующие прямо на сетчатку.
Интересно, реально удобно похоже сделано.
Вот на новых Лексусах/Тойотах управление жесть. На LX/Cruiser еще ничего, экран сенсорный и удобно расположен, можно тыкать, большинством функций более-менее можно управлять, навигация правда под это не рассчитана и на экране для промотки карты есть экранные кнопки, а вот на RX/Harrier та же самая система, только экран не сенсорный, и для управления курсором используется джойстичек с кнопкой сбоку. На ходу с ней бороться просто опасно, только пассажира просить, если есть.
Чаще всего пищат в них вибрирующие дроссели. Побеждается легко — нужно разобрать зарядку и залить дроссель. Чем заливать — есть варианты. Заливают цапонлаком, тупо эпоксидкой, мягким клеем. Желательно, чтобы дроссель полностью пропитался.
Возможно даже и о жизни не мечтает, просто потребляет картинку.
Скорее всего, возможности приблизиться не имеет. Ни при каком старании.
Однако, это тем не менее не значит, что она делает, то, что нужно делать. Даже «красивая жизнь», видимая ей в сериалах, не является тем, что нужно делать.
Общественная установка говорит о том, что потреблять — это нормально. Про созидание же — ничего. Конечно, многие все же созидают — их к этому тянет. Но есть у меня подозрение, что если бы нормальной общественной установкой было именно созидание, то и остальные бы вполне себе могли заниматься конструктивной деятельностью. Хотя бы, как минимум, спортом вместо сериалов.
По всей видимости, блокирующее чтение из сокета создает неявный wakelock, т.е. процессор устройства не уходит в сон, но при этом Timer'ы и Handler'ы, использующиеся в приложении, останавливаются и не срабатывают. Не факт конечно, что это происходит на всех устройствах, но попробовать использовать неблокирующее чтение, пробуждающееся периодически при помощи AlarmManagera, думаю, стоит.
У вас клиент, открывающий соединение и поддерживающий показали равные результаты, по-видимому, на разных устройствах это реализовано по-разному. Либо, возможно, где-то в вашем клиенте либо в целом в процессе тестирования закрался wakelock, хотя полагаю, что вы это проверили.
Второй момент, к C2DM и андроиду в целом не относящийся, касается жестких фильтров соединений у сотовых операторов. В ходе небольшого опыта установил, что в среднем Мегафон в моем городе разрывает TCP-сессию без уведомления обеих ее сторон (последующие попытки передать что-либо по этому соединению также не приводят ни к каким ошибкам, приходится ждать таймаута), если более полутора минут не было передачи данных в обоих направлениях, т.е. просто слать на сервер сообщения не катит, нужно получать ответ. Пинги, соответственно, тоже бесполезны, т.к. проверяется состояние каждого отдельного соединения. Есть подозрение, что это одна из причин, почему C2DM столь ненадежно работает — соединение постоянно убивается провайдером, при этом клиенты об этом не знают.
Подробной проверки на спектре устройств не проводил, так что на истину не претендую, так, информация к размышлению.
Вообще, многообразие возможностей в Андроиде порой поражает. А в документации многие из них не то чтобы совсем не описаны, но нужно очень внимательно сопоставить написанное в одной части документации с написанным в другой, при том, что это на первый взгляд не очень-то взаимосвязанные вещи.
Однако же, это количественное изменение таки приводит к качественному изменению результата восприятия, переход количественного изменения в качественное тут происходит не в дисплее, а в человеческом глазу.
Термин Retina Display был создан маркетологами для защиты простого потребителя от этой тонкости, чтобы тот мог ясно отличить экран, обладающий таким качеством, от экрана, таковым не обладающего.
В публицистике допустимо назвать Retina Display технологией, однако здесь, на сайте с более-менее научно-популярным характером содержимого, в среде специалистов различных профилей, это уже некорректно. Просто маркетинговый термин, но никакая, на самом деле, не технология.
Переводить Retina Display как «сетчаточный» нельзя хотя бы потому, что «сетчаточный», а вернее, ретинальный экран — это retinal display, дисплеи, проецирующие прямо на сетчатку.
Здесь уже про снятие изображения с человека
Вот на новых Лексусах/Тойотах управление жесть. На LX/Cruiser еще ничего, экран сенсорный и удобно расположен, можно тыкать, большинством функций более-менее можно управлять, навигация правда под это не рассчитана и на экране для промотки карты есть экранные кнопки, а вот на RX/Harrier та же самая система, только экран не сенсорный, и для управления курсором используется джойстичек с кнопкой сбоку. На ходу с ней бороться просто опасно, только пассажира просить, если есть.