Archive for április, 2009

Promo kép használata

Szerző:
devblogger
- 2009-04-21
Kategóriák: Gyorstalpaló Tudnivalók
. 4 megjegyzés

Az éles indulás után az Alkalmazások főmenü alatt elérhető katalógus nyitólapon szeretnénk az alkalmazásokat promotálni, illetve rotálni a legelső, kiemelt helyen. Ahhoz, hogy ott esztétikusan  legyen látható az alkalmazás, nem a thumbnail fog megjelenni az alkalmazás neve mellett, hanem az un. promo kép.

promokep

Kérjük készítsetek ilyet is az alkalmazásokhoz, és rakjátok fel a szerveretekre, mert nem tudhatjátok, hogy mikor kerül épp kiemelésre a ti munkátok.

A promo kép definiálásáról a Wiki-ben olvashattok a Gadget XML megkötések cikk alatt, de röviden itt is megismételjük, mivel picit trükkös a dolog: nem az XML-ben kell definiálni explicit módon, “csak” léteznie kell a képnek.

promó kép* 176x(max)176 kiemelt alkalmazás promóképe
  • alkalmazás lista elején a kiemelt alkalmazásokon

* A promó kép URLjét a rendszer az alkalmazás thumbnail URL-ből képezi:

  • ha az url utolsó / utáni része tartalmaz .-ot, az utolsó . elé illeszti a ‘_promo’ karaktereket
  • ha nem, az url vége után illetszti a ‘_promo’ karaktereket
  • pl: 
    http://foo.com/bar/baz.png -> http://foo.com/bar/baz_promo.png
    http://foo.com/bar/baz -> http://foo.com/bar/baz_promo

Alkalmazások élesítése az iwiw.hu alatt

Szerző:
devblogger
- 2009-04-17
Kategóriák: Fejlesztés, Haladó szint, Hírek Tudnivalók
. 8 megjegyzés

Zajlik a jóváhagyási folyamat, és napokon belül kiküldjük visszajelzéseinket a beküldött alkalmazásokkal kapcsolatosan. Sok alkalmazásnál csak kisebb formai vagy technikai problémák vannak csak, ezek gyors kijavítására számítunk. Az egyes feladatokról e-mailt küldünk.

A következő lépés innen már az alkalmazás élesbe állása, az iwiw.hu alatti megjelenése lesz, az ezirányú teendőiteket gyűjtöttük össze.

Az alkalmazás jóváhagyásáról egy emailt fog kiküldeni a rendszer, de ez nem jelenti az alkalmazás élesbe állását is - ezt a fejlesztő tudja megtenni az alkalmazás Aktív állapotba állításával. Ezt a Fejlesztői Portálon az alkalmazás Vezérlőpult menüpontja alatt éritek majd el.

Amint megkaptátok a formális értesítést a jóváhagyásól, kérjük ellenőrizzétek a következőket:

  • az alkalmazás tesztadatai, a Homokozóban felvitt információk törölve vannak
  • ha az alkalmazás igényli, fel van töltve kezdeti adatokkal, információkkal (pl. a cserebogarak különböző fajtáit bemutató alkalmazás legalább két-három cserebogarat bemutat)
  • az alkalmazás külön kezeli a Homokozót és az éles rendszert, elkülöníti az adatokat. A Homokozó és az éles rendszer mind a JavaScript kódban, mind a szerver oldalon elkülöníthetőek egymástól. JavaScriptből az opensocial.getEnvironment().getDomain() függvényhívás adja vissza az éppen aktuális domaint, míg szerver oldalon a signed requestek segítségével, a kérés során átadott oauth_consumer_key paraméter ellenőrzésével dönthető el, hogy honnan érkezett a kérés.
  • a nem élesbe szánt fejlesztéseket egy külön kódon végzitek, ugyanis amint lejár a cache ideje, vagy amikor frissítitek az alkalmazást a Homokozón, a legfrissebb kód fog megjelenni élesben is

A visszajelzésünk kiküldése után nem lesz sok időd, hamarosan indulunk! Várhatóan április 22-én, szerda reggel állnak élesbe az alkalmazások.

Új terminológia: “történések” helyett “hírek”

Szerző:
devblogger
- 2009-04-15
Kategóriák: Fejlesztés, Hírek Tudnivalók
. 2 megjegyzés

Egy terminológiai változásról szeretnénk hírt adni: az eddigi “történések” kifejezést a felhasználók számára talán érthetőbb “hírek” kifejezésre fogjuk cserélni a közeljövőben. Ez igazából csak pár szöveg átírását jelenti a Homokozóban, de itt a blogon, és a wikiben is már “hírek”-ként fogunk hivatkozni az opensocial.requestCreateActivity függvény segítségével előálló tartalomra.

Döntésünk nem hoz azonnali változásokat a blogban és a wikiben, de igyekszünk mihamarabb átállni mi is a friss kifejezésre, s a jövőbeni blogbejegyzésekben, illetve a wikiben már az új nevet használni. Ha az alkalmazásotokban hivatkoztok erre a lehetőségre (például annak FAQ-jában), akkor javasoljuk, hogy írjátok át a szövegeiteket az új formára.

Linkek a történésekben, értesítésekben

Szerző:
devblogger
- 2009-04-15
Kategóriák: Fejlesztés Haladó szint
. 10 megjegyzés

Több helyen is leírtuk már, de nem részleteztük: a történésekben és az értesítésekben használhattok linkeket is. Megkötés, hogy ezek csak az iWiWen belülre mutathatnak, külső oldalra nem. A linkek előállítása nem feltétlenül triviális feladat, főként ha ki szeretnétek használni azt a lehetőséget, hogy az alkalmazásoknak paraméterek is átadhatók. Az alábbiakban egy példakódot is közzéteszünk, mely segítségével helyes linkek állíthatóak elő könnyedén.

Ha az iWiWen belülre szeretnénk linkelni, akkor célszerű relatív URL-eket használni. A rendszer ezeket, továbbá a http://iwiw.hu/ és http://sandbox.iwiw.hu/ címmel kezdődő linkeket engedi át. Ez utóbbi abszolút URL-ek használatát nem javasoljuk, mivel egy tévesen meghatározott domainből csak problémák lehetnek.

Leszámítva a profil oldalakra történő linkelést, egy történésben, értesítésben főként magára az alkalmazásra szeretnénk linkelni: ez egy /app/12345678 kinézetű URL-t jelent. A link egyébként /app/{appId}{-prefix|/|userId}{-prefix|?view-params=|viewParams} formátumú, amiből talán a legérdekesebb számotokra a viewParams paraméter. Ennek értéke JSON formátumban adható át, segítségével paraméterezhetjük az alkalmazást. Bár egy linket ennek ismeretében könnyedén előállíhatunk már, hogy még egyszerűbb legyen, egy függvényt is közzéteszünk:

if (typeof IWIW == 'undefined') { var IWIW = {}; }
IWIW.getApplicationLink = function(parameters) {
 return gadgets.views.bind(gadgets.config.get('views')['canvas'].urlTemplate, {
   appId: document.location.host.match(/(\d+)\./)[1],
   viewParams: gadgets.json.stringify(parameters)
 });
}

A függvény nem csinál mást, mint veszi a fentebb is bemutatott URL sablont, s behelyettesíti az alkalmazás azonosítóját (mely a Homokozóban és az éles iWiW-en ugyanaz lesz) és az átadandó paramétereket a gadgets.views.bind függvény segítségével. Az alkalmazás azonosítóját az aktuális URL-ből veszi, a sablont pedig egy OpenSocial konfigurációs változóból olvassa ki.

A használata elég egyszerű:

alert(IWIW.getApplicationLink({'aaa':'bbb'}));

A függvény persze okosítható, és átadható hogy a canvas vagy profil nézethez szeretnénk URL-t, vagy hogy melyik felhasználónak a nézetére szeretnénk linkelni, innen már talán nem nehéz ezeket implementálni, ha szükség van rá.

Ahogy korábban is írtunk már róla a requestNavigateTo bemutatása kapcsán, az átadott paramétereket a következőképpen olvashatjuk ki az alkalmazásban:

var params = gadgets.views.getParams();

Értesítés küldésnél például az alábbi formában használható a linkelés az üzenet BODY-jában, amennyiben egy adott tartalomra szeretnénk linkelni az alkalmazáson belül:

// felhasználó objektum, pl. ismerős lekérdezésből (newFetchPeopleRequest)
var user = ...;
// felhasználó keresztneve
var userName = user.getField(opensocial.Person.Field.NAME).getField(opensocial.Name.Field.GIVEN_NAME);
// felhasználó (pl. ismerős) lekérdezéséből jövő profil URL
var userProfile = user.getField(opensocial.Person.Field.PROFILE_URL);
// link az alkalmazásra, példaként egy contentId paraméterrel
var appLink = IWIW.getApplicationLink({'contentID': 87654321});
// az adott tartalom címe
var contentTitle = 'Boys Don\'t Cry';
// üzenet BODY összeállítása
var messageBody =
  '<a href="' + gadgets.utils.escapeString(userLink)+'">' +
  gadgets.utils.escapeString(userName) + '</a> ajánlja kedvencét: ' +
  '<a href="' + gadgets.utils.escapeString(appLink)+'">' +
  gadgets.utils.escapeString(contentTitle) + '</a>. Neked hogy tetszik?';

Figyeljünk rá, hogy csakis valid XHTML tartalmat lehet az üzenetben elküldeni. Tekintettel arra, hogy a felhasználó nevében szerepelhet HTML-nek nézhető tartalom (kisebb/nagyobb jelek, & karakter), illetve ez igaz lehet a linkekre, a linkelt tartalom címére is, ezért ezeket mindenképpen megfelelően kódolni kell!

Adatkezelés és az alkalmazások életciklusa

Szerző:
devblogger
- 2009-04-8
Kategóriák: Jog Uncategorized
. 13 megjegyzés

A felhasználó és a fejlesztő között létrejövő adatkezelés viszony az alkalmazás telepítésével jön létre, és az alkalmazás törlésével szűnik meg. Két idevágó fontos (kötelező!) teendőről, fejlesztői feladatról szól ez a bejegyzés.

Telepítés előtt

Az iWiW felhasználók az alkalmazás telepítése előtt is interakcióba léphetnek azzal, hiszen egy másik felhasználó profil oldalán, vagy egy másik felhasználó canvas oldalán telepítés nélkül is megtekinthetik, “futtathatják” azt. Mivel ekkor még nem születik meg a felhasználó és a fejlesztő között az adatkezelésről és felhasználásról szóló megállapodás, ezért az alkalmazások ilyenkor még nem tárolhatnak le a felhasználóról semmilyen információt.

Ez fejlesztési feladatra lebontva azt jelenti, hogy ha a profil vagy a canvas nézetben az alkalmazás bármit eltárol az adott felhasználóról, akkor ellenőriznie kell, hogy a felhasználó már telepítette-e az alkalmazást. Ha még nem, akkor ez az adattárolás csak anonim módon, a felhasználóhoz nem köthetően valósulhat meg. Ha ez nem lehetséges akkor, célszerű lehet felkérni a felhasználót arra, hogy telepítse az alkalmazást. Ehhez a megfelelő navigációs megoldást a requestNavigateTo függvénnyel (lásd itt) oldhatjátok meg, a függvény harmadik paramétere egy felhasználói azonosítót vár, itt a “VIEWER”-t kell megadni.

Törlés után

Ha egy felhasználó töröl egy alkalmazást, kötelező, a Fejlesztői ÁSZF-ben foglalt adatkezelési irányelvek szerinti feladatotok a felhasználóhoz kapcsolódó adatok törlése, anonimizálása. Az alkalmazás törlése során az adatkezelési szerződés megszűnik a fejlesztő és a felhasználó között, s ezt a helyzetet kell rendezni. A Fejlesztői Útmutató kivonatának 5. pontjában (a Fejlesztői Útmutató IV. pontjában) a hazai jogszabályokkal összhangban a következő szerepel:

Amennyiben egy felhasználó töröl egy alkalmazást, azaz többé már nem akarja azt használni, úgy a felhasználóról akár iWiW-től, akár magától a felhasználótól begyűjtött adatok semmilyen formában nem használhatók, kezelhetők, tárolhatók, elemezhetők, értékesíthetőek, stb. Ezeket az adatokat fejlesztő köteles megsemmisíteni.

Felhasználóhoz nem köthető, nem személyes jellegű információk esetén - erre az alkalmazás adatkezelési nyilatkozatában külön ki kell térni - a törlés helyett anonimizálás is járható utat jelent, az összes többi adatot viszont törölni kell.

Az OpenSocial szabvány erre a feladatra az úgynevezett lifecycle event -et definiálja, mely segítségével az alkalmazás fejlesztője az alkalmazás telepítéséről és törléséről is értesülhet. Az itt megadott URL-re az iWiW aláírt kéréseket indít, melyeket (jelen esetben a törlést) a fentiek alapján le kell kezelni.

Írjuk a következőket bele az alkalmazás XML fejlécébe, a ModulePrefs-en belülre:

<Link rel="event.addapp" href="http://www.example.com/add" />
<Link rel="event.removeapp" href="http://www.example.com/remove" />

Az URL-ek felé menő kérésben egyetlen hasznosítható információ fog szerepelni, a felhasználó azonosítója, “id” nevű GET paraméterrel. Mivel sem az esemény típusa, sem az alkalmazás azonosítója nem szerepel ebben a kérésben, ezért az URL-nek magának kell ezt az információt hordoznia - akár például két GET paraméter segítségével.

Amire mindenképpen figyelnünk kell, hogy az iWiW felől, bármelyik alkalmazásból ne legyen hamisítható ez a kérés, hiszen pótolhatatlan adatok veszhetnek el. Az alkalmazásokból indított kérések során az iWiW felől érkező kérésben több információ is szerepel, melynek hiányából következtethetünk arra, hogy a megfelelő irányból kaptuk a kérést. Ha nincs opensocial_owner_id, opensocial_viewer_id, opensocial_app_id, opensocial_app_url a kérésben, de van id paraméter, és az aláírás helyes(!), akkor biztosak lehetünk benne, hogy valóban az iWiW felől érkezett életciklus esemény, s a fentiek szerint kell cselekednünk.

Kérjük figyeljetek ezekre a kérdésekre, az adatkezelési irányelveknek való megfelelőség szigorú elbírálási kritérium!

Böngésző kompatibilitás elvárások!

Szerző:
devblogger
- 2009-04-3
Kategóriák: Uncategorized
. 15 megjegyzés

Az iWiW felhasználók böngészőhasználata, és az egyes böngészők általános elterjedtsége alapján követelményeket és javaslatokat fogalmaztunk meg az alkalmazások böngésző kompatibilitását illetően.

Követelmények

Az alkalmazásoknak a következő böngészőkkel kell teljeskörűen működniük:

  • Internet Explorer 6
  • Internet Explorer 7
  • Mozilla Firefox 3.x

Teljeskörű működés alatt a funkciók hibamentes és konzisztens viselkedését, és a használható felületű megjelenését értjük.

Az eddig beérkezett és a későbbiekben beérkező alkalmazásokat ebből a szempontból is megvizsgáljuk, s amennyiben úgy tapasztaljuk, hogy a követelményeknek nem felelnek meg, azokat sajnos nem tudjuk jóváhagyni. Kérjük, hogy erre kiemelten figyeljetek!

További javaslatok

Bár a fenti böngészők vezetnek a statisztikákban, kifejezetten javasoljuk az alkalmazások tesztelését a következő böngészőkben is:

  • Internet Explorer 8
  • Firefox 3.5
  • Safari 4
  • Opera 9.6

Az Internet Explorer 8 nemrégiben jelent meg, számottevő felhasználói köre még nincsen, de a jövőben várható a térnyerése. A Firefox 3.5 hamarosan megjelenik, a tapasztalatok alapján ha Firefox 3.0-ban működik egy oldal, akkor ezzel sem lesznek gondok. A Safari 4 immáron Windowsra is elérhető, WebKit motorral működő böngésző, a Mac OS X felhasználók körében népszerű, s a Google Chrome böngészőben is ez a motor van. Végül, de nem utolsó sorban az Opera böngésző is egy ismert, és sokak által használt böngésző hazánkban, így ez alatt is érdemes ellenőrizni munkánkat.

Fontos változás az ismerősök lekérdezésénél

Szerző:
devblogger
- 2009-04-2
Kategóriák: Alapszint, Fejlesztés Tudnivalók
. 0 megjegyzés

A Homokozóban nemrégiben élesítettünk egy fejlesztést, miszerint megszűnt a korlátozás a newFetchPeopleRequest kérés MAX paraméterét illetően. Az eddigiekben egy kéréssel maximum 50 felhasználó volt lekérdezhető, ha a MAX paraméternek nagyobb értéket adtunk meg, akkor is csak 50 felhasználót adott vissza a rendszer. A változás keretében levettük ezt a limitet, azaz egy kérés keretében több felhasználót is lekérdezhetnek az alkalmazások.

A korlátozás feloldásának célja elsősorban az volt, hogy megfelelően indokolt esetben nagyobb lekérdezéseket is egyszerűen végre lehessen hajtani.

Az ismerősök lekérdezése viszonylag költséges, szerveroldalon sok erőforrást igénylő folyamat, így a jövőben sem támogatjuk az indokolatlan használatát.  Az alkalmazások elbírálásánál különös figyelmet szánunk arra, hogy megvizsgáljuk, hogy milyen céllal kerül felhasználásra.

Kérjük, tényleg csak akkor használjátok, ha az alkalmazás alapvető működése szempontjából fontos.

A korábban írt “Az összes ismerős lekérdezése” bejegyzésünkben írtak így érvényüket vesztették, a jövőben nem támogatjuk, hogy az ismerősöket több kérés egybecsomagolásával kérje le az alkalmazás. Ha valaki már az ott bemutatott példakód szerint implementálta az ismerősök lekérdezését, akkor egy ponton kell módosítani a kódon: az egy helyen szereplő 50-es számot kell nagyobb értékre állítani.

A jövőben igyekszünk olyan új függvényeket definiálni szerveroldalon, amely pl. ismerősök véletlenszerű lekérdezését szolgálja, illetve az OpenSocial szabvány és a Shindig container fejlődésével további új lehetőségeket biztosít.