Comments 37
Спасибо, ваш пост помог мне разобраться с программированием обоев на андроид. Большим спеоциалистом в данной системе не являюсь, хотя юзаю. Давно хотел научиться писать программы под андроид, свом постом вы меня вдохновили. Жаль, что решили опубликовать в воскресенье.
Сегодня понедельник ;)
А знает кто-нибудь как писать клавиатуры под андроид? А то все доступные клавитуры либо платные, либо не удобные. И есть концепция новой клавиатуры. Буду рад, если кто-нибудь напишет статью/даст ссылку на материал по теме.
Для реализации клавиатуры необходимо разработать собственный android.inputmethodservice.InputMethodService, подробнее здесь.
Есть пример SoftKeyboard.
Есть пример SoftKeyboard.
А что за концепция?
Хочется клавиатуру на которую можно не смотреть. Т. е. сделать алгоритм, который будет подстраиваться под пользователя. В итоге должна получиться клавиатура, с помощью которою можно набирать текст очень быстро (алгоритм будет исправлять ошибки, e.t.c.). Я понимаю, что написать нормальную клавиаутуру (которой я сам захочу пользоваться) у меня шансов почти нет, но если есть время, то почему бы не попробовать?
doDraw©;
Это так было задумано? :)
Раньше сложно было найти скриншот с андроидофона без птиц, теперь эту нишу заняла Cut the rope )
Хм, интересно. Но разве while(run_) не будет жрать батарею как мама не горюй?
Я конечно не очень в курсе тонкостей девелопмента под Андройд, но есть ощущение, что система может кидать некоторые нотифаи, на основе которых прога уже может выполнять некоторую функцию. Обычно в мобильных разработках какой-нибудь бесконечный цикл очень не рекоммендуется ввиду неограниченного питания.
P.S.
Сам недавно вступил на тропу Android и тоже имею Optimus One. После WinMobile просто сказка.
Я конечно не очень в курсе тонкостей девелопмента под Андройд, но есть ощущение, что система может кидать некоторые нотифаи, на основе которых прога уже может выполнять некоторую функцию. Обычно в мобильных разработках какой-нибудь бесконечный цикл очень не рекоммендуется ввиду неограниченного питания.
P.S.
Сам недавно вступил на тропу Android и тоже имею Optimus One. После WinMobile просто сказка.
Мой любимый паттерн для подобных сервисов: ловить нотифаи на SCREEN_ON, SCREEN_OFF и TIME_TICK (тикает раз в минуту, что удобно для часов без секундной стрелки). На отключение экрана останавливаем жизнедеятельность, на включение, возобновляем.
В данном случае, сон будет происходить в блокировке, так что тоже допустимо и не должно особо кушать батарею.
В данном случае, сон будет происходить в блокировке, так что тоже допустимо и не должно особо кушать батарею.
Вот что-то такое я и имел ввиду.
Уже без меня ответили, я не успел. :) Спасибо! А обновляются часы, как это видно из кода, чаще, чтобы раз в секунду мигало двоеточие. Пробовал, оптимизировать и перерисовывать реже, но от этого возникают проблемы с отрисовкой при смене экранов, так что отказался от этой идеи.
Аналогично поступил в разрабатываемом виджете, только вместо TIME_TICK использую AlarmManaget с setRepeating. А так же через костыли (почему нет в Андроиде функции проверки видимости виджета как у обоев?!) проверяю видимость лаунчера и в зависимости от этого меняю интервал обновления.
AlarmManager то есть.
Думаю, отсутствие нормальной возможности проверки видимости виджета связано с тем, что:
а) виджет может обновляться не мгновенно. Например вытаскивать данные по сети, и как результат, лучше обновиться заранее, а не изменять данные прямо на глазах у пользователя
б) у различных лончеров может быть разное поведение и там могут быть превьюшки и прочие моменты с анимацией и движухой. Тут тоже лучше обновиться когда пришло время, а не когда видно.
в) в том же SDK не очень рекомендуют частое обновление виджетов
TIME_TICK лучше тем, что тикает строго в начале минуты, а AlarmManager позволяет более гибко настроить время (заодно указать что тикать только при активности). В общем, смотреть по задаче, оба варианта имеют право на жизнь.
а) виджет может обновляться не мгновенно. Например вытаскивать данные по сети, и как результат, лучше обновиться заранее, а не изменять данные прямо на глазах у пользователя
б) у различных лончеров может быть разное поведение и там могут быть превьюшки и прочие моменты с анимацией и движухой. Тут тоже лучше обновиться когда пришло время, а не когда видно.
в) в том же SDK не очень рекомендуют частое обновление виджетов
TIME_TICK лучше тем, что тикает строго в начале минуты, а AlarmManager позволяет более гибко настроить время (заодно указать что тикать только при активности). В общем, смотреть по задаче, оба варианта имеют право на жизнь.
Да, факторов которые мешают создать эту функцию много, но опять же можно было бы сказать, что в лаунчер нужна обязательная функция или переменная, которая отображает состояние его, видимы ли виджеты или нет.
Или хотя бы функцию которая говорит, лаунчер ли сейчас активен, или другое приложение.
Некоторые виджеты да, обновляются когда приходят данные и т.п. но те же часы обновляются строго по времени и зачем их обновлять допустим каждую минуту, когда этот виджет не видим и допустим запущена прога чтения новостей или фильм?
Поэтому и нкжна такая функция, что бы отключать обновление временно.
Или хотя бы функцию которая говорит, лаунчер ли сейчас активен, или другое приложение.
Некоторые виджеты да, обновляются когда приходят данные и т.п. но те же часы обновляются строго по времени и зачем их обновлять допустим каждую минуту, когда этот виджет не видим и допустим запущена прога чтения новостей или фильм?
Поэтому и нкжна такая функция, что бы отключать обновление временно.
Все нормально благодаря строчке
wait()
, она приостанавливает поток до тех пор, пока мы не пошлем то самое событие на основе одного из системных (когда обои снова станут видимыми).что-то я не пойму тему с SurfaceHolder.
чтоли можно рисовать «часы» поверх других виджетов?
чтоли можно рисовать «часы» поверх других виджетов?
Нет, это как раз «канва» рабочего стола, можно рисовать под виджетами.
Спасибо за отрисовку в отдельном потоке. Похоже, что многие другие обои рисуют в основном потоке (gui), поэтому перелистывание столов, открытие списка приложений и даже отображение меню проиходит сильно медленнее и более дёрганно (я бы сказал, что фпс обоев ограничивает фпс отрисовки всего активити лончера).
Но, несмотря на всё это, процесс часов всё равно кушает по 20% цпу (Desire, 1ггц) при настройке режима цп = performance (поддержка частоты 1 ггц, чтобы проценты были верны относительно этой частоты), режим ondemand снижает частоту, отчего проценты растут до 35. Имхо, многовато для часиков, батарейку жалко.
Я пока не понял, кто/что отвечает за передвижение обоев при перелистывании рабочих столов (требуется перерисовка), но всё же считаю, что часы достаточно рисовать один или два раза в секунду.
Но, несмотря на всё это, процесс часов всё равно кушает по 20% цпу (Desire, 1ггц) при настройке режима цп = performance (поддержка частоты 1 ггц, чтобы проценты были верны относительно этой частоты), режим ondemand снижает частоту, отчего проценты растут до 35. Имхо, многовато для часиков, батарейку жалко.
Я пока не понял, кто/что отвечает за передвижение обоев при перелистывании рабочих столов (требуется перерисовка), но всё же считаю, что часы достаточно рисовать один или два раза в секунду.
В данном примере мы хреначим отрисовку в каждом цикле while, нагружая проц да. Это конечно ересь, я лично ограничиваю 25-30 кадрами в секунду, хотя можно и меньше, зависит от характера анимации.
Единственный обнаруженный подводный камень — то что в конструкторе surfaceHolder может еще не содержать размеров канвы!
Sign up to leave a comment.
Пишем живые обои с часами