Mondjuk a fiam kepevel.

In the last three days (or I should probably say evenings) I was working on an app for Android, specifically the part which logs in to my Google App Engine app with Client Login. It was an interesting journey, and I thought that other people may be able to learn from my mistakes, so here it is:

For GAE, Client Login works like this:
- Get the Auth string from “https://www.google.com/accounts/ClientLogin” with a post
- Using the Auth string, get the cookie from “http://myapp.appspot.com/_ah/login” using the abovementioned auth string as a get param, (and add a “continue” param too)
- Use the cookie for subsequent calls

When I tried the second part, I got this:

500 Server Error
Error: Server Error
The server encountered an error and could not complete your request.

If the problem persists, please report your problem and mention this error message and the query that caused it.

The solution:
Someone showed me this: SyncProxy.java

So I inlined the get parameters, like in the code above, or this:
HttpGet get = new HttpGet("http://yourapp.appspot.com/_ah/login?continue=" + URLEncoder.encode("http://yourapp.appspot.com/") + "&auth="+auth.substring(5));
(Where auth is the String from the first request, starting with: “Auth:”)
And it was working.

A few other possible pitfalls I’ve seen:
- If the first url is wrong (should be: https://www.google.com/accounts/ClientLogin) you will get cookies in the reply, a well known one is “PREF=ID=..”
- The information that you send in should be the body of the “post” call for the first request, and “get” parameters in the second.
- The Auth string from the first call comes back as content (in the body), not as header/cookie
- For the second call, it’s better to turn off redirect following
- You don’t need a CookieManager to capture the cookie. You can just look for “Set-Cookie” in the headers
- You can send the cookie as a “Cookie” header field, containing the same content.
- The expiry date of the cookie depends on your GAE app settings. The default is one day, you can change it to 1 or 2 weeks.

Az iPhone-Android háborúban mindeddig semleges voltam, ma azonban megjött a céges Desire (na jó, ez az én döntésem, választhattam volna iPhone-t is) úh. kvázi elköteleztem magam az Android mellett. Persze ez nem jelenti azt, hogy utálnám az iPhone-t. Épp ellenkezőleg, nagyon jó telefonnak tartom (bár még soha nem volt) és nagyon örülök, hogy oligopol piaci verseny van, mert az szerintem nagyon jót tesz a termékeknek, de a cégek se járnak rosszul.

Mindenesetre, neki fogok állni megtanulni az androidos fejlesztést.

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.