Доповіді

If you want to share the code between Android and iOS but you don't feel like doing C++/JNI, React Native, Flutter, you must try Kotlin/Native! In this presentation we will see how Kotlin/Native is different and in some aspects superior, and how easy it becomes to develop, debug and maintain a common codebase with JetBrains tools and without sacrificing runtime performance.

Хороший дизайнер на вагу золота. Він підготує екрани, визначиться з кольорами та шрифтами, пропрацює додаток так, щоб він відповідав усім вимогам цільової платформи. Але буває, що клієнтські правки в готовий дизайн (або навіть готовий додаток) створюють дивовижні можливості для вправ з рефакторінгу для розробників, наприклад:

• зміни шрифт у всьому додатку на мій улюблений
• а можна список показати у вигляді сітки?
• хочу щоб AppBar скролився разом з контентом.
• ця картинка повинна вилітати за межі екрану, змінюючи колір, прокручуючись навколо своєї осі, повільно розчиняючись "у тумані".
• і т.д.

Якщо вас дратують подібні ситуації, то швидше за все ваш інструмент недостатньо хороший. ;)

У цій доповіді ми візьмемо кілька екранів з Mobile UI Inspiration розсилок з найсміливішими дизайнерськими фантазіями і реалізуємо їх на Flutter. Обережно, буде багато коду!

В наш час мало просто писати код, його треба писати красиво і "правильно". Так як ці поняття вельми різняться від людини до людини, то в якийсь момент команди приходять до того, щоб формалізувати красивість і правильність. Деякі команди, втомившись лаятись в pull-request'ах через некрасиво оформлений код, йдуть далі та налаштовують автоматичні перевірки. Хтось навіть довіряє інстументам настільки, що дозволяє змінювати і виправляти код.

У цій доповіді я розповім про бібліотеки та інструменти, метою яких є робота з кодом. Розглянемо освновні відмінності бібліотек та області їх застосування. Після доповіді ви нарешті будете відрізняти SourceKit від SourceKitten, libSwiftSyntax від Swift Syntax.

Одвічний вибір: швидко, дешево або красиво. До недавнього часу при розробці мобільних додатків можна було отримати два з трьох. Найчастіше в жертву приносили UX/UI, причому ситуація була особливо плачевною в категорії додатків для бізнесу. Користувачам пропонували щось, що в кращому випадку не порушувало HIG платформи, а часто так взагалі було калькою web версії. Але ситуація змінюється з приходом Flutter!

У цій доповіді ми поговоримо про те, як писати надійні, красиві додатки, на ультра швидкості та без особливих витрат.

Using React Native, Flutter, Hybrid Web, Unity, Kotlin Multiplatform could be an interesting strategy, but what if we want to stay within traditional native development on both platforms?

A syntax of Swift and Kotlin looks pretty similar, especially if you are cooking it with RX. So, what if we will implement a new feature on one platform and then, kinda, copy-paste the code to another one, with minimum modification? How good it will work for us? How should we deal with platform-specific features? Will this strategy make a project too complex?

This speech will show the way, how to design your project in order to minimize the headache of implementing the same feature for both mobile platforms. Also, we will talk about gains and losses during implementation on a real project with this design idea.

My team's main focus in the recent past was rebuilding our company's main Android product - the trading app.

Our app was nearly 500k lines of code worth, written by dozens of devs in a timespan of 8 years, almost fully in Java. This obviously affected our velocity and caused us to deliver slower than we could potentially do.

During my talk, I'd like to go through the challenges we've faced and architecture decisions we have made to end up having a much healthier codebase.

Come to my talk to learn how we:

• Split our project into decoupled feature modules and multiple app-agnostic SDKs.
• Made sure the new release of the app wasn't a shocker to our clients - a complete redesign of the app in one drop wasn't an option.
• Managed to rebuild tons of features in a short timeframe by focusing on things that mattered the most and taking smart shortcuts.

Optional є одним з фундаментальних типів у Swift. На жаль, незважаючи на його поширеність, чимало розробників не звертають уваги на можливості, приховані у цьому типі, або використовують його недоречно. Все це призводить до порушень основних принципів програмування, а також нехтує деякими потужними можливостями, доступними у Swift. Крім того, цей тип дозволяє розглянути важливі концепти, які зроблять рутинну роботу з Optional і схожими типами, ефективнішою та зручнішою.

Під час доповіді ми відповімо на питання чому та як слід оминати optional binding. Розглянемо приклад з код-рев'ю і зробимо рефакторинг у фунціональному стилі щоб побачити недоліки та переваги такого підходу у Swift. Це надасть нам змогу дослідити як Optional впливає на DI та обробку помилок і які є альтернативи до стандартних технік, доступних у Swift.

Обрати архітектуру для розробки не просто. Серед безлічі можливих архітектурних рішень для Flutter у фаворити вибились BLoC і Redux. BLoC ― нове рішення від компанії Google, яке лише починає набувати популярності. Redux ― незмінний улюбленець ком'юніті. І, звісно, мій. Саме про нього і поговоримо.

Під час доповіді ми візьмемо готовий UI шар і реалізуємо всі необхідні Redux компоненти: Store, State і Reducer Actions. А також специфічні для Flutter елементи ― StoreProvider і StoreConnector.

Docker - популярне слово в світі backend-у, а чим він може стати в пригоді в Android розробці? Виявляється може. Коли проект тривалий і досить серйозний, то справа доходить до написання тестів на декількох рівнях(unit, integration, UI automation), а це в свою чергу вимагає налаштування pipeline-у на CI, який би правильно проганяв ці тести на кожен коміт. Наступні питання виникають: як зробити щоб різні види тестів ранились паралельно, як ранити паралельно на кількох девайсах, на кількох типах backend-у, і при цьому щоб одні тести не "заважали іншим". Тоді на допомогу і приходить Docker - пісочниця яка дозволяє ізолювати середовище і думати про масштабування. В багатьох випадках можуть допомогти devops піхотинці, але не завжди вони виділені на проект чи можуть зрозуміти що ви від них хочете. 

В рамках доповіді буде коротко розглянуто основні ідеї такого потужного інструменту як Docker, його можливості, буде написано вживу невеликий instrumentation тест для демо-проекту, потім написано Dockerfile для проекту і скрипт, який розвертатиме контейнер і його можна буде виконувати на CI, наприклад Jenkins.

Вже десять років ми активно працюємо над створенням мобільних додатків. Користувачі стають все більш вибагливими, темпи розробки зростають, і дизайн не стоїть на місці. Ми розкажемо, що насьогодні вважається якісним дизайном, які дизайн-практики використовуються для забезпечення якості дизайну, як передати наробки дизайнерів команді розробників. Окрім цього розкажемо, де шукати натхнення і заряджати ним колег.

В рамках доповіді ми розповімо про дизайн мислення, креативні воркшопи, юзабіліті тестування, дизайн-систему і базовану на ній SDK, як подружити дизайн та аджайл.

Всі сучасні популярні DI-фрейморки для Java використовують обробку анотацій під час компіляції та/або під час виконання програми. Вони однаково добре працюють і для Kotlin, але мають свої недоліки, бо генерують забагато коду та/або використовують рефлексію, що негативно позначається на часі компіляції додатку, його розмірі та швидкодії. Крім того, зазвичай їх конфігурація є нетривіальною для великого проекту. Kotlin пішов кращим шляхом...

В рамках доповіді буде продемонстровано як можна легко та ідіоматично організувати DI у своєму коді без допомоги сторонніх фреймворків. Натомість, в режимі програмування наживо ми разом створимо свій фреймворк без жодної анотації, де використаємо виключно стандартні можливості мови Kotlin.

Reactive programming becoming very popular these days and many people already adopted or started to adopt it in their projects. This is indeed a great tool but in the wrong hands, it quickly can get out of hands. Polluting the codebase with spaghettis of reactive operators where it can be hard to reason about and debug.

In this talk, I will share our experience with reactive programming at Babylon Health. And show our approach on how we manage the state in our ViewModels in a unidirectional way.

У якийсь момент найпростішим способом залучити нових користувачів стає придбання конкурента.

Йтиметься про технічні челенджі, з якими ми зіткнулися при міграції кількох VPN-додатків від куплених компаній, у проект з єдиною інфраструктурою та різними користувальницькими інтерфейсами, використовуючи VIPER.

В рамках доповіді будуть розглянуті наступні питання:

• стандартизація архітектури для всіх проектів;
• переваги та недоліки моно-репозиторіїв та наш підхід до міграції мобільних додатків від сторонніх компаній на наші рейки.

The introduction of Android Architecture Components made a lot of things easier for Android developers. Despite this, the documentation is still not complete and confusing. Here and their developers arise questions like: “How should I handle communication between ViewModels?”, “How to send one time events properly?”, “How to fill pleasure from Android development again?”.  I will cover these topics and guide you through this dark forest and show that the light of TDD.

In this talk, I will cover the most popular pitfalls when using ViewModels and show how one can easily follow the TDD approach while implementing MVVM on Android.

У середовищі розробників існує думка про те, що сучасні проекти, зокрема - Android проекти, - всього лише пазл з бібліотек та невеликої кількості бізнес-логіки. В рамках моєї презентації ми розглянемо кілька проектів, на прикладі яких я покажу деякі проблеми та приховану вартість використання деяких бібліотек, про яку мало хто замислюється.

В якості бонуса ми подивимося на деякі приклади очевидного (і не дуже) поганого коду та поганої архітектури.

Під час презентації ми розглядаємо як деякі відомі бібліотеки (RxAndroid, Dagger, Android Architecture Components) використовуються в занадто широкому сенсі або на занадто ранній стадії, і як це заважає проекту, викликаючи вельми неочевидні проблеми як для розробника, так і для кінцевого користувача.

Google Wear OS, formerly Android Wear, is the platform for wearable devices, watches primarily. In this talk, I would like to present what kind of applications may be developed for this platform, how it differs from regular Android development, what are the limitations, pitfalls and caveats.

In the deck I plan to cover the next topics:

• Kinds of applications available
• API available on the watch itself
• API for communication with a connected phone
• Watch face development specifics

Десятиліття тому Інтернет був зовсім не торт і мобільні пристрої не були вишенькою. Вразливості у доступі до персональних даних стирчали з таких місць, куди сьогодні може дістатись і дитина, та під час перегляду свинки Пеппи злити доступ до всіх ваших кредитних карт. 

Прихід протоколу OAuth не зміг врятувати нас від ремейків Філіпа Кіркорова та клауд-репу, але спробував убезпечити доступ до наших даних. Але він не допоможе тобі, юзернейм, якщо ти не вмієш користуватися ним як слід.

Так що влаштовуйся покомфортніше на кухні мобільної авторизації, будемо готувати OAuth2 та OpenId.

Протягом цієї сесії я розповім:

• Що таке SAML (та про ледачі банки)
• Чим авторизація відрізняється від аутентифікації
• Що таке OAuth та OpenID та навіщо вони потрібні
• Які є OpenID SDK та чи варто їх використовувати?

Протягом останніх двох років Room був переважним рішенням для роботи з SQLite в Android. Але нещодавно була випущена нова версія бібліотеки SQLDelight, яка підтримує kotlin multiplatform, має перероблений api, новий генерований Kotlin-код, розширення до RxJava2, підтримує Paging-бібліотеки та багато іншого. З його можливістю генерувати в live-режимі typesafe kotlin код з чистого SQL за допомогою плагіну Android Studio важко конкурувати. Чи все ще варто розглядати інші рішення, маючи такий потужний інструмент?!

На цій сесії ми розглянемо основні можливості SQLDelight та в live-режимі побачимо, як він працює. Розберемо типові випадки його використання та поміркуємо про можливості multiplatform використання SQLDelight у майбутньому.