Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Software developer
  • Як вам реліз iOS 17 та новий iPhone? Обговорюємо

    Коли ви останній раз користувались андроїдом? Тільки нормальним, а не за 5000 грн.
    Я не пам’ятаю, коли востаннє бачив баг в андроїді. А от півроку назад бачив, як айфон завис, коли встановлював додаток. Або коли під час першого налаштування з коробки два рази кидав на першу сторінку.

  • Скільки грошей ви заробили на своїй першій інді-грі?

    Згадав анекдот від Максима Залізняка.

    — Скажите, как вы стали миллионером?
    — Купил молока, сварил головку сыра, продал. На вырученные деньги купил больше молока, сварил 5 головок сыра, продал.
    — А потом сварили 10 головок сыра?
    — Нет, умерла бабушка еврейка и оставила наследство.

  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою Handlers

    =)
    На минулому проекті я використовував ZXing для MAUI. В основному для сканування штрих-кодів, тому що це був проект складського обліку. Іноді доводилось і показувати штрих-коди. ZXing дуже добре сканував, але відображення штрих-кодів на той момент було не дуже стабільним. Іноді падав на спробі намалювати якийсь штрих-код (з правильною контрольною сумою).
    Якщо не секрет, як ви малютєте штрих-коди? Skia чи щось нативне?
    До речі, ваша бібліотека платна? Я щось не побачив ціни.

  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою Handlers

    Для чекбокса багато коду не треба. Його взагалі не треба. Але стандартний чекбокс не має тексту. Тому доводиться додавати Label поруч з чекбоксом. Щоб не робити цю нудну роботу, можна інкапсулювати Label і чекбокс в один компонент. І можна зробити це двома шляхами.
    Перший (повністю кросплатформовий) описується в попередній статті dou.ua/forums/topic/43481
    Другий (через нативні компоненти) описується в цій статті.
    Як я написав нижче, наступного разу спробую більш чітко формулювати цілі статті.
    Дякую за відгук.

  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою Handlers

    Моє недоопрацювання. Схоже, потрібно краще пояснювати цілі статті.

  • CDPR вибачається перед росіянами з офіційних акаунтів за «деякі репліки» в українській локалізації Cyberpunk 2077 (UPD)

    Ого, невже суспільство здатне так швидко деградувати, що за найкоротший час забуло «болгарську»-російську?

  • Хто такий Android-розробник, переваги та недоліки професії, необхідні навички

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

  • Хто такий Android-розробник, переваги та недоліки професії, необхідні навички

    Зараз я займаюсь backend розробкою. Рік тому ще працював над мобільними додатками. Складно сказати, що складніше, а що простіше.
    З одного боку, backend може здаватись складнішим через міжсервісну взаємодію, вимоги до архітектури, роботу з базою даних, pooling, черги і т. д.
    А з іншого, в більшості випадків backend має рівний послідовний код, усілякі перевірки з викиданням виключень, і доволі нечасте використання багатопотоковості. Часто (звісно, не завжди) відсутні якісь підводні камені, усе рівно і просто: прийшов запит, обробив логіку у відповідності до бізнес-вимог, віддав відповідь.

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

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

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

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

    По-четверте, є ще кросплатформова розробка зі своїми нюансами, які мені лінь розписувати.

    Ну і звісно є ще окремий світ зі своїми тараканами — фронтенд (веб).

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

  • Недовіра до влади vs жодної мороки з податками. Що розповідають айтівці про гіг-контракти

    Вже чотири місяці як на гіг-контракті. В порівнянні з фопом нічого не змінилось, окрім ведення звітності.
    Звісно, вигадати гіг-контракти замість однакових справедливих умов для всіх це в стилі нашої держави. Але поки що умови не гірші за ФОП.
    Усіляких пунктів про неконкуренцію у мене в договорі немає. Я здивувався, що хтось в статті погодився на це. Я вважаю, що адекватна компанія не має включати такі пункти у свій договір. Поки що це єдиний мінус, який може бути в гіг-контракті. Хоча таке можуть спробувати всунути в якийсь NDA для ФОПу. Але в будь-якому разі я сподіваюсь, що чим більше людей будуть від таких пунктів про неконкуренцію відмовлятись, то менше компаній це будуть у включати в договір.

  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою ContentView

    Microsoft та MAUI є в чому критикувати.
    Але я за два місяці зробив мінімальну робочу версію мобільного клієнтського додатку облікової системи. Там багато сторінок (екранів), багато роботи з даними, купа переліків для кожної сутності і т. д.
    Звісно, я вже маю досвід, знаю вузькі місця технології і вмію працювати з нею максимально ефективно.
    Можливо не все так добре, як хотілось би, але не все так погано, як багато хто каже.

  • Робочі фейли, помилки, факапи. Діліться 👻

    А що саме вони зробили не так?

    Підтримав: Kateryna Shneidmillier
  • Про купівлю яких ігор ви шкодуєте найбільше?

    Іграшки можна використовувати в парі

  • Кандидати, які пишуть Kiev замість Kyiv, хто ви?

    Туреччина має ресурси, щоб просувати свої рішення. А ми навіть міномети не можемо виробляти, а лише вміємо голосно кричати.

  • Кандидати, які пишуть Kiev замість Kyiv, хто ви?

    Оце проблема. Аж страшно.

    Підтримали: Pavel, mssant2
  • Серед розробників — лише 8% жінок, серед тестувальників — 36%. Скільки жінок в українському IT і які посади вони обіймають

    Який порох? Вже давно винуватий зе.

  • Component with Parameters. BlazorServer

    Були часи. Довелось попрацювати з blazor в 2019 році.

  • Мій досвід з MAUI. Створюємо діалог за допомогою Handlers

    Можливо, вам буде цікаво прочитати відповідь у сусідній темі
    dou.ua/...​3481/?from=fptech#2629139

    Підтримав: Alex Midnayt
  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою ContentView

    Тут люди це обговорюють. github.com/...​net/maui/discussions/8087
    Не схоже, щоб таке було в MAUI. Але MAUI для Windows використовує WinUI. А WinUI це така хитра надбудова над чимось ще, деталей вже не пам’ятаю. Якщо в цьому WinUI є RichTextBox, то ви зможете його використати в MAUI через Handler.

    Щось таки є. learn.microsoft.com/...​gn/controls/rich-edit-box

  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою ContentView

    Давайте спочатку.
    Кросплатформові додатки можна поділити на такі (можливо, в деяких прикладах я помилився, виправте, якщо не так):
    — ті, що використовують нативні компоненти (Xamarin/MAUI, React Native);
    — ті, що використовують власний рендерінг (Flutter, Avalonia);
    — гібридні — ті, що побудовані на WebView (PhoneGap, Ionic).
    У кожного підходу є свої плюси та мінуси. Думаю, ви самі про них знаєте. Але розглянемо кожний.

    Перший підхід.
    Плюси: майже нативна швидкість, можливість використання нативних функцій.
    Мінуси: потреба в створенні абстракцій над нативними компонентами та функціями.
    Саме цей мінус багатьох відлякує. Я не знаю, як у React Native, але вам може здатись, що в MAUI невеликий вибір компонентів. Це не зовсім так. MAUI містить в собі стільки компонентів, скільки розробникам Microsoft не було лінь загорнути в абстрактні компоненти. Наприклад, у CheckBox відсутній текст, бо для iOS потрібно було трішки щось доробити. Або відсутній якийсь компонент з material. І багатьох лякає, що потрібно щось доробляти, щоб створити якийсь крутий дизайн. Але тут немає нічого страшного. Бо MAUI це обгортка над нативною платформою. Якщо вам чогось не вистачає, ви маєте усі інструменти, щоб це додати. І тут, до речі, ви можете отримати навички роботи з нативною платформою, використовуючи C#. Це взагалі круто для .NET-розробників.
    Так, можливо, доведеться попрацювати над кастомізацією компонентів або над створенням нових, використовуючи нативні. Але такого коду у вас буде не більше 10%. Ви один раз напишете handler (або renderer у Xamarin) і будете це використовувати.

    Другий підхід.
    Плюси: власний рендерінг. Мінусів не знаю, бо не працював з такими технологіями.
    Так, власний рендерінг дає якусь гнучкість. Але фактично потрібно усі компоненти створити з нуля. Тобто, сіли розробники Google і почали створювати кожний компонент. Хтось казав, що у них і Material, і Cupertino з коробки підтримуються. Але це ж треба було комусь намалювати. Тобто тут питання не у тому, що якась технологія хороша, а якась погана. А питання в тому, скільки ресурсів було використано, щоб створити усі компоненти з нуля за допомогою графічної бібліотеки (як зробили в google) або щоб зробити обгортки над нативними компонентами (як зробили Microsoft). А якщо вам потрібний і не купертіно, і не матеріал, то знову доведеться щось своє малювати?

    Тобто, тут вже ви обираєте, що вам більше подобається. Мені, наприклад, не дуже подобається, як виглядає «верстка» в Dart. Але я не приходжу до Flutter-розробників і не кажу їм, що не бачу сенсу існування Flutter. Я так само міг би сказати, що Flutter це костиль, бо рендерить власним рушієм. Але я ж так не кажу, бо тоді усе можна буде назвати костилями.

    Третій підхід.
    Наскільки я розумію, він є трохи застарілим, бо всі намагаються від нього піти.
    Плюсами мабуть є використання html. Але мінуси — це важкодоступність нативних функцій.

    Отже, у кожного є свої плюси та мінуси. Звісно, що повністю нативні технології (Java, Kotlin, Objective C, Swift) швидші за кросплатформові. Але чи завжди нам потрібні переваги, які надають нативні технології? А якщо у нас звичайний інтернет-магазин або якийсь додаток для бізнесу зі звичайними переліками та формами, який не потребує ніякого особливого нативного функціоналу? А якщо у нас багато бізнес-логіки на клієнті? Це все доведеться писати на різних мовах, підтримувати. Тобто тут ми вже враховуємо не тільки наші вподобання, а також інфраструктуру нашої системи. Якщо у мене інфраструктура на .NET, то скільки усіляких моделей доведеться переписати на Kotlin та Swift або навіть на кросплатформовий Dart?

    Чесно кажучи я не розумію для яких потреб кса(за)марін ще використовується. Поясніть, будь ласка, дуже цікаво почути вашу думку.

    Підхід, що використовує Xamarin або MAUI не є поганим. Він просто інший. Кожний обирає технологію судячи із власних уподобань та інфраструктури власної системи.
    Саме тому я й пишу статті, щоб люди змогли побачити MAUI в реальній роботі.
    А Xamarin та MAUI використовувались мною для створення клієнтських додатків для облікової системи.
    P. S. Мені не хотілося б, щоб коментарі перетворювались у MAUI vs Flutter vs React Native, Java vs .NET, Android vs iOS та інші суперечки.

  • Мій досвід з MAUI. Створюємо прапорець з текстом за допомогою ContentView

    Костиль у чому? =)
    Чим тоді Flutter не костиль?

← Сtrl 123456...28 Ctrl →