Author Archive for devblogger

Cache header-ök használata

Az alkalmazásokban található, ritkán változó tartalmak/adatok cache-elése hasznos a sávszélesség megtakarítására a gyakori, ismétlődő kérések esetén. A képek, hangok lokálisan történő átmeneti tárolása hatékonyabb megoldás, mint azok sorozatos újra letöltése.

A cache használata közös érdek, csökkenti az alkalmazásokat kiszolgáló szerverek terheltségét, és az iWiW szervereinek külső adatforgalmát.

Így arra kérünk titeket, hogy alkalmazásaitok nem változó tartalmait legyetek szívesek minél hosszabb lejárati idővel ellátott cache fejlécekkel kiszolgálni!

Üzenetsablonok használata

Korábban bemutattuk, hogy az OpenSocial üzenet sablonok hogyan használhatóak csoportosított hírfolyam elemek küldéséhez, de nem ejtettünk szót arról, hogy milyen egyéb felhasználási lehetőségeik vannak: lehetőség van az alkalmazások többnyelvűvé tételére, illetve ezt a lehetőséget használhatjuk az alkalmazáson belül megjelenített szövegekhez akkor is, ha nem célünk a többnyelvűség.

Alkalmazáson belüli felhasználás

Ha az alkalmazáson belül egy üzenetet, szöveget szeretnénk valahol megjeleníteni, és szeretnénk betartani az MVC mintát, akkor jól jöhetnek az üzenet sablonok. A sablonok tartalma (definiálásukat lásd a korábbi bejegyzésünknél) egyszerűen lekérdezhető a következő JavaScript kódrészlettel:

var prefs = new gadgets.Prefs();
var text = prefs.getMsg("hello_world");

A “text” változóban a “hello_world” name paraméterű üzenet szövegét fogjuk megkapni. Az OpenSocial nem kínál olyan függvényt, mely segítségével sablon változók feloldhatóak lennének, de egy ilyet könnyen írhatunk saját magunk is:

if (!iWiW) iWiW = {};
iWiW.getMsg = function(name, parameters) {
  var prefs = new gadgets.Prefs();
  var template = prefs.getMsg(name);
  if (parameters) for (var p in parameters) {
    template = template.replace('${' + p + '}', parameters[p];
  }
  return template;
}

Ha a “szorzas” nevű sablonunk szövege “Az ${a}*${b} szorzás eredménye ${c}”, akkor a függvény az iWiW.getMsg(”szorzas”, { ‘a’: 2, ‘b’: 2, ‘c’: 5 }); formában hívható meg.

Az sablonok szövege azonban nem csak JavaScriptből kérdezhető le, az alkalmazás XML-jében bárhol tudunk hivatkozni rá, és az OpenSocial előfeldolgozó lecseréli a hivatkozást a megfelelő szövegre. Avagy a fent elsőként bemutatott “bonyolult” kódrészlet helyett írhatjuk ezt is:

var text = '__MSG_hello_world__';

A “__MSG_azonosító__” (az egyértelműség kedvéért: az idézőjelet nem kell köréírni) szerepelhet bárhol az alkalmazás XML-jében, tehát a HTML vagy a CSS részekben is. Amire figyelni kell, hogy a fenti példa nem működik jól, ha az üzenet szövegében aposztróf is szerepel, hiszen ekkor nincsen megfelelően escape-elve az aposztróf karakter, s JavaScript hibát fogunk kapni (JavaScript kódrészbe az előbb ismertetett módon célszerű használni a sablonokat).

Többnyelvű alkalmazások

Bár az iWiW kapcsán jellemzően csak magyar nyelvű alkalmazások készülnek, de a sablonok jól használhatóak többnyelvű alkalmazások készítéséhez is (ráadásul eredetileg ebből a célból lett implementálva a funkció). Ha más OpenSocialt támogató oldallal is szeretnénk kompatibilissé tenni alkalmazásunkat, akkor mindenképpen célszerű a sablonok használatát választanunk.

A sablonok definiálásakor kell megadnunk a nyelvet:

<ModulePrefs>
  <Locale messages="http://example.hu/messages_HU.xml"/>
  <Locale messages="http://example.hu/messages_EN.xml" lang="EN"/>
</ModulePrefs>

Ebben a példában a magyar nyelvű üzenet definíciókhoz nem adtunk meg nyelvet - ezt választottuk alapértelmezettnek -, az angol nyelvű üzeneteknél a “lang” paramétert használtuk az nyelv megadásához. Ha az alkalmazást angol nyelvű környezetben töltik be, akkor a “messages_EN.xml” lép érvénybe, minden más esetben pedig a magyar nyelvű szövegek.

A témakörről itt bővebben is lehet olvasni.

Hírfolyam az iWiW nyitóoldalon: csoportosítás

Zárva a bejegyzés sorozatunkat a címlapon megjelenő hírfolyam elemek kapcsán, bemutatjuk a második opciót, melyet használhattok a hírek kiküldésekor: a csoportosítást. Ennek kapcsán az OpenSocial activity két további lehetőségét vezettük be az iWiW-en a hírfolyam elemeknél: a sablonok támogatását, és a hírfolyam elemek csoportosítását. A bejegyzésben bemutatjuk a sablonok használatát, illetve hogy hogyan készíthetőek olyan sablonok, melyek csoportosításra is alkalmasak.

Sablonok

Hírfolyam sablonokat kétféleképpen lehet hozzáadni alkalmazásunkhoz: vagy az alkalmazás XML-jébe ágyazva, vagy külső fájlként meghivatkozva (szintén XML formátum). Mindkét esetben a ModulePrefs részbe kerülnek információk. Az XML-ben elhelyezés a következőképpen néz ki (természetesen ahogy eddig is, a ModulePrefs további tulajdonságai, gyermek elemei megadandóak):

<ModulePrefs>
  <Locale>
    <msg name="uzenet_cime">
      Hello Világ!
    </msg>
    <msg name="uzenet_szovege">
      Ez itt egy szimpla Hello Világ üzenet.
    </msg>
  </Locale>
</ModulePrefs>

A példában ugyan két üzenet szerepel csak, de bármennyit definiálhatunk. Az üzenetek címét és szövegtörzsét két külön sablonnal kell definiálni. Külső XML-re hivatkozni pedig így lehet:

<ModulePrefs>
  <Locale messages="http://example.hu/my-activity-messages.xml"/>
</ModulePrefs>

A hivatkozott XML felépítése:

<?xml version="1.0" encoding="UTF-8"?>
<messagebundle>
  <msg name="uzenet_cime">
    Hello Világ!
  </msg>
  <msg name="uzenet_szovege">
    Ez itt egy szimpla Hello Világ üzenet.
  </msg>
</messagebundle>

Egy ilyen üzenet sablonra a “name” tulajdonságával lehet hivatkozni hírfolyam elem létrehozásakor:

var options = {};
options[opensocial.Activity.Field.TITLE_ID] = "uzenet_cime";
options[opensocial.Activity.Field.BODY_ID] = "uzenet_szovege";
opensocial.requestCreateActivity(opensocial.newActivity(options));

Egy sablonban változókat is használhatunk:

<msg name="osszeadas">
  Az ${a} + ${b} művelet eredménye: ${vegeredmeny}.
</msg>

A paramétereket a következőképpen adhatjuk át:

var options = {};
options[opensocial.Activity.Field.TEMPLATE_PARAMS] = { a: "12", b: "13", vegeredmeny: "42" };
options[opensocial.Activity.Field.TITLE_ID] = "uzenet_cime";
options[opensocial.Activity.Field.BODY_ID] = "osszeadas";
opensocial.requestCreateActivity(opensocial.newActivity(options));

Egy speciális változó is rendelkezésünkre áll, “Subject” névvel, és az aktuális felhasználó adataival. Ezt a következőképpen használhatjuk:

<msg name="osszeadas">
  ${Subject.DisplayName} most ütötte meg a főnyereményt.
</msg>

Ezt a paramétert átadnunk sem kell, a példa a felhasználó nevét - belinkelve a profil oldalára - fogja behelyettesíteni.

Tudnivalók az iWiW-en:

  • Minden, a hivatkozott sablonokban szereplő változóhoz értéket kell rendelnünk a TEMPLATE_PARAMS segítségével.
  • Csak string adható át paraméterként, objektum, vagy például egy OpenSocial Person átadása nem támogatott.
  • Sablon használata esetén a rendszer nem teszi automatikusan a hírfolyam elejére a felhasználó nevét, ezt magunknak kell megtennünk. A hírfolyam nevesítése, ahogyan az értesítéseknél is, kötelező.

Csoportosított hírfolyam elemek

A hírfolyam elemek csoportosítása a sablonok segítségével történik. A “sima” hírfolyam elemen felül definiálni kell azok csoportosított változatát is. Csoportosítás a sablon bármely változó eleme alapján történhet. Például egy alap üzenet:

Példa Béla lájkolt egyet.
Madonna zenésztől Like a Virgin szám a kedvence.

Itt változó paraméter lehet a felhasználó neve, az album neve és magának a számnak a neve. Ez sablonnal így nézhet ki:

<msg name="title">${Subject} lájkolt egyet.</msg>
<msg name="body">${artist} zenésztől ${song} szám a kedvence.</msg>

További sablonok segítségével csoportosíthatóvá tehetjük a hírfolyam elemet, például ha (az aktuális felhasználó ismerősei közül) több felhasználó (vagy egy felhasználó, de többször) is ugyanazt az előadót lájkolja, akkor:

<msg name="title:artist">${Subject.Count} ismerősöd ${artist} ${artist.Count} db számát lájkolta.</msg>
<msg name="body:artist">${Subject.List} kedvenc dalai: ${song.List}.</msg>

A sablon neve után kettősponttal kell jeleznünk, hogy melyik változó szerint kívánunk csoportosítani. Ha a hírfolyamban több hír is megjelenne úgy, hogy az adott változó értéke megegyezik, akkor a rendszer csoportosítani fogja azt a csoportosítást lehetővé tevő sablonokat felhasználva. Ebben a példában egyből láthatóak speciális értékek, a .List felsorolásként jeleníti meg az adott sablon paraméter értékeket, a .Count pedig a darabszámot helyettesíti be.

Lehet csoportosítani felhasználó szerint is, avagy ha az adott felhasználó több számot lájkol egymás után, akkor ahhoz így kell sablont rendelni:

<msg name="title:Subject">${Subject} ${song.Count} dalt lájkolt.</msg>
<msg name="body:Subject">Kedvenc dalai: ${song.List}. Kedvenc zenészei: ${artist.List}</msg>

Ha nincs alapértelmezett (nem csoportosított) sablon, akkor a rendszer a nem-csoportosított esetben a sorrendben legelső sablont használja megjelenítésre. A címlapra kikerüléshez kötelező legalább egy jellemző paraméter szerint csoportosítani mindegyik üzenettípust az alkalmazáson belül (az alap üzenet definiálásán kívül).

Végül, de nem utolsó sorban fogadjátok szeretettel példa alkalmazásunkat, a Rádió Aktivitást.

Hírfolyam az iWiW nyitóoldalon: megerősítés

Ahogy korábbi bejegyzésünkben írtuk, az alkalmazások híreinek címlapra kerüléséhez az egyik lehetőség, hogy az alkalmazásnak megerősítést kell kérnie a felhasználótól a hír elküldéséhez. Bár a konkrét megjelenésnek nincsenek részünkről design követelményei, úgy gondoltuk hogy hasznos lehet ha mutatunk egy példát arra, hogy hogyan valósítható meg ez a funkció.

A megerősítés kapcsán fontos tartalmi követelmények, melyeket a megerősítést kérő üzenetnek tartalmaznia kell:

  • tájékoztatás arról, hogy az alkalmazás hírfolyam elemet szeretne kiküldeni, s ehhez hozzájárulást kér
  • a kiküldendő hír pontos szövegének megjelenítése
  • két megegyező méretű, és ugyanolyan jól látható gomb az elfogadásról és az elutasításról
  • opcionálisan egy be nem jelölt checkbox, mely lehetőséget kínál arra, hogy a jövőben ne kelljen elfogadni a hírelem kiküldését

A példa alkalmazásunkban az iWiW fejlesztők között is népszerű jQuery függvénykönyvtárat, illetve az ahhoz készített Boxy kiegészítőt használtuk a megerősítő “popup” megjelenítéséhez. A példakód nincsen túlzottan kipolírozva, de a működés, illetve egy lehetséges megjelenés jól látható belőle:

activity-confirm

Hírfolyam megerősítés

Hírfolyam az iWiW nyitóoldalon: alapok

Az elmúlt napokban a hírfolyamokat illetően több jelentős változás is történt: a hírfolyam elemek köre kibővült számos iWiW-es “core” eseménnyel, több lehetőséget biztosító moderációs lehetőséget adtunk a felhasználók kezébe, továbbá az iWiW nyitóoldalon is megjelennek immáron ezek az információk. A hírfolyam ebben a formában jóval hangsúlyosabb megoldást, egyben az alkalmazások sikeres terjedéséhez jóval hatékonyabb eszközt jelent a korábbi aloldali megjelenéshez képest. Ebben a bejegyzésben összefoglaljuk a változásokat, és leírjuk, hogy milyen feltételekkel lehet megjelenni az alkalmazások activityjével az iWiW nyitóoldalon, a következő két bejegyzésben pedig példakódokkal illusztráljuk az opciókat.

Egy alkalmazás vagy core funkció által küldött hírfolyam elemnek három állapota lehet a megjelenés helyét illetően:

  • sehol sem jelenik meg (felhasználó letiltotta)
  • csak a hírfolyam aloldalon (iwiw.hu/pages/activity/activities.jsp) jelenik meg (ez az alapértelmezés, vagy a felhasználó így rendelkezett)
  • mind a nyitóoldalon, mind a hírfolyam aloldalon megjelenik (ez az alapértelmezés, vagy a felhasználó így rendelkezett)

Az egyes felhasználók szabadon felülbírálva az alapértelmezést letilthatják az adott forrásból származó hírelemeket, vagy a blokkolt alkalmazások oldalról visszaállíthatják, esetleg csak a hírfolyam aloldalra korlátozhatják azokat.

Az iWiW-es funkciók alapértelmezése, hogy a nyitólapon és a hírfolyam aloldalon is megjelennek.

Az API-hoz csatlakozó, általatok fejlesztett alkalmazások tekintetében két opció közül legalább egyet teljesítenetek kell, hogy az adott alkalmazáshoz központilag bekapcsoljuk a nyitólapi megjelenést is. (Az iWiW nyitólapra engedését minden esetben egyedileg fogjuk elbírálni, elképzelhető, hogy a kiengedéshez kérni fogjuk, hogy mindkét kritériumnak feleljen meg az alkalmazás.)

A két opció a következő:

  • Az alkalmazásból kiküldött hírek kapcsán a felhasználótól egy (div-vel megvalósított) “popup” segítségével a felhasználó hozzájárulását kell kérnetek a hírelem kiküldéséhez, tájékoztatva a felhasználót a hírelem pontos tartalmáról, és a kiküldés tényéről.
  • A kiküldött híreknél meg kell valósítanotok a hírelemek csoportosíthatóságát, vagyis hogy a címlapon az adott alkalmazás felől érkező híreket összefoglalva tudja megjeleníteni az iWiW.

A “popup” elkészítését és megjelenését rátok bízzuk, de egy jQuery-re és Boxy-ra épülő megoldást a következő bejegyzésben bemutatunk példaként. Itt a lényeg a fentebb is leírt adattartalom, és hozzájárulás.

A hírelemek csoportosításához üzenet sablonokat kell majd készítenetek, és ezeket használni a kiküldéskor, ezek használatáról, és a pontos technikai részletekről szintén egy külön bejegyzésben fogunk részletesebben is írni.

Medián WebAudit mérőkódok az alkalmazásokban

Az alkalmazások üzleti szempontból egyik legérdekesebb és legfontosabb mérőszáma a látogatottságuk, és a felhasználók különböző demográfiai paraméterei (életkor, nem, stb.). A jövőben minden alkalmazásban mérni fogjuk azok látogatottságát, ehhez partnerünk, a WebAudit biztosít számunkra mérőkódokat. A mérőkódokat az alkalmazás logikája szerint a fejlesztőknek kell elhelyezniük az alkalmazásokban.

A mérőkódok a dinamikus “oldalletöltéseket” mérik. A kódok központi beillesztése az alkalmazásokba pont ezért nem lehetséges, mert az, hogy mi számít oldalletöltésnek, az mindig alkalmazásspecifikus, így függ az alkalmazás logikájától, és az oldalak megjelenítésének technológiájától is.

A mérési eredményekhez és statisztikákhoz nem csak az Origo, de a fejlesztő is hozzáfér majd, ezzel olyan információkhoz jut, melyet jellemzően más statisztika alkalmazások nem tudnak nyújtani, illetve amelyek nyomán lehetőségetek nyílik tovább optimalizálni az alkalmazást a célcsoportotokra is.

Csak és kizárólag az alkalmazás canvas nézete mérendő, oda kell betenni az alábbi kódrészleteket. Két mérésről van szó, egyrészt az iWiW (iwiw.hu) saját mérésébe is be fog számítani egy kód, másrészt pedig az alkalmazás külön is mérve lesz. Ezért minden “oldalbetöltődéskor” két külön kód meghívása szükséges, egy iWiW-es, és egy az alkalmazáshoz tartozó.

A saját mérésetekhez minden alkalmazásnak egy főoldali és 5 aloldal méréséhez vannak kódjaink, míg a másodiknak meghívandó iWiW-es kód az minden oldalbetöltéshez ugyanaz (de alkalmazásonként az is különböző).

A canvas nézet fejlécébe ennek megfelelően be kell húzni a következő JavaScriptet:

<script type="text/javascript" src="http://static.iwiw.net/common/javascript/median.js"></script>

Az oldalak betöltődése után egyrészt az iWiW-es kóddal, másrészt pedig az adott oldal kódjával kell meghívni a WebAudit.measure() függvényt. Az iWiW-es kód mindig ugyanaz, az alkalmazás saját kódja változik.

A WebAudit.measure JavaScript függvényt kell meghívnotok oldalbetöltődéskor, például a főoldal betöltésekor:

WebAudit.measure(...iWiW-es kód...);
WebAudit.measure(...főoldal kód...);

Első aloldal betöltődésekor:

WebAudit.measure(...iWiW-es kód...);
WebAudit.measure(...aloldal1 kód...);

Hogy az adott alkalmazásban mi számít főoldalnak, aloldalnak, azt az iWiW Fejlesztői support-tal (dev kukac iwiw hu) tudjátok egyeztetni azután, hogy e-mailben megkaptátok az alkalmazáshoz tartozó kódokat. A struktúrára első körben várunk tőletek egy javaslatot. Értelemszerűen nem feltétlenül szükséges az összes kódot felhasználni - ha az alkalmazásnak nincs annyi különböző aloldala, akkor nem kell több aloldalt mérni.

A kódok kiosztásával kapcsolatban szeptember első napjaiban folyamatosan felkeressük az élesített alkalmazások tulajdonosait.

Az új, elbírálásra beérkező és jóváhagyásra váró alkalmazások fejlesztőinek az élesítési folyamat során adunk majd kódokat.

Módosul az iWiW Fejlesztői ÁSZF

2009. szeptember 10-i hatállyal módosul az iWiW Fejlesztői ÁSZF (Az iWiW Alkalmazások Általános Szerződési Feltételei Fejlesztők részére).

Az új ÁSZF-et itt olvashatjátok.

A legfontosabb változások röviden:

8.7 - az alkalmazásokba kötelező lesz Medián WebAudit mérőkódokat beépíteni, erre vonatkozóan egy külön részletes blogbejegyzést teszünk közzé a napokban.

17 - az alkalmazásokban megjelenő hirdetésekre csak jogi személyekkel tudunk szerződni.

Bővülő adatkör a felhasználókról, random ismerőslista, paraméterek átadása

Az elmúlt napokban több új lehetőség élesedett mind a Homokozóban, mind az éles rendszerben is elérhetően, továbbá két kisebb változás is volt a Fejlesztői Portálon. A részletek:

Bővebb adatok a felhasználókról

Az első és talán egyben a legizgalmasabb újdonság, hogy bővült a felhasználókról lekérdezhető adatok köre. Eddig a következő adatokat lehetett lekérni:

  • Felhasználó azonosítója: opensocial.Person.Field.ID
  • Felhasználó neve: opensocial.Person.Field.NAME
    • Vezetékneve: opensocial.Name.Field.FAMILY_NAME
    • Keresztneve: opensocial.Name.Field.GIVEN_NAME
    • Egyben: opensocial.Name.Field.UNSTRUCTURED
  • Felhasználó profil oldalának URL-je: opensocial.Person.Field.PROFILE_URL
  • Felhasználó 64×64-es méretű profilképének URL-je: opensocial.Person.Field.THUMBNAIL_URL
  • Felhasználónak telepítve van-e az aktuális alkalmazás: opensocial.Person.Field.HAS_APP

A kör a következő paraméterekkel bővül:

  • Felhasználó beceneve:  opensocial.Person.Field.NICKNAME
  • Felhasználó neme: opensocial.Person.Field.GENDER
  • Felhasználó helye: opensocial.Person.Field.CURRENT_LOCATION
    • Felhasználó országa: opensocial.Address.Field.COUNTRY
    • Felhasználó települése: opensocial.Address.Field.LOCALITY
  • Felhasználó időzónája: opensocial.Person.Field.TIME_ZONE
  • Felhasználó által beszélt nyelvek: opensocial.Person.Field.LANGUAGES_SPOKEN

Az adatokat külön kérni kell a szervertől, amennyiben az alkalmazásnak szüksége van azokra - alapértelmezetten nem küldjük el ezeket az információkat (kímélendő az adatbázist, illetve gyorsítva ezzel az adatlekéréseket). Az egyes mezők neve, illetve értéke az OpenSocial szabvány által definiáltakhoz igazodik. Érdemes lehet az OpenSocial Dev App segítségével átnézni a lehetőségeket, egy felhasználó adatainak lekérdezésekor ott megjelennek a bővített információk.

Íme egy példakód a fentiek használatára:

var params = {};
params[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS] = [opensocial.Person.Field.GENDER];
var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER, params), 'viewer');
req.send(function(response){
  var gender = response.get('viewer').getData().getField(opensocial.Person.Field.GENDER).key;
  if (gender == "MALE") { alert("Hello spaceboy!"); }
  if (gender == "FEMALE") { alert("Hello spacegirl!"); }
});

Mivel a nem-et leszámítva ezeket az információkat nem kötelező megadni az iWiW-en, arra számítsatok, hogy ezen adatok nem minden felhasználónál lesznek elérhetők!

FONTOS!!! Amennyiben már jóváhagyott és élesben lévő alkalmazásod van, és szeretnéd bővíteni az alkalmazás által használt adatok körét, kérjük, hogy ezen szándékodat előzetesen mindenképp jelezd a dev kukac iwiw hu e-mail címen. Adott esetben szükséges lehet az alkalmazás adatkezelési szabályainak frissítése.

Ismerősök véletlenszerűen

Pár véletlenszerű ismerős megjelenítéséhez eddig le kellett kérdezni az összes ismerőst, majd azokból véletlenszerűen választani. Ennek kiváltására és hatékonyabbá tételére bevezettük a “random” sorrendbe rendezhetőséget, melyet a következő példakód szemléltet:

var req = opensocial.newDataRequest();
var spec = opensocial.newIdSpec({"userId": "OWNER", "groupId": "FRIENDS"});
var params = { "sortOrder": "random", "max": 3 };
req.add(req.newFetchPeopleRequest(spec, params), "friends");
req.send(function(response){
  response.get("friends").getData().each(function(person) {
    alert(person.getDisplayName());
  });
});

Kérjük alkalmazásaitokkal igazodjatok ehhez a lehetőséghez!

Paraméterek átadása az alkalmazásnak

Bár az eddigiekben is lehetőséget teremtettünk az alkalmazásnak URL-en keresztüli paraméterátadásra, az adatok nem mentek át, ha a felhasználónak nem volt feltelepítve az alkalmazás (telepítőképernyőnél elveszett), vagy ha éppen nem volt belépve (login képernyőnél elveszett) amikor a linkre kattintott. Ez javítva lett, avagy a paraméterek megmaradnak a bejelentkezés, alkalmazás telepítés során is. Példakód:

gadgets.views.requestNavigateTo(gadgets.views.getSupportedViews()["canvas"], {
foo: 'bar',
url: 'http://dev.iwiw.hu/?foo=bar'
});
var params = gadgets.views.getParams();
alert(params['foo']);

Az első kódrészlet a canvasra navigálást mutatja meg, a második pedig hogy hogyan lehet kiolvasni az átadott paramétereket. Paramétereket nem csak a requestNavigateTo segítségével történő átnavigáláskor, hanem hírfolyamban és értesítésben szereplő linkekben is át lehet adni.

Fejlesztői portál

A fejlesztői portálon is végeztünk kisebb fejlesztéseket. Az egyik változás, hogy az eddig nem túl egyértelmű “Alkalmazás frissítése” gombnak immár az elhelyezkedése és leírása is jelzi, hogy minden környezetben (Homokozó is, éles rendszer is) frissül az alkalmazás, amennyiben megnyomjátok a gombot (emiatt érdemes külön fejlesztői verziót felvenni külön az alkalmazásból).

Egy másik változás, hogy újonnan hozzáadott alkalmazás XML megadása után nem kell kattintgatni ahhoz, hogy a Homokozón megjelenjen az alkalmazás, hanem egyből elérhető, aktív lesz ebben a környezetben.

Új megkötések az alkalmazásokban

Az eddigi tapasztalataink és a felhasználók visszajelzései alapján új, a már élesben látható alkalmazásokat is érintő megkötéseket vezetünk be. Minden fejlesztőt kérünk, hogy figyelmesen olvassa el az alább írtakat. Az alkalmazások módosítására június 12-ig biztosítunk lehetőséget. A változások főként az eddigi ÁSZF-ben foglalt szabályok további magyarázatát, szándékaink egyértelműsítését jelentik, a Wikiben belinkelt Fejlesztői Útmutató V. pontja illetve a Fejlesztői Útmutató Kivonatának 4-5. pontjai módosultak.

Hírek szövegezése, kiküldése

A hírfolyamra küldött hírek célja az aktuális felhasználótól ismerősei felé történő tájékoztatás az alkalmazásban történtekről. A hír szövegének utalnia kell a valódi cselekvésre, valótlan információt nem tartalmazhat.

Jó példa:

  • Szabó János telepítette az Amőba alkalmazást. Telepítsd fel te is, ha még nem próbáltad!

Rossz példa:

  • Szabó János szeretné, ha az Amőba alkalmazásban te is játszanál vele.

A hírekkel kapcsolatos összes szabályt a Fejlesztői Útmutató V. pontja részletezi, illetve itt is megtalálod.

Értesítések szövegezése, kiküldése

Az értesítések célja az aktuális felhasználótól egy másik konkrét iWiW felhasználó felé indított konkrét üzenet küldése. Egyrészt a fogadó félnek tudnia kell, hogy kitől kapott üzenetet, másrészt az üzenet nem tartalmazhat valótlan információt. Az értesítés-küldésnél nem lehet eleve kijelölve az összes ismerős, és az egy kattintással történő összes ismerős kijelölését sem támogatjuk.

Az értesítésekkel kapcsolatos összes szabályt a Fejlesztői Útmutató V. pontja részletezi, illetve itt is megtalálod.

Linkek a profil oldali nézetben

Az alkalmazás profil oldali nézetében csak külön engedéllyel helyezhető el az iWiW-ről kifele mutató link. A profil oldali nézetre összefoglaló, az alkalmazás canvas nézetét hirdető funkcióként tekintünk. Amennyiben ettől el szeretnétek térni, kérjük egyeztessetek velünk.

Alkalmazás viselkedése a telepítés előtt

Az alkalmazás jelenleg négy környezetben jelenhet meg a profil/canvas és saját/más tulajdonos tengelyek mentén. Ha más felhasználó profil vagy canvas oldalán jelenik meg, akkor előfordulhat, hogy még nincsen telepítve az aktuális felhasználó számára. Ekkor a felhasználó még nem fogadta el az alkalmazás felhasználási feltételeit, adatkezelési nyilatkozatát (ezeket még nem is olvashatta), így az alkalmazás nem tárolhat semmilyen hozzá kapcsolható információt sem az iWiW-en belül, sem külső szerveren. A legegyszerűbb megoldás, ha a felhasználót felszólítjuk az alkalmazás telepítésére egy megfelelő link elhelyezésével, mely  a saját canvas oldalára vezet. Egy sokkal bonyolultabb lehetőség pedig, ha a két dokumentumot megjelenítjük a felhasználó számára, és azokat elfogadtatjuk vele az alkalmazás telepítése nélkül - ekkor azonban a felhasználót tájékoztatni kell arról is, hogy milyen módon tudja majd törölni, vagy töröltetni a róla tárolt információkat az alkalmazásból.

Erről bővebben a Fejlesztői Útmutató IV. pontja (További fontos tudnivalók az adatkezelésről) rendelkezik, illetve itt is olvashatsz róla.

Alkalmazások életciklusa

Korábban írtunk már róla, hogy az alkalmazás eltávolításakor a felhasználóhoz kapcsolt információkat törölni, vagy anonimizálni kell. Erre azoknál az alkalmazásoknál kell különösen odafigyelni, melyek az iWiW-en kívül tárolnak személyhez köthető adatokat.

Alkalmazások frissítése az éles rendszeren

Az alkalmazások frissítéseit eddig is liberálisan kezeltük, és ezután is így szeretnénk, de mostantól minden frissítésről emailben (dev kukac iwiw pont hu) kérünk rövid, tényszerű összefoglaló emailt, akár minimális, akár nagyobb változtatás történt az alkalmazáson.

Az alkalmazások frissítéséről bővebben a Fejlesztői Útmutató III/6.-os pontjában olvashatsz.

Promo kép használata

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