Привет, Хабр! Хочу рассказать вам о библиотеке Chronos для Android (API level >= 9), цель которой – облегчить написание долгих операций, например, сетевых запросов, или обращений к БД.

Какую проблему решаем?

Не секрет, что для Android задача выполнения асинхронных операций всегда была одной из самых частовстречающихся. Действительно, крайне мало приложений работают исключительно в оффлайн, и где можно обойтись без сетевого взаимодействия. И уж совсем крохотная их часть обходится без обращения к постоянной памяти устройства, будь то база данных, Preferences или обычный файл. Однако, на протяжении истории развития системы нам так и не было предложено ни одного достаточно удобного решения “из коробки”.

Много боли изливается на страницы Сети по поводу неудачных собеседований. Кому-то не понравились вопросы интервьюеров, другого обидели насмешками, иных посудили по страничке вконтакте. Интервьюеры не отстают от соискателей и ругаются на то, как плохо нынче с кадрами, и какие глупые ответы дают неопытные программисты на их заковыристые технические вопросы.

К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.

За свою профессиональную карьеру мне довелось побывать по обе стороны баррикад, хотя, пожалуй, проводить технические собеседования приходилось всё же немного больше, чем проходить их. Но за это время у меня накопилось некоторое количество «пунктиков», которые отпугивают меня во время технического интервью и сразу в моём сознании ставят крест на дальнейшей беседе. Об этом мне и хотелось рассказать — с позиций интервьюера и соискателя. Хочу сразу оговориться, что статья отражает мои личные субъективные впечатления и не претендует на «руководство по прохождению собеседований». С другой стороны, это не минутный всплеск ярости от неудавшегося интервью, а давно взвешенный набор тех критериев, которые, хотя и по негативному принципу, позволяют мне отсеять варианты, либо самому не отпугнуть потенциально подходящего соискателя.

А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.

Вступление

Всем привет, меня зовут Григорий, последние 5 лет занимался программированием под iOS. Сейчас решил сменить сферу деятельности и ударился в веб, но чтобы добро не пропадало, хочу поделиться с сообществом своими наработками, накопившимися за это время. Библиотеки выложены на GitHub и добавлены в CocoaPods. Инструкции по установке и использованию вы сможете найти по ссылкам на GitHub, здесь же будет краткое описание.

Минимальная поддерживаемая версия — iOS 6.0.

Три с половиной месяца назад мы совместно с Google запустили нашу первую бесплатную онлайн школу Android-разработчиков LearnDroid. И в пятницу мы выпускаем финальный тест, пройдя который вы получите сертификат от Google. Тест сможет пройти только тот, кто зарегистрировался до четверга 16 июля 23:59.

За эти 3,5 месяца мы выпустили 14 лекций, в которых лекторы из Лаборатории Касперского, Тинькофф Банка, Parallels, JetBrains, Google, e-Legion, ABBYY, Mail.Ru, OK.RU, Aviasales, LinguaLeo шаг за шагом раскрывали тайны разработки под Android. Всего в школе зарегистрировалась более 22 000 человек из России и СНГ.



Подробности о финальном тесте и сертификате под катом.

Баннеры – один из наиболее популярных видов рекламы в мобильных приложениях. Они не занимают много места, как, например, полноэкранная (interstitial) реклама. И позволяют совместить их с элементами пользовательского интерфейса приложения. Их можно добавить на разные экраны в приложении.

Прочитав данную статью, вы узнаете, как лучше вставить баннеры таким образом, чтобы они не мешали пользователю и не портили вид приложения. При этом вам не придётся изменять layout xml и вносить много изменений в код приложения. Вы можете внедрить баннеры в своё готовое приложение, добавив всего несколько строк кода. Подход, описанный в статье, универсальный, вы можете использовать его для API любых рекламных сервисов. Статья будет интересна как для новичков, так и для опытных разработчиков. Если вы — новичок в разработке, то для того, чтобы понять предмет статьи, от вас не потребуется каких-либо глубоких знаний. Достаточно понимания базовых концепций разработки под Android. А опытные разработчики могут найти в ней готовое решение, которое они могут внедрить у себя. Но инициализация рекламного сервиса, работа с конкретными рекламными API и кеширование находятся за пределами данной статьи. Для решения таких вопросов, пожалуйста, обратитесь к руководству для вашего конкретного рекламного сервиса.

CocoaPods — это очень мощный инструмент, имеющий статус must have для любого iOS Developer'а. С помощью него мы можем легко, быстро и просто подключать различные вкусные тулзы, утилиты и библиотеки, которые значительно облегчают нам жизнь при разработке приложений. Но всяким инструментом надо уметь пользоваться и CocoaPods не исключение.
Под катом информация, которая позволит начать освоение этого инструмента (основано на том, что изложено в документации и собственном опыте). И так, дорогой читатель, отложи в сторону микроскоп, хватит уже им гвозди заколачивать и продолжай читать.

Наши разработчики в Techmas часто сталкиваются с задачами создания уведомлений (push notifications). Несмотря на простоту и популярность технологии, в её реализации есть ряд особенностей, о которых и пойдёт речь в этой статье.

С появлением у меня в первом классе Dendy вопрос кем я стану отпал сам собой буквально через пару недель — программистом конечно же. Я долго и упорно шел к этому, невзирая на отсутствие информатики в школе, работал в техподдержке известного всем регистратора параллельно с учебой в институте, но полноценная жизнь началась лишь в тот момент, когда меня наконец-то взяли хоть куда-то писать код.

Очень скоро я понял, что мало быть программистом, работающим от звонка до звонка и получающим за это деньги на карточку — всё самое интересное начинается, когда решаешь сам без всяких архитекторов, тестировщиков и тимлидов что-нибудь этакое написать и заставить работать. Желательно что-нибудь веселое и захватывающее. Игру, например.

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

Все java-разработчики, рано или поздно, встречаются с пресловутой ошибкой OutOfMemoryError. 

После этой встречи мы начинаем более бережно относится к используемой памяти, экономить ее. Начиная с версии 1.2 в Java появился пакет java.lang.ref.* с классами SoftReference, WeakReference, PhantomReference. Далее я расскажу вам о том, как помогут эти классы в борьбе с OutOfMemoryError. И что более интересно, приведу реальные примеры их использования. Начнем.

Никому не нравятся креши с OutOfMemoryError

Работая над Square Register, мы рисуем подпись клиента используя битмап-кеш. Поскольку этот битмап размером с экран устройства, у нас было очень много OutOfMemory крешей во время создания его.



Мы пробовали несколько подходов ни один из которых не решил проблему:

• Использовали Bitmap.Config.ALPHA_8
• Ловили OutOfMemoryError, вызывали сборку мусора и пробовали снова (подглядели в GCUtils),
• Мы не рассматривали вариант с размещением битмапов вне кучи Java. К счастью Fresco еще не существовало,
  

Уверен, что те, кто следят за изменениями в мире Android, заметили, что Toolbar начинает играть в приложениях всё более значимую роль. Например в последней версии Gmail клиента в Toolbar вынесен почти весь функционал по работе с почтой, а в новом Google Chrome Toolbar отвечает за работу с текстом страниц.

В данной статье я постараюсь рассказать о создании динамического Toolbar, который позволит пользователю работать с контентом четырьмя различными способами в рамках одного Activity. Мы рассмотрим весь процесс разработки Toolbar-a начиная с xml файлов стилей и заканчивая анимацией иконок, а в конце статьи я оставлю ссылку на GitHub репозиторий с примером полностью рабочего приложения.

Большинство прикладных приложения под iOS таким или иным образом используют UIViewController'ы. Там где UIKit фрэймворк — там и UIViewController'ы. Их много, они повсюду, они сидят в засадах и выглядывают из-за каждого угла. Поэтому, любой программист под iOS — будь он зеленым новичком, едва ступившим на тропу программирования, либо матерым профессионалом своего дела, должны знать о UIViewController'aх все.

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

Так вот. В данном посте, я еще раз расскажу о жизненном цикле UIViewController'ов, расскажу о том, что и где стоит делать, и в каком случае. Пост ориентирован на разработчиков разных уровней, так что кто-то узнает для себя что-то новое, а кто-то найдет повод отпинать моменты, на которые стоит обратить внимание Junior'ов в команде.

Всех заинтересовавшихся, прошу

Добрый день, хаброжители,

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

1. Облегчаем поддержку iOS приложения. Часть 1 — не отрываясь от Xcode
2. Облегчаем поддержку iOS приложения. Часть 2 — локация и сеть
3. Облегчаем поддержку iOS приложения. Часть 3 — падение и логи

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

Добрый день. Я хотел бы рассказать о том, как можно облегчить поддержку iOS приложений.

1. Облегчаем поддержку iOS приложения. Часть 1 — не отрываясь от Xcode
2. Облегчаем поддержку iOS приложения. Часть 2 — локация и сеть
3. Облегчаем поддержку iOS приложения. Часть 3 — падение и логи

Всем, кто создавал iOS приложение, и оно доходило хотя бы до открытого β-тестирования, скорее всего, знакома фраза: “Я тут поигрался с приложением и вот что получилось...”. И вот после этой фразы вы могли провести несколько часов, пытаясь понять, как же «это» получилось.

Если вам знакома эта ситуация, или хочется узнать о том, как спасти себя от такого в будущем — прошу под кат.

Единственной постоянной в разработке програмного обеспечения являются баги. Давайте посмотрим правде в глаза, нам никогда не удавалось сделать все правильно с первого раза. Из-за небрежности или неправильных предположений, разработка программного обеспечения становится похожа на приготовление пирога в мотеле, кишащим тараканами, за исключением того, что в нашем случае мы сами создаем жуков. К счастью Xcode дает нам множество инструментов для того, чтобы держать насекомых в ужасе. Очевидно что для этой цели существует отладчик, который мы знаем и любим, но есть еще многое что он умеет помимо просмотра переменных и построчной отладки. Это туториал для начинающих и продвинутых iOS разработчиков, где вы сможете получить практический опыт работы с некоторыми менее известными но черезвычайно полезными методами отладки, таких как:
— как избавится от NSLog в пользу логирования брейкпоинтов;
— как избавится от списка TODO в пользу генерации предупреждений компилятора;
— остановка на условиях с выражениями;
— динамическое изменение данных с помощью LLDB и многое другое.
Как вы можете заметить, целью для меня является быть ленивым разработчиком. К счастью LLDB позволяет сохранить мое время на мартини. Он предоставляет мне отличные инструменты для того, чтобы я не был приклеен к моему компьютеру в течении дня и ночи. Устраивайтесь поудобнее в кресле и открывайте свой любимый напиток. Время становиться ленивым!
Замечу что данный туториал подразумевает что вы уже знакомы с основами отладки в Xcode. Если вы новичек, рекомендую пройти сначала этот туториал.

Эта статья о том, как подружить языки Java и C++ в одном приложение для операционной системы Android.

На С++ написано огромное количество кода. Мне хотелось бы как-то использовать этот код в своих приложения, но почему-то у меня процесс использования вызывал некий дискомфорт. Скорей всего, это, банально, было связано с тем, что основой моей рабочей средой является Android Studio, в которой работа с нативным кодом, скажем так, не самая лучшая. Но вот мысль о том, чтобы комфортно разрабатывать приложение с нативной частью не оставляла меня никогда. Поэтому я решил попробовать скрестить всю мощь библиотеки Qt и приложение, написаное на родном для Android языке — Java.

    Относительно не так давно появилась замечательная библиотека Espresso для тестирования UI Android приложений. Её преимущества над аналогами обозревались не один раз. Если вкратце, то они заключаются в том, что это разработка Google для собственной ОС (ранее они сами использовали Robotium), а так же в лаконичности синтаксиса и скорости работы. Итак, мы решили идти в ногу со временем и использовать Espresso. Но нам мало тех плюсов, что уже есть, мы хотим BDD (http://en.wikipedia.org/wiki/Behavior-driven_development), мы хотим скриншотов и отчетов в json и html, мы хотим запускать это все на CI, в конце концов! Но обо всем по порядку. Я расскажу как подружить Cucumber (http://habrahabr.ru/post/62958/) и Espresso (http://habrahabr.ru/post/212425/) на небольшом примере. Всех, кто устал от Appium, кто хочет уйти от Robotium и тех, кому небезразлично тестирование Android, прошу под кат.

Вот захотелось мне такое сделать и я сделал.

Полноразмерная картинка (на случай если Хабр пережмёт картинку под спойлером). Подходит для печати на стандартной кружке, площадь поверхности 20 х 8.8 см, 300 dpi (ребята в магазине сувениров сказали, что это стандарт).
Шпаргалка, послужившая основой

P.S. Да, я в курсе, что у меня не вышло вместить 1300-cтраничный стандарт на одну кружку. В следующий раз точно получится, я уверен.