Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?

Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?

Тогда вам сюда:

Такая история всегда начинается одинаково. Вам показывают демку, в которой набор проблем, ранее казавшийся сложным, решается на раз — достаточно запустить некий Волшебный Инструмент. Зачастую такой инструмент рекомендуют Большие Тузы из отрасли, либо не только рекомендуют, но и сами поддерживают. У вас в организации отыскиваются коллеги, ратующие за то, чтобы немедленно взять эту технологию на вооружение. Буквально наутро этот новый инструмент приравнивается к «решению всех наших проблем».

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

К тому моменту, как его обсуждение доходит до руководителей высшего звена, инструмент уже раскручен в пресс-релизах. Вы видите статьи в духе «Технология X морально устарела, время обзаводиться Волшебным Инструментом». Те из вас, кто не так давно работает в технической отрасли, могут предположить, что, пожалуй, была сделана какая-то добросовестная оценка, призванная проверить, в самом ли деле Волшебный Инструмент так хорош, или безопасен, или уместен именно в вашем бизнесе. Нет, вы ошибаетесь. 

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

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

Когда-то работа в фоне была простой. Теперь в Android есть множество ограничений: работа в фоне, доступ к файловой системе, разрешения на которые надо получить одобрение модераторов Google Play и другие. Со всеми ними разработчикам приходится работать. Недавно я выступил с докладом на эту тему на конференции DUMP, а теперь написал текст на его основе для Хабра. Давайте вспомним, с чего все начиналось и как менялись требования с каждой новой версией Android.

Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент. 

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

В данной части, обсудим как можно проверять размер в pull request, что позволит автоматизировать весь процесс обнаружения регрессии, до того как изменения попали в development.

Главная сложность в разработке приложения – накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

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

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

Периодически возникает желание получать уведомления, иметь возможность настраивать источник и фильтровать сообщения по темам, и писать как можно меньше кода. Например, присылать себе картинку/цитату/слово дня или дельту по изменениям ордеров на бирже. В результате получился универсальный инструмент - бот и персональное АПИ для отправки сообщений в Telegram.

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

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

Далее я покажу своё видение того, какие инструменты и в какой конфигурации должны применяться на Java проектах, а особенно в микросервисах.

Совсем недавно у меня появилась необходимость разработать функционал для взаимодействия между двумя приложениями одной компании, и недолго гуглив я открыл для себя мир межпроцессного взаимодействия в андройд - AIDL.

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

Казалось бы, на первый взгляд весьма простая задача. Некоторые читатели могли еще в те бородатые времена лазить по всяким 4пда, рутить свой сенсорный самсунг, менять содержимое файла build.prop и показывать наивным ламерам свой iPhone 15+ Max Pro. Однако, как оказалось, и как оно часто бывает, не все так просто и здесь есть свои подводные камни. Статья призвана помочь простым работягам избежать все кочки да ямы на пути к своей цели!

Ваши пользователи жалуются на то, что приложение очень быстро сажает заряд телефона? Запущенный фоновый сервис внезапно останавливается? Сообщения от FCM не доходят до пользователя? Что связывает эти три серьезных вопроса? Ответ прост — неверно выстроенная работа с энергопотреблением приложения.

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

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

В последнее время задача распознавания символов в прикладных программах не представляет особой сложности — можно использовать множество готовых OCR-библиотек, многие из которых доведены почти до совершенства. Но все же иногда может возникнуть задача разработать свой алгоритм распознавания без использования сторонних «навороченных» OCR-библиотек.

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