Згадав анекдот від Максима Залізняка.
— Скажите, как вы стали миллионером?
— Купил молока, сварил головку сыра, продал. На вырученные деньги купил больше молока, сварил 5 головок сыра, продал.
— А потом сварили 10 головок сыра?
— Нет, умерла бабушка еврейка и оставила наследство.
=)
На минулому проекті я використовував ZXing для MAUI. В основному для сканування штрих-кодів, тому що це був проект складського обліку. Іноді доводилось і показувати штрих-коди. ZXing дуже добре сканував, але відображення штрих-кодів на той момент було не дуже стабільним. Іноді падав на спробі намалювати якийсь штрих-код (з правильною контрольною сумою).
Якщо не секрет, як ви малютєте штрих-коди? Skia чи щось нативне?
До речі, ваша бібліотека платна? Я щось не побачив ціни.
Для чекбокса багато коду не треба. Його взагалі не треба. Але стандартний чекбокс не має тексту. Тому доводиться додавати Label поруч з чекбоксом. Щоб не робити цю нудну роботу, можна інкапсулювати Label і чекбокс в один компонент. І можна зробити це двома шляхами.
Перший (повністю кросплатформовий) описується в попередній статті dou.ua/forums/topic/43481
Другий (через нативні компоненти) описується в цій статті.
Як я написав нижче, наступного разу спробую більш чітко формулювати цілі статті.
Дякую за відгук.
Моє недоопрацювання. Схоже, потрібно краще пояснювати цілі статті.
Ого, невже суспільство здатне так швидко деградувати, що за найкоротший час забуло «болгарську»-російську?
До речі, андроїд така зараза, що поки існує людство, то існуватиме і андроїд =)
Зараз це зручна, гарна, стабільна операційна система.
Ну і приємно побачити у відео адекватного розробника, який визнає, що і для кросплатформових технологія є своя ніша. Бо є такі, що визнають лише нативну розробку, а все інше зневажають.
Зараз я займаюсь backend розробкою. Рік тому ще працював над мобільними додатками. Складно сказати, що складніше, а що простіше.
З одного боку, backend може здаватись складнішим через міжсервісну взаємодію, вимоги до архітектури, роботу з базою даних, pooling, черги і т. д.
А з іншого, в більшості випадків backend має рівний послідовний код, усілякі перевірки з викиданням виключень, і доволі нечасте використання багатопотоковості. Часто (звісно, не завжди) відсутні якісь підводні камені, усе рівно і просто: прийшов запит, обробив логіку у відповідності до бізнес-вимог, віддав відповідь.
Багато хто думає, що якщо мобільний додаток є різновидом фронтенду, то там все просто: роби, що хочеш, малюй, що хочеш, і все працює. Скажу одразу: фронтенд і мобільна розробка мають безліч підводних каменів.
По-перше, різні пристрої різних виробників з різними розмірами екранів, з різними версіями операційної системи можуть викидати власних коників. А ще користувач може увімкнути збільшені шрифти і гарненький додаток перестане бути таким.
По-друге, якщо додаток насичений багатим функціоналом, то цей функціонал потрібно гармонійно представити в інтерфейсі. Це одне з найскладніших завдань: зробити інтуїтивний інтерфейс при великій кількості функцій. Навіть якщо на проекті є дизайнер і він гарно намалює інтерфейс, то все одно стикнешся з тим, що один елемент конфліктує з іншим, десь може бути просадка швидкодії, бо дизайнер може не знати тонкощів роботи мобільних додатків; десь він не зрозуміє бізнес аналітика і зробить щось не так, як задумано, щоб користуватись додатком; десь потрібно буде навіть пояснити йому ієрархію сутностей і т. д. Тому коли на проекті є дизайнер, це, звісно, допомагає, але розробник має бути готовий до безлічі нюансів.
По-третє, користувачі доволі нетерплячі і багато чого їм здається повільним, коли воно таким не є. Завжди потрібно слідкувати за плавністю. Тут асинхронна розробка і багатопотоковість стають на перше місце. Іноді, якщо дані завантажуються надто швидко, користувачу може здатись, що додаток різкий і тормозить. Навіть доводиться штучно вставляти асинхронні затримки, щоб викликати у користувача відчуття плавності.
По-четверте, є ще кросплатформова розробка зі своїми нюансами, які мені лінь розписувати.
Ну і звісно є ще окремий світ зі своїми тараканами — фронтенд (веб).
Але іноді я сумую за мобільною розробкою, тому ще цю роботу можна побачити і доторкнутись до неї. А результат роботи з бекендом видно хіба що у сваггері =)
Коли ти власноруч малюєш інтерфейс і розробляєш його, це приносить більше задоволення, аніж розробка бекенду, який є невидимим для більшості користувачів.
Вже чотири місяці як на гіг-контракті. В порівнянні з фопом нічого не змінилось, окрім ведення звітності.
Звісно, вигадати гіг-контракти замість однакових справедливих умов для всіх це в стилі нашої держави. Але поки що умови не гірші за ФОП.
Усіляких пунктів про неконкуренцію у мене в договорі немає. Я здивувався, що хтось в статті погодився на це. Я вважаю, що адекватна компанія не має включати такі пункти у свій договір. Поки що це єдиний мінус, який може бути в гіг-контракті. Хоча таке можуть спробувати всунути в якийсь NDA для ФОПу. Але в будь-якому разі я сподіваюсь, що чим більше людей будуть від таких пунктів про неконкуренцію відмовлятись, то менше компаній це будуть у включати в договір.
Microsoft та MAUI є в чому критикувати.
Але я за два місяці зробив мінімальну робочу версію мобільного клієнтського додатку облікової системи. Там багато сторінок (екранів), багато роботи з даними, купа переліків для кожної сутності і т. д.
Звісно, я вже маю досвід, знаю вузькі місця технології і вмію працювати з нею максимально ефективно.
Можливо не все так добре, як хотілось би, але не все так погано, як багато хто каже.
Іграшки можна використовувати в парі
Туреччина має ресурси, щоб просувати свої рішення. А ми навіть міномети не можемо виробляти, а лише вміємо голосно кричати.
Який порох? Вже давно винуватий зе.
Були часи. Довелось попрацювати з blazor в 2019 році.
Можливо, вам буде цікаво прочитати відповідь у сусідній темі
dou.ua/...3481/?from=fptech#2629139
Тут люди це обговорюють. github.com/...net/maui/discussions/8087
Не схоже, щоб таке було в MAUI. Але MAUI для Windows використовує WinUI. А WinUI це така хитра надбудова над чимось ще, деталей вже не пам’ятаю. Якщо в цьому WinUI є RichTextBox, то ви зможете його використати в MAUI через Handler.
Щось таки є. learn.microsoft.com/...gn/controls/rich-edit-box
Давайте спочатку.
Кросплатформові додатки можна поділити на такі (можливо, в деяких прикладах я помилився, виправте, якщо не так):
— ті, що використовують нативні компоненти (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 та інші суперечки.
Костиль у чому? =)
Чим тоді Flutter не костиль?
Коли ви останній раз користувались андроїдом? Тільки нормальним, а не за 5000 грн.
Я не пам’ятаю, коли востаннє бачив баг в андроїді. А от півроку назад бачив, як айфон завис, коли встановлював додаток. Або коли під час першого налаштування з коробки два рази кидав на першу сторінку.