Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Як зіскочити з Android Studio та опанувати VS Code розробнику на Flutter

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Розробкою мобільних застосунків я займаюсь вже майже 5 років. Увесь цей час для роботи використовував Android Studio (AS надалі). На Flutter я програмую близько 3 років і не так давно почав помічати, що «Студія» зі зручного інструменту стала перетворюватись на перевантажений комбайн.

І все б нічого, але абсолютна більшість інструментів направлена на покращення користувацького досвіду саме нативного розробника. Для Flutter-девелопера це скоріш вантаж, який якщо і потрібен, то настільки нечасто, що ним можна знехтувати. Тому я спробував VSCode і хочу поділитись з вами своїм досвідом. Можливо, я замотивую когось перейти з AS з іншої IDE, а можливо, продемонструю, що перехід того не вартий.

Тож, кому буде цікавою ця стаття:

  • Flutter-розробникам, які працюють на Android Studio, проте відчувають, що їм щось в ній не подобається.
  • Flutter-розробникам, які вже працюють з VS Code. Можливо, ви знайдете щось цікаве і корисне.
  • Будь-яким розробникам, які хотіли б дізнатись щось нове про VS Code.

Хоч ця стаття і планувалась як порівняння AS з VSCode, проте інформації буде більше саме про VSCode і про те, як там усе працює.

Ще одна важлива деталь перед тим, як почати. Я буду розповідати саме про реалізацію якоїсь функції в VSCode та/або порівняння її реалізації з Android Studio. Якщо ви не знайомі взагалі з якоюсь функцією (наприклад, що за команда git blame, нащо вона потрібна і як використовується без прив’язки до IDE), я не буду її тут розписувати. Це виходить за рамки статті й значно збільшить її об’єм.

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

Keymap & Shortcuts

Я з тих людей, які намагаються не перенести користувацький досвід з однієї системи на іншу, а зрозуміти, чого розробник екосистеми хотів домогтися. Тому я не почав відразу змінювати всі шорткати на студійні, а спробував власноруч оцінити зручність запропонованого рішення.

Наведу приклад моїх типових повсякденних шорткатів VSCode та їхні аналоги в студії:

А проте, деякі комбінації я змінив та доповнив. Просто не зміг звикнути до стандартних.

Command Palette

Command Palette — це також дуже зручний інструмент, який приблизно можна охарактеризувати як суміш finder та терміналу. Цей інструмент дозволяє:

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

Якщо коротко, це, найімовірніше, буде інструмент, який ви будете використовувати постійно. Запам’ятати усі потрібні хоткії, а тим паче призначити на все на світі — дуже складно. Проте зручний пошук, який дозволяє ігнорувати половину символів з назви тієї команди, яку ти шукаєш, дає можливість практично забути про навігацію через різні меню за допомогою курсора.

Звичайна Палітра

Для початку потрібно запам’ятати комбінацію cmd + P. Ця комбінація відкриває Command Palette (буду інколи називати просто «палітра») в режимі, який дозволяє шукати файли за назвою чи за шляхом до них або викликати допоміжні команди з меню. Наприклад, якщо ввести слово debug і поставити пробіл, то ви побачите перелік конфігурацій для запуску застосунку в відлагоджувальному режимі. Якщо ввести view — ви відповідно побачите перелік усіх меню які зараз можна показати.

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

Палітра для роботи з командами «>»

Другою (а можливо, і першою) за частотою використання у вас буде палітра, що дозволяє шукати та виконувати команди всіх плагінів і підменю VSCode. Для відкриття цієї палітри використовуйте комбінацію cmd + shift + P.

Відкриється вже знайомий нам Command Palette з символом >. Ви можете почати відразу вводити назву команди чи почати з назви плагіна, потім почати вводити команду. Можете пропускати символи (як я зазначав раніше) чи ігнорувати пробіли. Пошук доволі гнучкий (не тільки в цій палітрі, а всюди), тож проблем з пошуком відповідних речей у вас не повинно виникати.

Пошук за символами у відкритому файлі «@»

cmd + shift + O. Відкриється Command Palette, але вже з проставленим символом @. Це дозволить шукати символи в межах відкритого файлу. Під «символами» мається на увазі пошук за назвою класів, методів, полів.

Пошук за символами по всьому проєкту «#»

Те саме, що і в попередньому абзаці, але по всьому проєкту, включно з залежностями. Cmd + shift + T.

Перейти до рядка «:»

Мабуть, вже здогадались :) Можна перейти до рядка в файлі та до потрібного символа в рядку.

Source Control

Дозволяє отримати інформацію про всі зміни (changes), які зараз є в коді. На відміну від студії, де відразу ж можна скористатись комбінацією cmd + K, щоб зробити коміт, тут потрібно спочатку зафіксувати (stage) зміни. Це можна зробити через палітру (cmd + shift + P; Git: Stage All Changes). Або через хоткій. У мене це cmd + shift + A. Альтернативно можна скористатися відповідною кнопкою навпроти імені файлу. Після цього робимо commit за допомогою палітри або хоткія (як, в принципі, і будь-який наступний етап, тому я більше не буду повторюватись) і потім push. Також ви можете для будь-якого коміту стейджити окремий файл і навіть окремі рядки коду в файлі. Це може бути доволі зручно, коли ви намагаєтесь розбити якийсь великий шматок роботи на декілька маленьких і зрозумілих комітів.

Якщо у вас немає бажання стейджити зміни перед кожним комітом, ви можете активувати Smart Commit у налаштуваннях. Це дозволяє відразу робити коміт з усіма актуальними змінами, якщо жодних змін не було застейджено вручну.

Якщо ви застейджили окремі рядки в файлі, то можна окремо дивитись як на зміни, що застейджені, так і на ті, що не застейджені. Для перегляду файлу без порівняння з початковою версією є окрема кнопка (Open File).

Є ще один маленький нюанс щодо роботи з файлами через Source Control, що може бути неочевидним. Навпроти імені файлу ви інколи можете побачити букви M, або ж U.

Або ж червоні цифри.

Коротко:

  • M — Modified.
  • U — Untracked.
  • Цифри — кількість помилок при компіляції, які знайшов аналізатор коду.

Плагіни

Насамперед, VSCode — це звичайний редактор коду із вбудованим Git Source Control, що для мене є його найбільшою перевагою. Завдяки цьому VSCode дуже легкий, швидко запускається і працює без проблем. У разі, коли вам не вистачає якоїсь функціональності, на допомогу приходять плагіни. Вони надлегкі, їх сила силенна, а встановлення навіть не потребує перезавантаження VSCode.

Git (GitLens)

Цей плагін можна вважати доповненням до Source Control. Деякі корисні функції для початку розробки за допомогою VS Code:

Git Blame

Наразі Source Control не має зручної реалізації git blame з коробки, як от, наприклад, Annotation в AS. Проте тут вона доволі непогана. Виконайте через палітру Toggle File Blame, щоб зліва від робочого простору з’явилось аналогічне до AS меню зі змінами в коді. Якщо виконати Toggle Line Blame, то плагін буде підказувати, хто і коли змінив саме рядок, на якому зараз знаходиться курсор. Також прикольна штука — File Heatmap: залежно від кольору, який з’явиться біля рядка коду, можна швидко зробити висновок, як давно внесено зміни в файл. Доволі зручно, коли потрібно шукати, що зламалось, наприклад, після останнього мержа.

Commits

Це підменю являє собою відображення всього дерева комітів. Розповідати тут мало чого, крім цікавої фічі доволі зручного порівняння гілок. Потрібно натиснути на кнопку, показану на скріні.

І в меню, яке з’явиться з палітри, вибрати потрібну гілку. Ви зможете подивитись коміти Ahead і Behind, а також зміни відносно вибраної гілки в кожному файлі.

Ще деякі підменю

Наступні підменю також потрібні й цікаві, проте немає сенсу розписувати щось дуже детально, тому коротко про головні:

  • File History — як можна здогадатись, це історія змін у файлі. Показує як історію запушених в remote комітів, так і зміни: незастейджені/застейджені/закомічені.
  • Branches — перелік гілок. На відміну від commits тут більше уваги приділено саме перегляду гілок і керуванню ними.
  • Search & Compare — аналогічно порівнянню з меню Commits, але трішки зручніше. Можна знайти конкретний коміт або посилання (тег, гілка або посилання на коміт).
  • Stashes — говорить саме за себе. Це ваш код у git stash.

Git Graph

Плагін, який дає можливість дуже зручної візуальної презентації вашого репозиторію. Крім цього, додає такі зручні функції як:

  • прив’язка до issue — дає можливість навігації до issue через посилання у коментарі до коміту у вигляді номеру issue;
  • автоматизація створення Pull Request для Github, Bitbucket або Gitlab.

Інтеграція з GitLab (GitLab Workflow)

Цей плагін буде до душі будь-кому, хто працює з GitLab і має регулярно робити код-рев’ю та/або слідкувати за життям проєкту. Цей плагін дає слідкувати за мерж-реквестами, створювати їх, писати коментарі, закривати треди та має ще безліч функцій, що економлять час та дозволяють рідше виходити з VSCode.

На жаль, GitLab Workflow не дає можливості затвердити запит на мерж :( Найшвидший спосіб зробити це — перейти в Overview потрібного мерж-реквесту і натиснути Open in GitLab. Тому залишається чекати, поки це реалізують, і бути активним на їхньому репозиторії.

Ще є проблема з переглядом своїх коментарів до коду, що змінився після код-рев’ю, якщо рядок з коментарем видалили. У пригоді тут стане меню Comments у панелі.

До речі, користувачам GitLab CI має сподобатись команда Validate GitLab CI config для файлів конфігурацій. Це дозволить швидко перевірити, чи все гаразд, особливо у разі об’ємних та складних конфігурацій чи коли редагувальнику бракує досвіду.

Підключення цього плагіну не є тривіальним, новачкам не завадить інструкція. Зазначу лише, що у разі помилок з instanceUrl або токеном, варто скористатись функцією Remove Your GitLab Personal Access Token через палітру. Це допоможе впоратись з тонною повідомлень про неможливість завантажити репозиторій.

Декілька невеличких цікавих плагінів

Плагіни:

  • Thunder Client — маленький Postman.
  • Live Share — допоміжний плагін у парному програмуванні або парному рев’ю.
  • Dart build runner — зручний інструмент для роботи з build runner.
  • Clipboard Manager — розширення можливостей буферу обміну, майже так само як в AS.

Run/Debug

Тут нічого складного. Launch emulator дозволяє запускати емулятор Android і симулятор iPhone, що встановлюються окремо. Також є вбудований так званий flutter emulator, який емулює роботу Android.

Через палітру вводите Debug: і вибираєте спосіб запуску, а потім і сам пристрій для запуску, якщо їх під’єднано декілька.

Для запуску необхідно обрати конфігурацію з переліку і натиснути на кнопку Run.

Праворуч від переліку конфігурацій є кнопка у вигляді шестерні, що відкриває json-файл з налаштуванням саме конфігурацій. Наприклад, щоб додати аргумент для запуску —no-sound-null-safety, треба додати поле args: [«—no-sound-null-safety(або будь-який інший параметр)»] до вашої конфігурації.

"name": "work.ua",
           "request": "launch",
           "type": "dart",
           "program": "lib/main.dart",
           "args": [
               "--no-sound-null-safety"
           ]
       },

Tests

Для запуску тестів використовуйте меню Run, де виберіть потрібну вам конфігурацію запуску. В нашому випадку це Flutter: Run all tests. На вкладці Testing можна перевірити результат виконання у вигляді переліку тестів, пофарбованих в інтуїтивно зрозумілі кольори:

  • зелений — усе добре;
  • жовтий — тест пропущено;
  • червоний — біда.

Також є зручна можливість однією кнопкою окремо запустити лише червоні або жовті тести.

Консольний вивід тесту доступний на вкладці Testing. Через палітру можна виконати Test: Show Output. Відкриється новий екземпляр терміналу з логами тестів.

Мінуси порівняно з AS

Поки за час роботи зі студією я знайшов лише це:

  • Кожен індивідуальний тест, що потребує додаткових аргументів на кшталт —no-sound-null-safety, потрібно запускати через термінал, щоб не додавати конфігурацію запуску. В AS можна редагувати тимчасові конфігурації через GUI. Як варіант, можна зробити окрему конфігурацію з полем args і в ній змінювати шлях до потрібного тесту.
  • Написання і супровід Swift або Java/Kotlin-коду все ж буде зручніше в Android Studio/Xcode. Тож повністю від них я б не відмовлявся.

Висновок

На момент написання статті я вже пів року використовую VS Code як основну IDE. Можна сказати, що вона задовольняє мої потреби на 90%. При супроводі коду Flutter лізти в нативний код доводиться доволі рідко, тому з цим нюансом розробки цілком можна жити.

Особисто я віддаю перевагу VS Code через зручність і функціональність, плагіни й те, як влаштована робота з ними. Мені подобається досвід, який я отримую від роботи з VS Code.

Розробникам, у котрих більшість коду знаходиться на нативному боці, я б рекомендував залишитись на Android Studio, насамперед, якщо це Kotlin. А тим, у кого більшість коду на стороні Flutter і хто відкритий до нового досвіду, — спробуйте, воно того варте.

👍ПодобаєтьсяСподобалось22
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Робила спробу перейти з AS до VS Code. Закінчила себе мучати, коли не змогла подружити IntelliJ шорткати з плагіном для множинного буферу обміну (як на мене, ця функція має бути вбудованою в IDE).

з плагіном для множинного буферу обміну (як на мене, ця функція має бути вбудованою в IDE)

Як на мене, ця функція має бути вбудованою в систему. Який сенс для окремого буферу виключно для IDE? А якщо мені щось з історії буферу треба в Slack закинути чи прогуглити?

Я про цю функцію в Android Studio згадую раз в півроку, коли випадково жмакаю шорткат. А так у мене глобальний шорткат для історії буферу (зараз через Raycast, раніше Alfred, але є і спеціалізовані програми виключно для множинного буферу).

Як на мене, ця функція має бути вбудованою в систему

Цілком згодна! Оскільки не чула про тули для осі, дуже активно користуюся цим функціоналом хоча б в IDE. Дякую за назви софту, спробую!

Щодо комбінацій клавіш — є ж офіційний плагін для шорткатів ідеї. Поставив першим ділом і нормально. Навіщо себе ламати, якщо не на все життя переїжджаєш у VS Code? 🙂

Підтримка гіта у VS Code відверто убога, порівняно з AS, і ніякі плагіни цього поправити до кінця не можуть.

Не вистачало плагіну ADB Idea, тож довелося написати свій marketplace.visualstudio.com/...​hyan.adb-command-launcher

З комбінацій клавіш — згоден. Але звик до нових і навіть зручніше, це суто моє суб’єктивне враження
ADB чомусь звик використовувати саме через термінал. Це мабудь одна з дуже невеликого переліку штук які я більше звик робити через термінал, проте плагін — це круто.
А з підтримкою гіт не згоден. Встановивши Git Lens і Git Graph взагалі не відчуваю, що мені щось не вистачає. А з Gitlab workflow і Live Share для ревью і парного програмування взагалі дуже круто виходить, якщо у тебе в обов’язках є ревью і навчання

Android Studio one love <3

Говно потребляющее всю оперативку)

Самый развёрнутый комментарий, наполненный глубоким смыслом и подкреплённый многолетним опытом. Что за чушь несёшь?? )))

Сейчас абсолютно весь софт это говно потребляющее всю оперативку, достаточно запустить браузер на бюджетном ноутбуке з селероном, и 4 Гб оперативной памяти, чтобы это доказать.

Да, тяжело нынче на компьютере с 2 ГБ ОЗУ работать.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Я от з Vim спробував перейти на NeoVim, але за годину повернувся. Бо сумісність має бути сумісною.

but why? intellij набагато потужніше ніж вс код. Так, там менше плагінів, але екосистема більш здоровіша.
+ до всього сказаного, jetbrains працюють над новою «легкою» ide, яка має перемогти vscode : www.jetbrains.com/fleet

По-перше: Мова йде саме про Android Studio. Яка йде з купою плагінів які віджерають пам’ять, але мені, як флаттер девелоперу, не потрібні. Як і купа налаштувань, кнопок на панелях і тд.
По-друге: Один з проектів JetBrains — Kotlin Multiplatforms. І я дуже сумніваюсь, що «легка» IDE буде підтримувати щось кроссплатформ крім Kotlin.
По-третє: такі плагіни як LiveShare і Gitlab Workflow «рєшают» особисто для мене. Подібних аналогів для студії я не знайшов.
По-четверте: Мені суб’єктивно вже після першого тижня VSCode здався зручніше. Особливо Command Palette.

І я чесно кажучи не зрозумів, що в вашому розумінні «здоровіша екосистема»?

ок ясно

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

Работал с VC несколько лет под React проекты и около 8 лет с Android Studio. При «нормальной машине» ну от слова «ВООБЩЕ» не увидел преимуществ в контексте работы с Flutter. А если учесть достаточно частую необходимость «ковырять» нативную часть андроид, то тут выбор очевиден...imao

JetBrains s.r.o. is a Czech software development company which makes tools for software developers and project managers.

так так так
з росіянами засновниками і офісами по московії)

треба тоді гуглом/android перестати користуватись, бо засновано росіянином і є офіс в московії

Ну про це писали багато закордонних газет. Що це за JetBrains. Наприклад одна з:
www.nytimes.com/...​cs/russia-cyber-hack.html

Звичайно там нема конкретних звинувачень, але і вони неможуть теж доказати, що вони не винні, бо дуже багато цікавого навколо цієї компанії.

Плохая аналогия подобна котенку с дверцей.
Брин — гражданин США и уехал из совка, когда ему было 6 лет. Второй сооснователь вообще к совку не имеет никакого отношения. В РФ у Гугла один офис из почти сотни мировых.
Все основатели JetBrains и подавляющее число сотрудников — граждане РФ с рождения и по данный момент, живут в основном там же. В РФ у JetBrains 4 офиса из 11, если брать именно разработку — вообще половина, 3 из 6.

Тут погоджусь.
Як тільки з‘явиться інструмент, з яким я не втрачатиму продуктивності на роботі, зразу злізу на нього.

Тебя не смущают москвичи в правительстве Украины, но смущают в чешской конторе, ты вообще нормальный?

Вгадай чий газ отоплює наші міста 🙄

Гарне порівняння газу з програмним забезпеченням 😁😁👍. Треба вивчити це питання, як хакнути когось через трубу з газом 😎

Гермашку хакнули, французов тоже. Мало?

Android studio ocнована на базе IntelliJ IDEA, wait, o sh......

Потому что если открыть и поработать пару часов — начинает тормозить

Пробував виділити більше, ніж 500Мб ОЗУ?

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі