Swing'dan JCEF'ga

1. Loyihani asoslash

Maro moti plagini IntelliJ muhitida Beat deb nomlangan ekran birliklarini avtomatik ravishda yaratadigan mahsuldorlik vositasi sifatida ishlab chiqilgan.

Ushbu plagin takroriy ravishda yaratilishi kerak bo'lgan ekran tuzilmasi va maydon joylashuvini avtomatlashtirish orqali dasturchilarning samaradorligini oshirishni maqsad qilgan edi.

Foydalanuvchi CreateBeatAction ni ishga tushirgandan so'ng, dialog orqali ekran tuzilmasini belgilaydi va har bir bo'limga kerakli maydonlarni joylashtirib, oxir oqibat kodni yaratadi.

Dastlabki versiyada bu oqimni Java Swing asosidagi ikkita dialogga bo'lib ishlamoqda.

Birinchi dialogda ekran bo'limi tuzilishini aniqladik, ikkinchi dialogda esa haqiqiy maydon joylashuvi va xaritalash jarayoni olib borildi.

Dastlab oddiy tuzilma bo'lganligi sababli katta muammo deyilgande, haqiqiy foydalanish chastotasi oshgan sari bir qator UX muammolari paydo bo'la boshladi.

Ayniqsa foydalanuvchilar ikkita dialog bo'ylab takroran yurishlari va holatni eslab qolishlari kerak edi, oldingi sozlashlarni yana bir bor tekshirish uchun avvalgi bosqichga qaytish talab etilgan hollarda ko'p bo'ldi.

Shuningdek, Swing asosidagi wireframing UI haqiqiy ekran bilan katta farq qiladi, bu esa foydalanuvchilar uchun yakuniy natijalarni intuitiv ravishda taxmin qilishni qiyinlashtiradi.

Loyihaning kengayishi bilan tortish va tashlash, murakkab tartib tuzish strukturalari, real vaqtda oldindan ko'rish funksiyalari kabi talablar ham oshdi.

Lekin Swing asosidagi tuzilishda bunday funktsiyalarni amalga oshirish uchun ko'p tadbir kodlari va holat boshqaruvi mantiqi kerak edi va saqlash xarajatlari ham tezda oshib borishga boshladi.

Nihoyat, oddiy UI yaxshilanish darajasidan, arxitekturani o'zgartirish zarurligiga kelib, bunda IntelliJ tomonidan taqdim etilgan JCEF (Java Chromium Embedded Framework) dan foydalangan holda veb asosidagi tuzilma o'zgarishini amalga oshirishga kirishdik.

2. Mavjud tuzilmaning muammolari

Mavjud tuzilmadagi eng katta muammo foydalanuvchi oqimining bir necha bosqichga ajralganligi edi.

[мавжуд экран]

Фойдаланувчилар аввал бўлим структурасини тўғрилашлари керак эди, кейин эса кейинги диалогга ўтиб, майдонларни жойлаштиришлари керак эди.

Ushbu jarayonda avvalgi sozlamalarni eslab qolishimiz kerak edi va kerak bo'lganda oldingi dialogga qaytishimiz kerak edi.

Xususan, murakkab ekran tuzilishini boshqarishda foydalanuvchilar bo'limlar va maydonlarni takroran taqqoslashlari kerak edi va butun ekran tuzilishini bir marta o'zlashtirib olish qiyin edi.

Bu foydalanuvchining charchoqligini oshirdi va sozlash jarayonini qiyinlashtirdi.

Ikkinchi muammo - Swing asosidagi simsiz interfeysning cheklovlari edi.

Mavjud UI BoxLayout asosida sodda tarzda tuzilgan edi va haqiqiy xizmat UI bilan vizual farq katta edi.

Masalan, haqiqiy komponentlar turli xil uslub va joylashtirish tuzilmalarga ega bo'lsa-da, Swing asosidagi wireframe faqat oddiy quti shaklida ifodalangan.

Buning natijasida foydalanuvchilar oxirgi natijani intuitiv ravishda tushunishda qiynaldilar va natijalarni yaratganda ko'pincha qayta o'zgartirishlari kerak edi.

Uchinchi muammo kengaytirilishi edi.

Loyihalar kengaygani sari quyidagi funktsional talablar doimiy ravishda ortib bordi.

• Maydonni sudrab olib tashlash

• Ichki tuzilmalar

• Real vaqt rejimida renderlash

• Maydon tartibini o'zgartirish

• Reaktiv ko'rish

• Turli komponentlarni qo'llab-quvvatlash

Ammo Swing muhitida bunday funksiyalarni amalga oshirish uchun ko'p hodisa ishlov berish kodi va holatni boshqarish kodi kerak edi.

Xususan, komponentlar o'rtasida holatni sinxronlashtirish murakkablashgan sari, texnik xizmat ko'rsatish qiyinlashdi.

UI ni o'zgartirish jarayonida ham muammolar yuzaga keldi.

Tizim tuzilishi murakkablaşgani sayin, birgina o'zgartirish uchun bir nechta hodisa mantiqlarini birga o'zgartirishga to'g'ri keldi va kutilmagan yon ta'sirlar tez-tez paydo bo'ldi.

Nihoyat, funksiyalarni kengaytirish tezligi saqlash xarajatlarining oshish tezligidan oshib ketdi va yangi Foydalanuvchi interfeysi arxitekturasini joriy etish zaruriyati yanada oshdi.

3. JCEF asosidagi tuzilma o'zgarishi

Yangi tuzilma IntelliJ tomonidan taqdim etilgan JCEF (Java Chromium Embedded Framework) imkoniyatlaridan faol foydalanishni ta'minladi.

JCEF, IntelliJ ichida Chromium brauzerini joylash imkonini beruvchi funktsiya bo'lib, plagin ichida ham deyarli veb ilovalarini ishga tushirishga imkon beradi.

Buni foydalanib, mavjud Swing asosidagi dialoglarni React asosidagi veb ilovasiga aylantirdik.

Yangi tuzilishda JBCefBrowser orqali brauzerni ochish va unda alohida ishlab chiqilgan vui-editor React ilovasini ishga tushirishga mo'ljallangan.

Bu tuzilishning eng katta foydasi UI rivojlantirish usulini butunlay veb old tomoni uslubiga olib kelish imkoniyatidir.

Mavjud Swing-da to'g'ridan-to'g'ri amalga oshirilishi kerak bo'lgan turli interaktsiyalarni React va frontend kutubxonalaridan foydalangan holda ancha samarali amalga oshirish imkoniyati paydo bo'ldi.

Shuningdek, komponentlarga asoslangan dasturlash tuzilishini qo'llash imkoniyati yaratilgach, qayta ishlatish va texnik xizmat ko'rsatish qobiliyati ham sezilarli darajada oshdi.

Xususan, holatga asoslangan rendering tuzilmasini qo'llash davomida UI holat boshqaruvi ancha intuitiv tarzda o'zgardi.

Oldin voqeaga asoslangan holda bir nechta komponent holatlarini qo'lda sinxronlashtirish kerak edi, lekin React asosidagi tuzilishda holat o'zgarishi bilan ekran avtomatik ravishda yangilanadigan tarzda tashkil etilishi mumkin edi.

Yangi tuzilmada quyidagi maqsadlarga erishishni ko'zlagandik.

• Yagona dialog asosidagi UX taqdim etish

• Real vaqtda oldindan ko'rish qo'llab-quvvatlanadi

• Boy interaktiv tajriba taqdim etiladi

• Oldin ishlab chiqarish samaradorligini oshirish

• Kelajakda funktsiya kengaytirilishini ta'minlash

• Veb texnologiyalari asosida texnik xizmat ko'rsatish tizimini yaratish

Bunday tuzilma o'tishi oddiy UI o'zgartirish ishlariga emas, balki IntelliJ plaginining UI arxitekturasini qayta loyihalash ishiga yaqin edi.

4. Java va JavaScript o'rtasidagi aloqa

JCEF asosidagi tuzilishga o'tayotganda birinchi hal qilinishi kerak bo'lgan muammo Java va JavaScript o'rtasida ma'lumot almashish edi.

Plagin ichida allaqachon Java ob'ekt ko'rinishida boshqarilayotgan ComponentElement, DataModel, maydonlar ro'yxati kabi ma'lumotlar mavjud edi.

Ushbu ma'lumotlarni React dasturining boshlang'ich holati sifatida uzatishimiz kerak edi va aksincha, foydalanuvchi tahrirlangan natijalarni yana Java tomoniga uzatish strukturasiga ham ehtiyoj bor edi.

Dastlabki ma'lumotlarni evaluateJavaScript() yordamida amalga oshirdim.

Dialog yuklangandan so'ng window.initEditor() funksiyasini chaqirib, JSON shaklida ma'lumotlarni React ilovasi uchun taqdim etdim.

React ilovasida olingan ma'lumotlar asosida dastlabki holatni tuzish va ekrani chizish uchun mo'ljallangan.

Aksincha, saqlash so'rovi window.cefQuery() dan foydalangan holda amalga oshirildi.

Foydalanuvchi saqlash tugmasini bosganda, React dasturi hozirgi holatini JSON shaklida uzatadi va Java tomonidan JBCefJSQuery ishlovchisi buni qabul qilib, ichki holatini yangilash uchun tuzilgan.

Ishlab chiqish jarayonida bir qancha vaqt masalalari ham yuzaga keldi.

Oʻziga xos ravishda brauzer toʻliq yuklanmaganidan oldin initEditor() chaqirilganda JavaScript funksiyasi hali tayyor boʻlmaganligi sababli, dastlabki yuklashda muvaffaqiyatsizlikka uchraydi.

Buni hal qilish uchun DOM yuklash tugagandan keyin faqat dastlabki ma'lumotlarni kiritish uchun o'zgartirildi.

Shuningdek, saqlash callback'ida CountDownLatch'dan foydalanib, ma'lum vaqt davomida javob kutish uchun tuzildi va eng ko'pi bilan 2 soniyadan keyin timeout ishlashiga mo'ljallangan.

Ushbu jarayonda istisno bilan ishlash va brauzer holatini tekshirish logikasini ham qo'shdik, bu esa barqarorlikni oshirdi.

5. Paketlash va CORS muammolarini hal qilish

JCEF asosidagi tuzilmada kutganimizdan ko'ra qiyinroq bo'lgan jihlardan biri bu tarqatish muhitidir.

React ilovasi qurilishdan so'ng statik resurslar shaklida yaratiladi va oxir-oqibat IntelliJ plagini JAR ichida joylashtiriladi.

Muammo shundaki, JCEF da file:// protokoli asosida React ilovasini yuklayotganda brauzerning CORS siyosati tufayli ba'zi funksiyalar to'g'ri ishlamaydi.

Asosan fetch API chaqiruvi yoki dinamik resurslarni yuklash jarayonida to'siq muammolari yuzaga keldi.

Dastlab, oddiygina mahalliy fayllarni to'g'ridan-to'g'ri yuklash yo'li bilan yondashildi, ammo haqiqiy ishchi muhitda turli xil cheklovlar yuzaga keldi.

Buni hal qilish uchun JAR ichidagi resurslarni vaqtincha katalogga chiqarib, oddiy mahalliy HTTP serverini ishga tushirib, localhost asosida resurslarni taqdim etish tuzilmasini o'zgartirdim.

HTTP serverini yaratishda com.sun.net.httpserver.HttpServer dan foydalandim.

Brauzer nuqtai nazaridan oddiy HTTP so'rov muhitida qabul qilindi va natijada CORS muammosini hal qilish imkoniyati yaratildi.

Shuningdek, rivojlantirish muhitida Vite rivojlantirish serveri (localhost:5173) bilan to'g'ridan-to'g'ri bog'lanib ishlash imkoniyati yaratilgan.

Bu orqali Hot Reload muhitidan to'liq foydalanish mumkin bo'ldi va frontend dasturchilik samaradorligi sezilarli darajada oshdi.

Xususan, UI o'zgartirishlari paytida IntelliJ plaginini qayta qurmasdan darhol o'zgarishlarni ko'rishni mumkin bo'lganligi sababli takroriy rivojlanish tezligi juda tezlashdi.

Natijada ishlab chiqish muhitini va ishlash muhitini barqaror qurish mumkin bo'ldi, web asosidagi UI ishlab chiqish tajribasini IntelliJ plaginlari ichida tabiiy ravishda qo'llay olish imkoniyatiga ega bo'ldik.

6. Natijalar va yaxshilash ta'siri

JCEF asosidagi tuzilmaga o'tgandan keyin eng katta yaxshilangan qism foydalanuvchi tajribasi bo'ldi.

[Yangi ekran]

Avvalgi ikki bosqichda ajratilgan oqim hozirda bitta dialog ichiga birlashtirildi va foydalanuvchilar to'liq ekran tuzilmasi va maydon tuzilmasini bir vaqtning o'zida ko'rishlari mumkin.

Endi foydalanuvchilar quyidagi harakatlarni bitta ekranda amalga oshira oladilar.

• Bo'lim tuzilishini yaratish

• Maydon joylashuvi

• Tartibni o'zgartirish

• Drag and drop

• Real vaqt ko'rinishi

• Tashqi ko'rinishni tekshirish

Xususan, real vaqtlarda render qilish imkoniyati tufayli foydalanuvchilar hozirda tahrir qilayotgan ekran natijasini darhol ko'rish imkoniyatiga ega bo'lishdi va yakuniy natijani oldindan taxmin qilish ham ancha osonlashdi.

UI/UX jihatidan ham katta yaxshilanishlar amalga oshirildi.

React asosidagi tuzilishga o'tish orqali turli front-end kutubxonalarini va holatni boshqarish naqshlarini ishlatish imkoniga ega bo'ldik, animatsiya va interaktsiyalarni o'rnatish juda tabiiy bo'ldi.

Rivojlanish tashkiloti jihatidan ham ijobiy o'zgarishlar bo'ldi.

Avval UI o'zgartirishlar IntelliJ plagin kodining ichida amalga oshirilishi kerak edi, ammo endi front-end va back-end ishlarini bir-biridan mustaqil ravishda ajratish mumkin bo'ldi.

Front-end dasturchilari React ilovasiga diqqatini qaratib ishlay olishdi va plagin ishlab chiquvchilari Java asosidagi biznes mantiqiga diqqatini qaratishdi.

Sizning yordamingiz bilan ikkita dasturchi parallel ravishda ishlay olishdi va dastur ishlab chiqish tezligi hamda texnik xizmat ko‘rsatish samaradorligi sezilarli darajada oshdi.

Ushbu loyiha orqali IntelliJ plaginlarini ishlab chiqishda veb texnologiyalaridan faol foydalanish mumkinligini tasdiqlay oldim.

Ayniqsa murakkab o'zaro ta'sirlar va boy foydalanuvchi tajribasini talab qiladigan vosita bo'lsa, JCEF asosidagi tuzilma juda samarali tanlov bo'lishi mumkinligini his qildim.

DEVKC