Работая с Android часто можно видеть, как весь функциональный код помещается в методы жизненного цикла activity/fragment. В общем-то такой подход имеет некоторое обоснование — «методы жизненного цикла» всего лишь хэндлеры, обрабатывающие этапы создания компонента системой и специально предназначенные для наполнения их кодом. Добавив сюда то, что каркас UI описывается через xml файлы, мы уже получаем базовое разделение логики и интерфейса. Однако из-за не совсем «изящной» структуры жизненного цикла, его зависимости от множества флагов запуска, и различной (хоть и похожей) структуры для разных компонентов, эффективно воспользоваться подобным разделением не всегда бывает возможно, что в итоге выливается в написании всего кода в onCreate().

Одна из естественных и первых задач при разработке под Андроид – организация асинхронного взаимодействия. Например, обращение к серверу из некоторой активности и отображение на ней результата. Трудность состоит в том, что за время обращения к серверу поверх может быть открыта другая активность или другое приложение, исходная активность может быть безвозвратно завершена (пользователь нажал Back) и т. д. Вот получили мы результат от сервера, но активность «неактивна». Под «активна», в зависимости от обстоятельств, можно понимать, например, что находится между onStart и onStop, onResume и onPause (или, как у нас в проекте, между onPostResume и первым из onSaveInstanceState и onStop). Как понять, завершена активность окончательно (и результат нужно отдать сборщику мусора) или лишь временно неактивна (результат нужно хранить, и отобразить, как только активность станет активной)?

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

Всем привет.

Так получилось, что уже давно мучает вопрос: «Как следить за форумами по интересным тебе темам, но самое главное, как узнавать о появлении новых вопросов в момент их публикации». Конечно, можно сказать, что есть рассылки, RSS, но лично у меня получается так, что до почты я добираюсь, как правило, с мобильного во время передвижения. Вручную серфить ресурсы вообще не вариант. Вот поэтому, если бы я и мог ответить, компьютера под рукой нет. А после приезда голова уже забита совсем другим. Могу смело сформулировать свою проблему. Необходим канал, сообщающий и самое главное, привлекающий мое внимание в момент публикации нового вопроса.

До недавнего времени таким я рассматривал какой-нибудь IM, для работы Telegram я не пользуюсь, а с остальными все что-то не совсем так.

Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.

Привет, Хабр! Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI. Добро пожаловать!

Признак плохого дизайна №1:
Наличие объекта-«бога» с именем, содержащим «Manager», «Processor» или «API»

Ведущий iOS-разработчик Redmadrobot Егор BepTep Тафланиди — о том, как добиться стройного архитектурного дизайна мобильного приложения, используя классические шаблоны проектирования и логическое разделение исходного кода на модули.

К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».

Автор: Антон Валюх, Senior Mobile Developer.

В этой статье поговорим о теории и практике использования очень удобного шаблона проектирования MVVM (Model-View-ViewModel) при разработке Android-приложений.

MVP — Model-View-Presenter

Для начала — немного теории. Всё началось с того, что многие думали, как приспособить шаблон MVC (Model-View-Controller) для написания приложений с интерфейсом пользователя. И в 2006 г. в работе “GUI Architectures” Мартин Фаулер подробно рассмотрел шаблон, который впоследствии получил название “MVP” (“Model-View-Presenter”).

Итак, MVP — шаблон проектирования, производный от MVC, разработанный в основном для построения пользовательского интерфейса. MVP используется для облегчения автоматического модульного тестирования и улучшения разделения логики и отображения.

В этом шаблоне есть три элемента:

1. View.
2. Presenter.
3. Model (модель).

В новом дайджесте мы сравниваем Swift и Rust, оцениваем гайдлайны Apple, следим Xamarin.Forms, обновляем приложения в Google Play к Новому году, выводим в топ и смотрим за покупками.

Привет, Хабр! Мы открываем набор на вторую стажировку для разработчиков в Redmadrobot. Старт — в середине января.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Предыстория
В далёком 2005 году, когда я был ещё мелким ребёнком, я впервые увидел такую вещь как «Социальная карта москвича» Смотря на то как пенсионеры прикладывают её при проходе через турникеты наземного транспорта и метрополитена, я стал задумываться над тем, как же работает вся эта система. Но в детстве у меня не было возможности этим заняться. Позже, когда я уже сам начал зарабатывать деньги, я решил всерьёз приступить к изучению системы оплаты проезда в общественном транспорте.

RFID
Конечно же я начал с поиска в гугле и без особых усилий нашёл название данной — RFID (Radio Frequency IDentification) или в переводе на русский Радиочастотная Идентификация. Прочитав статью на википедии, я понял что метки (карты) делятся на 3 диапазона работы, Метки диапазона LF (125—134 кГц), Метки диапазона HF (13,56 МГц), Метки диапазона UHF (860—960 МГц). В общественном транспорте используются метки второго диапазона — HF.

Сегодня поговорим о том, как писать скрипты для Unity Editor. Статья рассчитана на тех, кто уже знаком с Unity3D, что-то успел сделать, но еще не решился попробовать писать скрипты для эдитора.

Если коротко — то в режиме эдитора скриптами можно сделать абсолютно всё тоже самое, что и в режиме игры.

Начнем с простого. Допустим, мы хотим в режиме эдитора создать 10 кубиков и расположить их в линию. Для начала давайте упростим задачу и забудем про эдитор, давайте сделаем так, чтобы эти кубики создавались при старте приложения.

Это первая наша статья на Хабре (и, надеюсь, не последняя) и хочется максимально честно и открыто рассказать про наш опыт запуска бизнеса в Питере по разработке мобильных приложений «с нуля», какие ошибки мы совершали, какие продолжаем совершать (ну куда же без этого) и про то, как мы пытаемся построить что-то действительно масштабное и «изменить этот мир» — а именно наш проект мобильного товарного агрегатора tapki (название смешное конечно, родилось как производное от английского слова «tap»). Оглядываясь на статью, после ее написания, вижу, что получилось не мало текста (около 18-ти страниц в word’е), но надеюсь, что сказанное будет полезно. Коллеги советовали разбить документ на части, но как мне кажется, цельное повествование, затрагивающее период чуть больше года, позволит дать более полную картину развития компании. В статье читатель найдет экономику (управленческий баланс), который «тянется» с самого начала, с разбивкой по статьям затрат. Мы ничего не добавляли-убавляли и все цифры приводим «как есть».

Я расскажу про запуск бизнеса с самого начала: поиск помещений, поиск инвестиций, про основную (изначальную) идею бизнеса и как она менялась в течении года, про удачи и неудачи. Поскольку мы зарегистрировали юр.лицо в июне 2013 года (а точнее 29 мая), нам, можно считать, исполняется 1 год «с хвостиком» и какие-то нюансы уже не вспомнить, но основные вехи с фотографиями — сохранились. Важно — если где-то в тексте я делаю для себя (и читателей) вывод или даю совет (прямо или косвенно) — прошу расценивать его исключительно как мое личное мнение, которое с вероятностью 50% может быть в корне не верным. И еще — некоторые моменты я не могу вспомнить в деталях, поэтому могут встречаться небольшие неточности в части объяснения тех или иных цифр — это не попытка утаить информацию, а просто элементарная забывчивость, т.к. дневник я не вел (к сожалению — исправляюсь) и пишу по памяти.