• Разработка UI с помощью Flutter

    Привет, Хабр! Представляем вашему вниманию перевод статьи "Building Layouts".

    Сегодня мы узнаем:


    • Как работают механики построения UI на Flutter
    • Как верстать экраны горизонтально и вертикально
    • Как сверстать экран, используя Flutter

    Результатом сегодняшнего урока будет следующий сверстанный экран

    image

    Читать дальше →
  • Kodein — интересная альтернатива Dagger 2 для внедрения зависимостей в Kotlin

      Здравствуйте, меня зовут Владимир, я работаю главным ИТ-инженером в СберТехе, в команде Digital Business Platform. Как-то раз за обедом мы обсуждали плюсы-минусы Dagger 2 и то, что хотели бы поменять в своей реализации. Нас много, и кода мы, соответственно, тоже пишем много, так что на тот момент в нашем приложении уже было 100500 методов и полтонны dex-файлов. Пораскинув мозгами, пришли к выводу, что писать меньше у нас не получится, зато можно уменьшить количество генерируемого кода при компиляции. Так было принято решение искать альтернативу существующему мастодонту от компании Google.


      Читать дальше →
    • Приложение для iOS и Android на Kotlin + Flutter UI

      • Tutorial
      image

      Вступление


      Всем привет. Какое-то время назад, я решил делать свой проект для Android и iOS одновременно. Естественно, встал вопрос о выборе технологий. Пару недель присматривался к популярным стекам и выбрал Kotlin/Native. Поскольку я являюсь Android-разработчиком, то с Kotlin знаком давно, а со Swift особого опыта не было и хотелось получить большую часть кода общего для обеих платформ. Следовательно, сразу встал вопрос, а как писать UI для iOS. Быстрый взгляд на рынок подсказал, что есть Flutter, который позволяет писать UI для двух платформ одновременно. Собственно, так и началась эта история.

      В статье описан опыт сборки Flutter в качестве UI и Kotlin для основной логики. Важно: под катом много картинок и инструкция, как собрать проект
      Читать дальше →
    • Flutter: прокачиваем AppBar & SliverAppBar

      • Translation

      Во Flutter для создания панели инструментов используется хорошо всем известный AppBar, ну а когда нам нужна динамическая панель инструментов, которая покажет контент при свайпе, мы используем отличный виджет SliverAppBar.


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


      Я видел много вопросов на StackOverflow и в группах Facebook о том, как можно изменить AppBar и SliverAppBar с точки зрения поведения или дизайна.


      Давайте рассмотрим две задачи.

      Читать дальше →
    • Основы архитектуры приложений на Flutter: Vanilla, Scoped Model, BLoC


        (оригинал статьи на английском языке опубликован на Medium)


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


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


        1. Запрос и загрузка данных.
        2. Трансформация и подготовка данных для пользователя.
        3. Запись и чтение данных из базы данных или файловой системы.

        Учитывая все это, я создал демонстрационное приложение, которое решает одну и ту же задачу используя различные подходы к архитектуре.

        Читать дальше →
        • +21
        • 11.2k
        • 6
      • Современная MVI-архитектура на базе Kotlin

        • Translation


        За последние два года Android-разработчики в Badoo прошли длинный тернистый путь от MVP к совершенно иному подходу к архитектуре приложений. Мы с ANublo хотим поделиться переводом статьи нашего коллеги Zsolt Kocsi, описывающую проблемы, с которыми мы столкнулись, и их решение.

        Это первая из нескольких статей, посвящённых разработке современной MVI-архитектуры на Kotlin.
        Читать дальше →
      • Многомодульность в Android с точки зрения архитектуры. От А до Я

          Всем привет!

          Не так давно мы с вами осознали, что мобильное приложение — это не просто тонкий клиент, а это действительно большое количество самой разной логики, которое нуждается в упорядочивании. Именно поэтому мы прониклись идеями Clean architecture, прочувствовали, что такое DI, научились использовать Dagger 2, и теперь с закрытыми глазами способны разбить любую фичу на слои.

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

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

          В своей статье я хочу вам рассказать, как дошел до многомодульности именно с архитектурной точки зрения. Какие проблемы меня беспокоили, и как я их старался поэтапно решать. А в конце вас ждет алгоритм перехода с мономодульности на многомодульность без слез и боли.
          Читать дальше →
        • О чём молчит developer.android.com про RecyclerView?

          Вопрос о жизненном цикле (life cycle) активности (activity) или фрагмента (fragment) андроид-приложения чрезвычайно важен для практикующего андроидчика (андроид-разработчика). Почему? Потому что порядок выполнения обратных вызовов всех методов, связанных с состоянием жизненного цикла (onCreate(), onStart() и т.д.), жёстко задан и неправильное его применение приведёт к неработоспособности приложения. При чём здесь жизненный цикл? — спросит внимательный хаброчитатель. Ведь в заголовке, вроде бы, речь не о нём? Отвечаю: между жизненным циклом активности и работой RecyclerView есть нечто общее — это НАЛИЧИЕ ЖЁСТКОГО ПОРЯДКА выполнения методов обратного вызова при использовании данного виджета, и, следовательно, необходимость ЕГО ПРАВИЛЬНО ПРИМЕНЯТЬ.

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

          Читать дальше →
        • О чем все-таки говорит developer.android.com про RecyclerView

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


            Начнем с самого начала. Полностью согласен, что "между жизненным циклом активности и работой RecyclerView есть нечто общее" – это "нечто" – необходимость понимать, что мы делаем и зачем. И читать документацию. А невыполнение этих двух необходимостей, как и сон разума, рождает монстров. Только вот с тем, как предлагает с этими монстрами бороться предыдущий автор, я категорически не согласен.

            А почему?
            • +12
            • 5.6k
            • 8
          • Ускорьте Ваше приложение. PERFMATTERS!.

            • Translation

            Мои правила


            Каждый раз, когда у меня возникает проблема в производительности, я следую этим правилам:
            • Всегда измеряйте — оптимизация с помощью глаз плохая идея. Когда вы просмотрели ту же анимацию несколько раз, вам кажется, что она выполняется быстрее. Цифры не врут. Используйте инструменты, о которых я расскажу, и измеряйте поведение вашего приложения несколько раз до и после того как делаете изменения.
            • Используйте медленные устройства — Если вы хотите найти все слабые места, вам больше помогут медленные устройства. Новые и производительные устройства не будут показывать ваши возможные проблемы производительности и не у всех ваших пользователей есть топ устройства.
            • Компромиссы — Оптимизация производительности всецело состоит из компромиссов. Вы оптимизируете одно в обмен на другое. Во многих случаях этот другой компромисс может быть потраченным временем на нахождение и исправление производительности, также он может быть качеством ваших растровых изображений или количеством данных которые вы должны хранить в определенной структуре данных. Приготовьтесь жертвовать чем-либо.

            Читать дальше →
          • Delegate Adapter — зачем и как

              Практически во всех проектах, которыми я занимался, приходилось отображать список элементов (ленту), и эти элементы были разного типа. Часто задача решалась внутри главного адаптера, определяя тип элемента через instanceOf в getItemViewType(). Когда в ленте 2 или 3 типа, кажется, что такой подход себя оправдывает… Или нет? Что, если завтра придет требование ввести еще несколько типов да еще и по какой-то замысловатой логике?



              В статье хочу показать, как паттерн DelegateAdapter позволяет решить эту проблему. Знакомым с паттерном может быть интересно посмотреть реализацию на Kotlin с использованием LayoutContainer.
              Читать дальше →
              • +7
              • 12.4k
              • 5
            • Головная боль от RecyclerView.Adapter — выход есть

                Привет, Хабр! Сегодня в нашем блоге Макс Туев, архитектор Surf, одной из наших сертифицированных студий. Ребята занимаются заказной разработкой, поэтому сроки важны не меньше, чем качество кода. Подходы и технологии, которые тормозят разработку, здесь не подходят. Хороший пример такого — RecyclerView.Adapter. Под катом Макс расскажет, как сэкономить время и нервы. Слово Максу.


                Читать дальше →
                • +19
                • 11.2k
                • 4
              • Избавляемся от рутины RecyclerView.Adapter с помощью DataBinding


                RecyclerView — основной UI элемент практически любого приложения. Написание адаптеров и ViewHolder'ов зачастую слишком рутинная работа и содержит достаточно boilerplate кода. В этой статье я хочу показать как с использованием DataBinding и паттерна MVVM можно написать абстрактный адаптер и напрочь забыть про ViewHolder'ы, inflate, ручной биндинг и прочую рутину.

                Читать дальше →
                • +6
                • 15.7k
                • 4
              • Рецепты под Android: Как вкусно приготовить LayoutManager

                • Tutorial
                Привет хабр!

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


                Читать дальше →
                • +33
                • 38.5k
                • 4
              • Обнаружение зависимостей Android компонентов

                Это не очередная статья про Dagger и его возможности. Не будет ни слова про другие DI фреймворки.

                scan

                Цель данной публикации — продемонстрировать подход к получению зависимостей во фрагментах, диалогах и активити.
                Читать дальше →
              • Библиотека для совершения покупок внутри приложений (Android In-App Billing v.3)


                  Checkout («касса», «кассовый аппарат») — это библиотека для совершения покупок внутри приложений на базе Android In-App Billing v.3. Основная цель — уменьшить время разработчика, затрачиваемое на внедрение платежей в Андроид приложения. Проект был вдохновлён библиотекой Volley, и проектировался для того, чтобы быть максимально простым в использовании, быстрым и гибким.
                  Читать дальше →