Приветствую, уважаемое сообщество.

В предыдущей статье мы, используя только верстку, сделали кнопку “включить/выключить”, и вот что у нас тогда получилось:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:padding="6dp"
    android:background="#dddddd" >

    <ToggleButton
       android:id="@+id/act_main_btn_telephony"
       android:layout_width="match_parent"
       android:layout_height="wrap_content"
       android:background="@drawable/button_background"
       android:drawableLeft="@drawable/icon_phone"
       android:drawableRight="@drawable/icon_on_off"
       android:gravity="left|center_vertical"
       android:textOn="Телефония"
       android:textOff="Телефония"
       android:textSize="24sp"
       android:textStyle="bold|italic"
       android:textColor="@color/text_color"
       android:onClick="onToggleButtonClick" />

</RelativeLayout>

XML-код получился довольно увесистый. В этой статье я покажу, как сделать его по-настоящему красивым. Мы сократим код вдвое, убрав все, что может затруднить сопровождение нашего приложения или вызвать недовольство тим-лида. В этой статье мы будем использовать строковые ресурсы (strings.xml), ресурсы размерностей (dimens.xml), стили и темы (styles.xml).

Приветствую, уважаемое сообщество.

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

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

Предупреждение:
Вообще говоря, информация из статьи применима только для некоторых специфических случаев. Например, когда приложение работает внутри какого-то сегмента изолированной сети. А в общем случае посредник, коим является http-сервер, всё-таки нужен. Хотя бы потому, что при описанном методе логин/пароль доступа к базе зашиты в приложении и передаются по сети.

Статья является продолжением работы, о которой писал в своём предыдущем посте. Изначально эту часть писать не хотелось (см. предупреждение), но на хабре данная тема ещё не освещена, и в целом в сети меньше информации.
Поэтому, если Вам интересно, как можно из под Android напрямую работать с MS SQL (логично предположить, что и с другими БД, но на практике я этого не делал), добро пожаловать под кат.

«… Если бы в этот момент мистер Рипли вывел нас во двор и, оборотясь к дому, сказал: «Стань, домик, к Нью-Йорку задом, а ко мне передом», и домик, подобно избушке на курьих ножках, выполнил бы эту просьбу при помощи электричества, мы бы не слишком удивились.»

Ильф и Петров. Одноэтажная Америка. 1935г.

Часть первая

Введение

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

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

Я пишу эту статью на берегу моря, под музыку композитора Брайана Крэйна, вдали от московского офиса, где ведутся работы над новыми проектами. В отпуске у меня появилось немного времени, чтобы поделиться накопленным опытом.

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

Всем привет!

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

Технотроникс — это разработчик и производитель аппаратно-программного комплекса «Ценсор-Технотроникс». Комплекс широко известен в отрасли телекоммуникаций и позволяет организовать диспетчерскую службу для охраны и мониторинга всего хозяйства оператора связи — телекоммуникационных шкафов, контейнеров, АТС, линейно-кабельных сооружений (колодцы, кабель, распределительные шкафы). Таким образом, мы уже более 8 лет разрабатываем и поставляем программное обеспечение для диспетчерского центра и специализированные контроллеры для размещения на объектах мониторинга. И кстати, система применима за рамками отрасли связи — для мониторинга ЦОД, банкоматов, имеются решения для мониторинга квартир, домов и другое.

Что касается функционала, достижений и других подробностей, то лучше посмотреть ролик о компании. Думаю, так будет и быстрее, и понятнее.



А теперь к основной теме поста — разработанному нами контроллеру КУБ-Пико/220. Вот он перед вами.



Рис. 1. Конструктив контроллера КУБ-Пико/220

Долго я прочёсывал интернет в поисках простого решения, как мне в проект добавить 1 только класс и больше не беспокоиться о проблемах геолокации.
Критерии были такие:
1) решить всё в 1 классе, как можно меньше используя внешний код.
2) у пользователя должна быть всегда под рукой 1 static переменная в которой указанно его местоположение и больше ни о чём он знать не должен.

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

Всем, кто интересуется радиоуправляемыми моделями, известна аппаратура Turnigy 9x. Это практически народная аппаратура РУ.
Доступная по цене, существует множество аксессуаров и альтернативных прошивок к ней. Например, вот так выглядит мой экземпляр:

В нем альтернативная прошивка — er9x, добавлена подсветка экрана, стики заменены на широкие, сзади добавлена откидная подставка, в батарейный отсек выведен кабель для прошивки и редактирования настроек с ПК, питание от 2S LiIon аккумулятора.
И все бы хорошо в этой аппаратуре, она ведь модульная. Можно поставить любой модуль передатчика JR стандарта. А их существует море — почти на любой кошелек и задачи. Однако, есть два варианта комплектации — с родным радиомодулем Turnigy 9x и вообще без модуля.
Родной модуль не имеет своей антенны и подключен к верхней антенне на корпусе передатчика неразъемным кабелем так, что отсоединить модуль нельзя и заменить его можно только откусив антенный кабель:

В статье описан простой алгоритм наведения пушки, когда оси вращения не пересекаются с осью ствола. Быстро найти готовый не получилось – пришлось вспоминать школьные времена. Ну а раз вспомнил – грех не поделиться с остальными. А кто-то где-то, сэкономив время, использует его на создание еще чего-то полезного…

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

В первой части разобрались с тем, зачем все это нужно и как я до этого докатился, во второй поговорили о софте. Настала пора остановиться на самом любимом хабравчанами разделе DIY — на железе. Итак, берем текстолит, хлорное железо, паяльник… Хотя нет, стоп, открываем редактор плат. Про паяльник, куда его засовывать, а куда лучше не надо другие лучше меня расскажут. А я расскажу какие платы и датчики трудятся на благо моего умного дома.

Пару лет назад, когда стоял вопрос отделки новой квартиры, возникла тривиальная, казалось бы, задача.
Дано:

• Кухня-студия (кухня совмещенная с холлом/коридором), три точки освещения.
• Необходимо управлять освещением из двух точек. У входа в квартиру и на кухне.

Варианты решения:

• Покупаем, так называемые, проходные выключатели, ставим три штуки на кухню, три в коридоре — вот оно счастье. Вот только получилось, что от коридора на кухню нужно вести 9 жил кабеля, некрасиво, спрятать некуда.
• Покупаем готовые решения по управлению одним источником с нескольких точек.
  Точных чисел не помню, но получалось что-то около 10000р за точку освещения + 1000р за каждый выключатель, итого 36000р. Жаба.
• Как это ни странно, но эту идею высказала жена, в общем-то далекая от IT: “ А помнишь, ты светофор в Яндексе делал? Может тут тоже что-то сам сообразишь?”
  В самом деле, а почему бы и нет, подумал я?

Но я не электронщик, я программист, причем контроллеры никогда не программировал, только полноценные сервера. Значит мозгом должен быть сервер. А раз ставить сервер, то управлять тремя лампочками — это из пушки по воробьям (даже, ядерным зарядом по мухам). Значит можно еще функций навешать.
Тут Остапа понесло (с), столица перемещается в Васюки. Три лампочки с выключателями превращаются в систему управления, мониторинга, видеонаблюдения и т. д.

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

Итак, вы задумали делать продукт. Не проект, а именно продукт, который через Х месяцев должен появиться в сторах и начать свое движение к звездам. Вы уверены в своих силах и знаниях, а количество новых идей, которые могут превратиться в настоящие киллер-фичи, просто зашкаливает. Самое время сказать себе “стоп!” и разобраться в том, что должно войти в комплект вашей самой первой релизной версии.

После того как вы расписали все характеристики будущего продукта, необходимо определить приоритеты в разработке. Первое желание – ранжировать по сложности реализации. Логично, тем более если ресурс ограничен – нет смысла строить “Титаник”, когда для первого преодоления Рубикона нужна просто шустрая и устойчивая лодка. Следуя заветам customer development, вы в будущем будете только наращивать функционал: главное – в архитектуре не промахнуться.

Итак, делаем шуструю лодку. Но выбор все еще непрост – даже из относительно простых деталей нужно определить тот набор, который и станет вашим release candidate. И здесь вам на помощь придет модель, которую придумал в 70-е годы прошлого века японский ученый Нориаки Кано. На “Хабре” уже был текст об использовании его модели для решения задач UX. Этот подход вполне применим и к продуктовым функциям – ведь они тоже отвечают за эмоциональные реакции потребителей. Кано предположил, что таких реакций бывает пять типов: от полной неприязни до прямо-таки восхищения. Эти типы японец изложил на одном графике, где по вертикальной оси отобразил эмоциональную реакцию пользователя (неприязнь – восхищение), а по горизонтальной – “количественное” значение характеристики (нет – много).

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

Привет, Хабр!

В рамках нашего спецпроекта с NetCat для веб-студий и агентств мы подготовили большой материал по финансовой модели студии с кучей KPI, разработали реальный образец — и предлагаем обсудить его. Это эксклюзивный материал, ранее я не публиковал нигде этого шаблона и не выступал по данной теме.

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

Вводная

Данный бизнес-план, несмотря на то, что он выглядит довольно сложно, на самом деле, является очень упрощенной моделью. Мы сделали ряд допущений и упрощений, чтобы показать в простом виде, как зависят друг от друга основные значения. «Боевые» финансовые модели реальных агентств, конечно, еще более сложны.

Надеюсь, что вы постараетесь «поиграть» со значениями – изменяя константы и показатели, которые подаются на вход «руками» — и посмотрите, как меняется динамика развития компании.

Подавляющее большинство мобильных приложений выходит в свет без интегрированных фреймворков аналитики и без правильной их настройки. Это очень печально, приложение не веб-сайт, где можно воткнуть Google Analytics за 10 минут и собирать статистику.

Я вижу четыре причины для того чтобы задуматься над аналитикой в мобильном приложении ДО его выхода:

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

Под катом набор инструментов для аналитики и рекомендации по их настройке принятые в Touch Instinct и ценные комментарии от LinguaLeo и агентства мобильной рекламы Mobio.

Сначала предметная область

Изначально была мысль написать очень подробный мануал, но потом решил остановиться на стратегиях.

Ключи/запросы

Это фразы, которые набираются в поиске, для достижения результата (ответа на вопрос, покупки, получения информации…)
По частотностям
НЧ – низкочастотные (величина вычисляется логарифмически относительно самого большого числа запросов по ВЧ запросу из категории), для простоты пусть будет все что ниже 300 запросов (хотя в каждой группе по разному).
СЧ – среднечастотные (величина вычисляется логарифмически относительно самого большого числа запросов по ВЧ запросу из категории), для простоты пусть это будет все что выше 300 и ниже 2000 запросов (хотя в каждой группе по разному).
ВЧ – максимальное значение количества поисков простого запроса, к примеру «Светильник».
По конкуренции
НК – низкоконкурентные запросы, по которым есть шанс двинуться в топ (мало точных вхождений поисковой фразы, мало главных страниц, низкое количество результатов в поисковой выдаче)
СК – средне конкурентные запросы, по которым есть шанс продвинуться в топ, но есть и конкуренция (весь топ занят или главными или точными вхождениями, но показатели ссылочной массы конкурентов низкие)
ВК – высококонкурентные запросы, по которым необходимо из кожи вон вылезти чтоб продвинуться (и топ весь занят, и ссылочная масса ужасающая) при средних бюджетах ВК топ недостижим, но можно долго работать, чтоб кардинально поменять выдачу (закупка сателлитов, ссылочной массы, грамотное внутренне СЕО).

Семантическое ядро

Предполагает, что будет оптимизироваться каждая страница сайта. Это значит, что страница конечно будет давать ответ на запрос пользователя, но при этом на ней должен быть материал, который включает в себя эти ответы. То есть признаки, по которым ПС сможет выдать именно эту страницу на это запрос…
Пока что это сами запросы пользователей – они же «КЛЮЧИ»
Ключевые фразы подбираются для каждой страницы персонально.
Для главной страницы берутся общие запросы (описывающие общую категорию и выделяющие общую тематику сайта).
Для страницы категории выбираются запросы более узкой тематики, выделяющие отдельную категорию в общей всего сайта.
Для страницы товара/услуги – берутся максимально конкретные запросы, отражающие ее суть и позволяющие максимально точно ее/его идентифицировать.

0 Стратегия: Тариф Беззаботный

Минимум затрат, так как трафик тупо покупается у ПС. Других вариантов нет.

1 Стратегия: На халяву

Низкоконкурентный трафик – занимается ниша, где есть спрос, но нет конкурентов – классический «кто первый встал – того и тапки».
Схема до боли проста – ищем свободные ниши, подбираем НК запросы, пишем материал (даем полезное на запрос пользователя) – попадаем в ТОП, для усиления эффекта можно закупить по парочке ссылок.

Система MajorDoMo объединяет в себе различные компоненты, действие многих из которых сопряжено с чтением либо изменением данных. Для организации эффективного обмена данными между частями системы была создана объектная модель. Данная модель во многом соответствует парадигме Объектно Ориентированного Программирования (ООП) и людям, знакомых с данной парадигмой, не составит труда разобраться в имеющейся модели. Однако, знание принципов ООП совсем не обязательно, т.к. встроенная в систему модель достаточно упрощённая и может применяться без глубокого знания какого-либо языка программирования или же в качестве первого шага обучения этой концепции. В статье описаны основные составляющие этой модели.

Disclaimer:
Данная статья представляет собой вольный художественный пересказ-перевод первой главы книги "App Savvy
Turning ideas into ipad and iphone apps customers really want"

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


Чтобы полностью оценить жизнеспособность идеи вашего приложения, сначала вы должны понять текущую ситуацию с приложениями в App Store, оценить стоимость запуска вашего приложения, и реалистично смотреть на возможность попадания вашего приложения в каталог App Store. Под «вами» и «вашей идеей» я подразумеваю не только лично вас, а всех людей — родственников, друзей и коллег — с которыми вы прорабатываете вашу идею. Оцениваете ли вы идею в одиночку, или с кем-то, я хочу предложить вам схему, следуя которой вы сможете получить более структурированную оценку вашего приложения. В конце статьи будут приведены ссылки на полезные ресурсы и инструменты, которые помогут вам оценить вашу идею.