_duck.ai

Щоб можна було хоч більш менш користуватись застосунком, не вистачало однієї дрібниці. Так ще багагато чого потрібно перебрати, перевірити на фунеціональність, може десь покращити чи поправити інтуїтивність інтерфейсу. Проте для звичайного створення допису, щоб це було доступно із будь якої платформи, точніше із найбільш розповсюджених, шлях до яких лежить через вебзастосунок. Тому однією деталькою, це була поведінка із віртуальної клавіатурою. Мобільні пристрої її мають, а взаємодіє застосунку із нею має бути правильною. І вельми зручно, коли віджет знаходиться наде нею, щоб форматування було максимальо комфортне. Але він все не слухався як слід, а у процесі виявилось що основний файл App.tsx розрісся до розміру 13000+ рядків коду. ШІ моделі то назвичайно тяжно обробляти кожного разу і якось вона просто почала збоїти, бо частина почала просто затиратись того коду чи втрачатись у процесі стиснення. Тож спочатку довелсь перейти до рефакторингу. В результаті App.tsx схуд до 1500+ рядків коду, хоча й залишилось ще декілька сотень рядків коду, які можна теж перемістити в окремі невеличкі хуки, компоненти та інші складові. В ході довелось теж щось підправляти, проте розробка має бути тепер легшою.

_{neon style}

І в результаті. Ніби це було стояння на місті, якщо дивитись на функції чи ще шось, проте. На даний проміжний момент, це дало більше продуктивності для андроїд застосунку. Бо раніше він шось підвисав при вставці 2-3 тисяч слів і дуже довгенько подумував, а зараз швидше шевелиться. Й можна навіть із синхронізацією, більше менш комфортно набрати тексту до 10000 слів, що ніхто робити не буде. Тож для середніх 300-400 слів, цього має бути із запасом. І поведінка там для набору тепер більш менш прийнятна.

Отже основним викликом є поведінка застосунку, у різних мобільних браузерах, якщо просто відкрити сторінку редактора із інтернету. Бо, як вивилось є деякі нюанси.

Наприклад, браузер Waterfox на базі мозіли, має специфічно панель, бо із Chrome від гугл працює файно, в плані позиціонування.

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

Прогалина між нижньою панеллю й ардесним баром	Віджет перекрито адресною панеллю.	Адресний рядок вгорі, але маємо прогалину	Але, коли адресний рядок вгорі, то віджет видно добре.

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

Навіть є презнтаційне лого на старті	+	+	+

Тож PWA майже нічим не відрізняється від окремого застосунку на андроїд, якого ще немає в Плей Маркеті, тож це мабуть найбезпечніший спосіб мати такий застосунок у себе, щоб писати дописи й публікувати на блокчейні STEEM. При цьому доступно й для IOS, Windows, Linux та ще якихось платформ завдяки лише одному браузеру. А там у браузері теж своя система безпеки є. Якщо порівнювати із встановленням застосунка із стороннії джерел.

✍️	✍️	✍️

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

Міні галерея

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

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

Маленький підсумок

Із цього виходить, що найкращий і простіший спосіб, особливо із точки безпеки, це просто встановити собі PWA у веббраузері. Це зрунчо, особилво із ПК, бо тоді точно достунпне розширення Кейчейну, тоді взагалі до застосунку свій ключ не вводиться, хоч він лише й для постингу, тобто фінансовий ключ тут взагалі ніяким боком не використовується. Хіба можуть бути деякі обмеження на збереження величезних текстів саме у пам'яті браузера, але вони легко імпортуються як окремі .md файли так і пакетно в одному архіві. Найпідстуніший аспект у цьому, хіба очищення кешу браузера, тоді можуть стертись не експортовані на локальний диск записи. І важливий нюас для цього.

Щодо інших контейнерів, в які може бути запакований вебзастосунок, то там не дуже то й багато методів щоб розповсюдити його. Із простіших, це fdroid для андроїд, флетпак для лінукс та маркет для відновс. Скрізь є додаткова перевірка безпеки перед додавання, що трішки покращує ситуацію, в порівнянні із розміщенням просто в репозиторії ГітХабу. Щодо маркету для віндовс. То там є одна цікава особливість, якщо застосунок не додавати у загальний маркет, то не потрібно реєструвати обліковий запис і платити одноразовий збір у два-три десятка доларів. А можна просто подати його через той же гітхаб, де робиться перевірка на віруси та ще шось і додається той застосунок до маркету віндовс, але із поправкою. Встановити його можна буде лише через командний рядочок, а не через загальнодоступний Winwows Store, де вільний застосунок можна знайти в пошуку й кліком мишки встановити на ПК.

Десктопні застосунки

Щодо застосунків для ПК, то наразі помічено навіть деяке зниження продуктивності для великих текстів. Перевірені Neirolino (чи якось так) та AppImge (by Tauri) на Лінукс. Тобто цілком запасу вистачає на 10000+ слів чистого тексту, навіть 20тис. І того мало хто буде писати, але таки помічено. Версія 3.5.8 видавала більше продуктивності. При тому, що прецес впирається не скільки у потужності CPU & GPU, як у якісь внутрішні організаційні процеси. Може перевантаження потоку чи ще чогось. Може то особливості взаємодії із двигуном WebKit, бо у веб браузері продуктивність дещо вища. Хоча якщо порівнювати той же Obsidian теж при 20тис слві починає дещо приторможувать, принаймні та версія що в мене є у формі AppImage. Тобто такого розміру файли одним махом редагувати чи писати немає великої необхідності чи технічної змоги проводити по ньому ефективну й зручну навігацію.

Загальний підсумок

Редактор робочий, працює й цільове завдання він собі спокійно виконує. Навіть згідно освновного плану все додано. Тільки з тією поправкою, аби все ще перевірити, поправити де потрібно, допрацювати. Щось зробити зручнішим, чи узгодити певні дії функціоналу, як-то поведінка галереї, якщо змінювати розмір вікна на ПК. Чи подекуди перевірити правала ковертації html у markdawn, бо трапляються деякі баги після рефакторингу. Тобто загалом. основна частина зроблена.

_{p.s. І хороша та штука резервного атозбереження. Бо пишу собі цей допис, клацаю комбінації клавіш, згадую яка там щоб у браузері відкрились функції розробки для симуляції перегляду сторінки ніби це мобільний пристрій, і раптом натрапляю на такі, що наглуго вирубають ОС ПК, лие крапочка мигає. Перезавантаження і текс цілий і можна писати далі.}

Сс:
@hungry-griffin
@steemcurator01

Дякую за підтримку))