Предисловие

Недавно я начал свое знакомство с платформой Android. На определенном этапе необходимо было проверить, как тут обстоят дела с удаленным вызовом процедур или, проще говоря, клиент-серверным взаимодействием.

Поначалу была надежда, что платформа позволит использовать технологию EJB. После некоторых поисков в Интернете, я убедился, что это не так просто. Большинство источников рекомендовало использовать вебсервисы как альтернативу, т.к. EJB слишком тяжеловесна для Android. Для вебсервисов же рекомендовался фреймворк ksoap2-android.

Понатыкавшись на различные грабли при первоначальном изучении ksoap2, я дошел до этапа, когда необходимо было послать и получить с сервера объект своего кастомного типа. Воспользовавшись поиском нашел вот эту статью. Оттуда почерпнул, что каждый кастомный объект должен реализовать интерфейс KvmSerializable. Это же подразумевало, что мы должны реализовать методы для сериализации и десериализации объекта. Поскольку в теории предполагалось использовать больше сотни собственных объектов, идея писать реализацию KvmSerializable для каждого из них как-то не вызывала у меня энтузиазма.

Как стало известно — в новой версии Android Jelly Bean (API v16) появилась возможность изменения размера виджета, да не просто изменения, а автоматического, который теперь подстраивается под свободное место на экране.
Функция удобная и полезная, но в официальной документации про это почти ничего нету, что довольно странно.

Так как я разрабатываю несколько виджетов, то решил добавить данный функционал.

1. Мир пытается оставить тебя тупым. Начиная от банковских платежей и процентов и заканчивая чудо-диетами — из необразованных людей легче вытрясти деньги и ими проще управлять. Занимайтесь самообразованием столько, сколько можете — для того, чтобы быть богатым, независимым и счастливым.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Думается, что хабра-аудитория, проводящая большинство своего времени за экраном мониторов, найдёт полезным этот сервис, который к столетнему юбилею фирмы Carl Zeiss подготовили её специалисты.

Надо сказать, что тест не совсем привычный — смотреть на удалённую доску и называть буквы не надо. Также авторы просят отнестись с пониманием к тому, что такая проверка никак не заменяет настоящий визит к офтальмологу, но зато вполне может служить настоящей, хоть и довольно приблизительной, оценкой остроты зрения (Visual Acuity Check), его контрастности, а также способности различать цвета.

Перед тем как начать тестирование, предлагается обязательно откалибровать монитор на разрешение и цветопередачу и занять правильное за ним положение.

Сам тест находится здесь.

Сегодня проект Coursera, о котором на хабре уже неоднократно писали, наконец перешел из статуса беты в полностью рабочий. И переход этот можно назвать, мягко говоря, успешным — к уже заявленным и частично идущим 16 курсам от Stanford и Berkley и 1 курсу от Michigan добавились 12 курсов от Penn (Философия, Литература, Экономика, Медицина), 6 от Michigan (Литература, Экономика, Право) и 8 от Princeton (История, Математика, Computer Science).

Похоже, то, что обещали в прошлом году, наконец происходит на наших глазах — университетское образование всех областей становится доступно всем и каждому. Теперь любой может в свободное время изучить под руководством виднейших профессоров области узнать то, что давно собирался, но не хватало самодисциплины, знаний или просто самих материалов — принципы работы вакцин, теорию игр или особенности социальных сетей. Будущее всеобщего образования наступает, и оно прекрасно.



Ну и после такого оптимистичного вступления — собственно сами курсы. Для большинства известны продолжительность и дата начала, так что можно уже заранее спланировать время. Поехали:

Вы разрабатываете приложения и ищете мощный инструмент для их анализа? Вам нужно удобное представление их архитектуры? Вы пытались разобрать байт-код Android-программ? Всё это умеет новый виртуальный инструмент анализа приложений ApkAnalyser от Sony, который поставляется с открытым исходным кодом.

ApkAnalyser предназначен для валидации и проверки работы вашего приложения. Вы можете распаковать, установить, запустить и проверить результаты команды Logcat. C помощью ApkAnalyser вы также сможете декодировать XML, выявить потенциальные уязвимости в вашем приложении и многое другое. ApkAnalyser полностью написан на Java и потребует JRE 1.6 или выше; работает на Windows, Linux и Mac OS X.

Большая часть кода Android приложения работает в контексте компонент, таких как Activity, Service, ContentProvider или BroadcastReceiver. Рассмотрим, как в системе Android организованно взаимодействие этих компонент с потоками.

В этой статье мы поговорим о различных механизмах, посредством которых взаимодействуют части Android-приложений. Условимся называть все эти механизмы «уровнем взаимодействия» (насколько мне известно, в документации Android нет специального термина для этого).

Итак, мы уже говорили о происхождении архитектуры ОС Android и о шаблонах, реализованных в этой архитектуре. Теперь настала пора поговорить о том, из чего состоит Android-приложение.

В этой статье будут представлены основные «персонажи» архитектуры Android-приложения.

В этой статье мы поговорим об архитектурных шаблонах, используемых в Android-приложениях.

Почему важно понимание шаблонов, реализованных в рамках некой архитектуры? Потому что таким образом изучаемая нами новая архитектура укладывается в контекст нашего предыдущего опыта и позволяет нам более эффективно использовать накопленные знания и навыки.

Возможно, я плохо искал, но в документации Android нет упоминания о каких-либо шаблонах. Не смотря на это, в Android реализованы некоторые шаблоны и архитектурные стили, о которых мы сейчас и поговорим.

В этой статье мы рассмотрим архитектуру Android-приложений.

Откровенно говоря, официальную статью Google по этой теме я считаю не очень полезной. Детально отвечая на вопрос «как», она совсем не объясняет «что» и «почему». Итак, вот моя версия, и, я надеюсь, она внесёт некоторую ясность. Да, кстати, я полностью одобряю чтение статей Google, поскольку они содержат полезную информацию, повторять которую я не собираюсь.

Не так давно, мне выпала задача, написать кеш, который сам себя чистит по истечению некоторого определенного времени. Требования к нему были следующие:

1. Легковесность
2. Потокобезобасность

В общем-то и все. До написания данной задачи с java.util.concurrent дела не имел. На мысль использования этого пакета меня натолкнул один мой коллега, у которого было нечто подобное, но не соответствовало тому функционалу который был нужен. Итак, начнем:

В качестве ключа будет выступать внутренний класс, который помимо прямого назначения будет определять он является «живым» или его можно удалить с кеша, так как время его существования подошло к концу:

В данной статье мы попытаемся описать свой опыт работы с AIDL в Android IPC.
В ней содержится пример приложения с сервисом, который запущен в отдельном процессе.

Как вы разрабатываете веб-приложение на Java?
После каждого изменения, как вы его запускаете и проверяете? Сколько времени занимает редеплой приложения и рестарт контейнера?

Мне довелось видеть разные варианты: от полной пересборки WAR-файла до использования плагинов для IDE типа MyEclipse, WTP и «коннекторов» для сервлет-контерйнеров. У некоторых из них есть явные недостатки, другие вполне работают — но есть способ проще!

Запускалка

Этот способ разработки позволяет максимально просто и гибко настроить приложение с минимальным временем редеплоя. Вам надо всего лишь написать один простенький Java-класс с main-методом, который запустит сервер Jetty сразу с нужными приложениями (т.н. Embedded Mode).

После реализации пары проектов под Android, стало понятно, что, несмотря на их небольшие размеры и кажущуюся простоту, без автоматизированных сборок и тестирования не обойтись. Родилось желание получить следующие возможности:

• unit тестирование,
• интеграционное тестирование,
• тестирование интерфейса,
• тестирование этих типов тестов на различных версиях Android и конфигурациях девайсов,
• рассылка по email в случае сломанного билда;
• таже не помешает автоматическая сборка релизов.

Не так давно мне понадобилось добавить в андроид-приложение валидаторы для полей ввода (EditText), но ничего подходящего в сети не нашлось: пришлось писать свои собственные. Теперь, когда все готово, можно раздать результаты всем желающим под Apache лицензией и немного рассказать, как все устроено. Тех, кому интересно,

Доброго времени суток!

Введение

К своему стыду, я совсем недавно познакомился с элементом details, который по сути является виджетом для представления информации о чём-либо. По информации, которая есть у меня, его поддержка достаточна скудна, так как поддерживается он на данный момент лишь в Google Chrome, начиная с 12.0, а также в Android Browser, начиная с версии 4.0. Что же, давайте посмотрим, что это за зверь такой.

Долгое время занимаясь разработкой под Android, я постепенно пришел к выводу, что многих вещей мне, как разработчику, сильно не хватает. Тогда, в начале 2010-го, не хватало только C++ exceptions и RTTI. Без них любой нетривиальный C++ код просто не мог быть портирован на Android и требовал практически полного переписывания. Это было очень существенное ограничение, которое никак не давало мне покоя. К счастью, Android — это open source, поэтому, вооружившись максимой «если тебе что-то нужно, сделай это сам», я засел за работу. К моему удивлению, сделать поддержку полноценного C++ с исключениями и RTTI оказалось довольно несложно. Потребовалось всего около недели работы. Далее был сделан сайт, на который и были выложены получившиеся пакеты для Windows, Linux и Mac OS X, а также патч и инструкция по сборке.

В первой части я постарался дать понимание относительно того, как выбрать заказчика/исполнителя для проекта. Естественно, в одной статье нет возможности перечислить все, с чем приходится сталкиваться, но основы я постарался описать.

Как верно было замечено в комментариях, не описаны такие важные моменты, как взаимодействие во время проекта и оплата работ. Оплату мы вынесем в отдельный пост, а сейчас хотелось бы рассказать о том, как надо вести проект. Опять же, не являясь истиной в последней инстанции, я не говорю, что делайте именно так, а не иначе. Просто этот опыт был вынесен на основании ошибок, и в моем случае данные правила помогают жить.

Ну, от слов к делу