A Google kiadta az Androidhoz az App Inventort. A szoftver lenyege, hogy az alkalmazasodat nem “programozod”, hanem epitoelemekbol illeszted ossze. A reakciok meglehetosen vegyesek voltak, sokan amiatt aggodnak, h elarasztja az app store-t a gagyi, 12 evesek altal osszetakoltak kisalkalmazasok tomege, mig masok orultek a lehetosegnek.
A blokkokbol epitkezes nagyon regi otlet a szoftverfejlesztesben. Amikor 13 eve a foiskolan tanultam rola, mar akkor is tortenelmi multu gondolatnak szamitott, ambar akkor meg a gepek kepessegei joval alatta maradtak annak, amire ma kepesek, gondolok itt elsosorban a grafikus UI-ra. Azonban szamtalan okbol eddig mindig meghiusult az, hogy ebbol olyan termek legyen, amit nem programozok is kepesek hatekonyan hasznalni. En a palyam soran nemegyszer belefutottam ezekbe az alkalmazasokba, es nehanyat volt is szerencsem hasznalni munkam soran – ergo nem csak az otthoni kiprobalas jellegu jatszadozasok alapjan van tapasztalatom veluk. Az App Inventort meg nem probaltam ki, de ki fogom mindenkeppen. Egyelore csak az altalanos gondolataimat irom le, aztan ha lesz konkret tapasztalatom, akkor majd azt is.
A programozas alapallapotban ugy mukodik, hogy a programozo ismeri a nyelv alapveto konstrukcioit: ertekadas, felteteles elagazas, ciklus, stb. Ehhez hozzacsapodnak a keretrendszer elemek: Az objektumok, pl. a String, azok fuggvenyei. Az alkalmazas UI elemei is ilyenek. Ezekbol a programozo ossze tud rakni egy programreszletet, ami megcsinal valamit, amire neki szuksege van: pl. hatulrol elkezd bejarni egy listat, es osszeszed ot elemet, ami megfelel egy adott feltetelnek. Ezt egy atlagos felhasznalo azert nem tudja megtenni, mert nem ismeri az alapelemeket, nem ismeri a keretrendszer elemeket es nincs birtokaban a programozashoz szukseges gondolkozasi strukturaknak, azaz meg ha ismerne az elemeket, akkor sem tudna oket megfeleloen sorba tenni.
A vizualis kodepites egyik alapveto problemaja a kodgranualitas eltalalasa: A legegyszerubb epitoelemeket adjam oda a felhasznalonak, vagy valamivel bonyolultabbakat, vagy egeszen osszetett epitoelemeket, amiket csak konfiguralnia kell, vagy valami vegyesfelvagottat a fentiekbol? Mindegyiknek megvan a maga problemaja: Ha nagyon egyszeru elemeket adok, a felhasznalonak gyakorlatilag ugyanugy programoznia kell, csak nem gepelessel, hanem dobozokat osszehuzva. Raadasul igy mindent maganak kell megirnia. Ha csokkentem a granualitast, es haladok az osszetettebb elemek fele, akkor a usability-be futok bele: adok peldaul egy blokkot, amivel be lehet egy listat jarni, de akkor a felhasznalo azt akarja majd, hogy hatulrol elore, vagy csak minden masodikat, vagy eppen hatulrol elore minden masodikat… Ez hasonlo ahhoz a problemahoz, amibe belefutottam a MindGraph kapcsan mult heten, amikor egy apro valtoztatas miatt at kellett irni egy egesz osztalyt, csakhogy erre altalaban nincs lehetoseg. Persze megtehetjuk azt is, hogy csak egy blokkot adunk a felhasznalonak, amirol tudja, hogy ez egy ciklus, am a belsejet neki kell leprogramoznia scriptnyelven. Ezzel persze gyakorlatilag semmit nem haladtunk elore a sima programozashoz kepest, a felhasznalonak meg kell tanulnia, hogyan kell egy programot osszerakni. Ha egesz nagy blokkokat akarunk hasznalni, pl. “Beleptetes”, “Vasarlolista”, “Fizetes”, akkor abban a szituban leszunk, hogy barki ket perc alatt ossze tud rakni egy webshopot az elemeinkbol, de Solitaire-t soha nem fog csinalni vele. Persze megprobalhatunk mindenre adni egy ilyen blokkot, de ez kvazi lehetetlen. A hibrid megoldasok gyakran azt eredmenyezik, hogy mindket megoldas problemai megjelennek, am emellett meg az is jelentkezik, hogy tulzsufolt lesz az elemkeszlet. En pl. a Visio-val vagyok mindig igy: borzaszto jo tool lenne, ha tudnam, hol a feneben van az az elem, amit hasznalni szeretnek.. ha van egyaltalan.
A masik, egyaltalan nem megoldhatatlan feladat, amivel megis problema szokott lenni, az a kod ujrahasznalas. Ez reszben kapcsolodik a kod attekinthetosegehez is. Konnyu belatni, hogy egy alkalmazas diagramja nagyon osszetett lehet. Van benne egy udvozlokepernyo, ami pl a fomenu, egy “about” kepernyo, egy toltes kepernyo, ahol kivalaszthatjuk, hogy melyik mentett dokumentumunkat akarjuk megnyitni, egy hasonlo a menteshez, plusz az osszes koztes kepernyo. Ha mar csak azt felrajzoljuk, hogy melyik kepernyorol melyikre lehet eljutni es milyen modon (ha van aktualisan szerkesztett dokumentum, akkor load elott ajanlja fel a mentest..) mar az onmagaban atlathatatlan. Azonban mi most arrol is beszelunk, hogy a kepernyon beluli kodot is vizualisan megalkotjuk.
Nyilvanvalo a megoldas, hogy akkor a kepernyokhoz csatlakozo kodokat szeparaljuk el kulon, csak adott kepernyonel lathato diagramra. Am itt jon a kepbe a scope: Mi van akkor, ha a kod egy resze olyan logikat valosit meg, amit szeretnek ujrahasznositani? Atnyulhatok az egyik kepernyorol a masikba? Vagy kirakhatom egy kulonallo valamibe, ami nem kepernyo? De egyaltalan, hogyan azonositom, hogy en oda akarok most menni, ezzel-es-ezzel az adattal, es utana ide akarok visszajonni? Egy mondatban: hogyan rajzolok publikus fuggvenyeket es hogyan hivom meg oket?
A megoldas itt nyilvan az lenne, hogy ezek az altalam irt publikus fuggvenyek is uj epitoelemkent jelennek meg, valamint az alkalmazasom elszeparalt reszei (kepernyok) is megjelennek epitoelemekkent – pontosabban azon reszeik, amiket publikusan kiajanlok. Innen persze a felhasznalonak ertenie kell a scope kifejezest is.
A scope kapcsan nyilvan megemlithetnem itt a valtozok atadasat is: hogy oldom meg azt, hogy a kepernyom at tudjon passzolni ertekeket a kovetkezo kepernyonek, aki aztan majd felhasznalja? Valamint pl. hogy oldom meg azt, hogy ha a felhasznalo a vissza gombot nyomja meg, ki legyen toltve a form, mig ha a tovabbi elemek hozzaadasa akciot valasztotta, akkor ne? Ezek mind olyan kerdesek es problemak, amivel egy vizualis tervezo keszitesenel talalkozunk, es a megoldasra olyasmit kell kitalalnunk, amivel a programozni nem tudo, alapvetoen egeret hasznalo felhasznalo boldogul, es amitol nem lesz olyan erzese, hogy ez most rocket science.
Gyakorlo programozokent az az erzesem, hogy a programozasnak ez az aga vagy zsakutca, vagy egy olyannyira limitalt lehetoseg, amivel nincs ertelme foglalkozni addig, amig nincsenek mesterseges intelligenciak, akik az egyszeru abra moge, amit te lerajzolsz, kepesek maguktol kitalalni a tartalmat. Maskulonben, akarmilyen jo is az eszkozunk, elobb-utobb vagy olyan problemaba fut bele a felhasznalo, amit nem lehet benne megoldani, vagy programoznia kell.
Tovabbiakat majd akkor, ha kiprobaltam az App Inventort.
