A következő garázsprojektem a pécsieknek lehet hasznos, mobilon tudják majd chekkolni merre járnak a buszok.

Minden további infó a fejlesztésről a projekt FB oldalán fog menni: http://www.facebook.com/pages/Hol-a-busz/450232621719996

Projektindító poszt:

Tegnap a Comenius IHT 1/13-mal óra végén azt beszéltük, hogy ebben a hirtelen jött újratélben nem is biztos, hogy járnak a pécsi helyijáratos buszok, nézzük meg neten. A PKZRT-nek van egy hivatalos oldala, ahol nyomon lehet követni a buszokat (GPS adóval vannak ellátva), így láthatjuk ha épp egy sarokkal előttünk megy. Csak az a baj, hogy ezt az oldalt mobilon lehetetlen használni, erre Bálint hívta fel a figyelmem. JS dropdown, meg iframe gmaps embed, használhatatlan. Pedig ez tipikusan az az oldal lenne, amit az ember a buszmegállóban állva (vagy felé szaladva) használna, nem otthon kényelmesen a fotelban. Szóval az osztály feldobta a labdát (tudják, hogy mostanában mobil webbel foglalkozom) csináljam meg a mobilos felületet.Óra után gyors source turkálás, eléggé áttekinthető a kód, meg is találtam, hogy a weboldal hogyan kommunikál a szerverrel, és hogyan kéri le a buszok adatait. Szóval most itt tartok, arra gondoltam, hogy ennek az apró fejlesztésnek minden fontosabb mozzanatát egy külön fb oldalon publikálom, sőt az első tesztverziókat is elérhetővé teszem, és a teszterekkel itt tartom a kapcsolatokat….nyílt lapokkal.

Sejtettem, hogy elsőre nem kerülök a vájúhoz. Visszadobta az Apple a programomat, de szerencsére nem azzal az indokkal amire én számítottam.

Miről is van szó?

Regeltem Apple fejlesztőnek magam, és arra gondoltam megpróbálkozom az App Store-ba fejleszteni. A natív fejlesztésbe nem ugranék bele, nem is érdekela annyira és nem is vagyok programozó. Viszont webdesignerként HTML/CSS/JS webappok terén ár van tapasztalatom, és vannak ugyebár fejlesztőeszközök és frameworkok amikkel ezen tudásomra alapozva tudokok én is fejleszteni natív appot (khmmm), de azért ennek vannak buktatói. Ebbe már bele köthet az Apple.

A Titanum-ra esett a választásom. Első körben készítettem egy HTML5 webappot, ami HTML5 geolokációt használva saját szerverre (!!!) elküldi a user GPS koordinátáit, majd én saját saját szerveren gMaps API segítségével geokódolom és megmondom melyik városban van és ott mi a postai irányítószám… nem nagy cucc, de én totálisan arra számítottam, hogy a HTML5 lokáció és a saját szerverre való GPS koordináta küldés fogja elkapálni az appot, de nem így történt. A válasz csak azt ecsetelte, hogy bár az Apple az egyszerűséget és az átláthatóságot tartja szem előtt, de az én alkalmazásom már túl egyszerű, kevés funkciót tartalmaz, ezért nem engedélyezik.

Vagy egyszerűen nem nézték mélyebben a technikai részleteket, vagy azzal tényleg nincs gond, ha én HTML5/JS webappot és saját API-kat (amikkel jQuery segítségével JSON objektumokon keresztül kommunikálok) használok és bújtatom valami builderrel natív app bőrébe.

Régebben már agyaltam azon, hogy ma a weben vajon terméket érdemes-e készíteni, vagy inkább szolgáltatást kell fejleszteni.

Annó a szolgáltatásra tettem a voksom. Ma már picit árnyaltabban látom a kérdést, de tény, hogy a “csak csináljunk egy weboldalt” gondolkodás már kevés.

Jelenleg azt mondanám, hogy ha van egy termék ötletünk, akkor alakítsuk azt át szolgáltatás modellé, de ne publikáljunk addig semmit, amíg a szolgáltatásra épülő eredetei termékünket nem készítettük el. Ez után pedig megjelenhetünk az adott termékkel (jobban is marketingelhető), valamint egyből kapcsolni tudjuk hozzá a különböző szolgáltatás modelleket.

Konkrét példát is tudok mondani a garázsból…igen, az ügyeletespatika.com.

Az alapötlet egy alkalmazás (most mindegy, hogy natív vagy webapp) elkészítése volt, ami megmutatja egy adott városban mely gyógyszertár ügyeletes. Ezt már tudjátok. Az új felfogásmóddal ezt kibővítettük, és létrehoztam a patikaadatokat kiszolgáló API-kat (szolgáltatások), és ezekre épül az ugyeletespatika.com, mint egy termék. Szintén ezekre az API-kra épül a weboldalakba ágyazható modul… és még van néhány ötlet…

Tehát a kiinduló pontban lévő ügyeletespatika app már csak egy funkció a sok közül. Igen, ugyanarról a dologrol több bőr lehúzása, de nem ez hajtja a világot?

Szóval jelenleg van

• fejlesztőknek szánt API ami a magyar gyógyszertárak alap adatait szolgálja ki JSON kimenetben (hamarosan)
• fejlesztőknek szánt API ami egy adott városban egy adott napon ügyeletes gyógyszertárak adatait szolgálja ki JSON kimeneten (hamarosan)
• weboldal tulajdonosoknak szánt beépíthető modul egy adott városban lévő ügyeletes gyógyszertárak megjelenítésére: http://embed.ugyeletespatika.com
• felhasználók számára szánt webalkalmazás egy adott városban lévő ügyeletes és normál patikák megjelenítésére: http://ugyeletespatika.com
• …ugyanez natív Android/iOS alkalmazás formájában (hamarosan)

Nos akkor ezennel levettem a béta jelzőt. Innentől 1.0 (jelenleg 80-as build) verzió van kint, az alap funkciók elméletileg hibamentesen működnek, semmi sem igényli a félkész címkét.

De nem állunk meg, további fejlesztések jönnek:

• normál nyitva tartás esetén közeli patikák hivatalos és pontos adatbázis alapján alkalmazáson belüli térképen
• ha nincs az adott városban ügyeletes patika, akkor a legközelebbi város mutatása ahol van
• patika tulajdonosok saját maguk szerkeszthetnek kiegészítő információt gyógyszertárukhoz
• …és még sok-sok titkos dolog ;)

Egy újabb garázsprojektem indult útjára, de az első posztot ezennel nem én írtam meg róla, hanem stro-B barátom, olvassátok ékes szavait: http://www.stro-b.com/patikablog/ugyeletes-patika-hol/

Sajtómegjelenések

• Patikablog
• Szifon.com
• iPhone Hungary
• Blog Pécs
• Apple hírek
• iPhone Blog

Verziók

• 2.0 Teljesen újraírt feldolgozó kód. Pontosabb eredmények.
• 1.3 Hibajavítás, együttműködés az embeddelhető modullal (http://embed.ugyeletespatika.com)
• 1.2 Új funkció: közeli patikák térképes megjelenítésénel már nem google keresés van használva, hanem hivatalos forrásból származó adatbázisból vannak a gyógyszertárak megjelenítve
• 1.1 Hibajavítás+új funkció: ha az adott városban nincs ügyeletes gyógyszertár, akkor megmutatja mely közeli városokban van
• 1.0.x Már nem béta, az alapfunkciók a tervek szerint működnek
• 0.9.7x beta További hibajavítások, funkcióbővítések
  • Kézi városmegadáskor patika címének mutatása térképen
• 0.9.6x beta További hibajavítások, funkcióbővítések
  • Budapest agglomerációk ügyeleti beosztásai
  • Budapesten a több ügyeletes patika közül távolság szerinti legközelebbi jelzése
• 0.9b Hibajavítások
• 0.8b Első publikus béta verzió
  • Az élesítés utáni első hét forgalmi statisztikája: PDF

A lentebbi posztomban a képlet mutatja, hogy valami mobilra optimalizált, facebookkal és (virulens) megosztással kapcsolatos valamit szeretnék kitalálni. Örök kedvenc állatorvosi lovam, a Chuck Norris mém, most is erről húzok le egy bőrt, és most mobil framework nélküli, touch vezérlést használó valamit akartam csinálni, csak hogy a fejlesztés buktatóira fény derüljön. Így összedobtam ezt a webappot.

Feltételezhetően csak iPhoneon működik normálisan. Az érdekességek, amikre fény derült számomra:

• egyscreenes app esetén (én így nevezem amikor nem akarom a scrollozást engedni) számításba kell venni, hogy böngészőben nézve jelentősen kisebb a felületünk, mint fullscreenen, márpedig legtöbben nem fogják a webappot kitenni kezdőképernyőre, illetve a portrait és landscape nézetet is nyílván elegánsabban kellene lekezelni mint itt
• iOS Safari néha viccesen cachel, ne dőljünk be neki
• jQTouch és egyéb frameworkok sokszor nagyon béták és felesleges használni. Sokkal gyorsabban lehet haladni, ha mi magunk írjuk meg a felületet HTML/CSS-ben, és csak kiegészítjük a szükséges meta és jquery pluginekkel a kódot (itt én csak a viewportot, no-scale-t, ikont és a touch slider-t használtam, egyébként egy mezei weboldal)
• ios facebook app-ban nyitot oldalon nem mukodik a sharer.php dialog

Most az érdekesebb hibajelenségekről illetve olyan dolgokról írnék, amikbe a fejlesztés során belefutottam, és amikkel abszolút nem lehet a munkálatok elején tervezni.

Foursquare

Azt már említettem ugye a legelején, hogy a bankok címeit a közösségre hagyatkozva gyűjtöm be, a foursquare adatbázisát használom.

Viszont gyakran nem jól vannak megadva a címek, sőt gyakran hiányosak is, ugyanis az address csak opcionális mező helyszín létrehozásakor, a 4sq a koordinátákat tárolja le. Ahhoz, hogy én mindenhol szépen utcaneveket listázhassak nekem kellett a hosszúsági és szélességi koordinátákat fordított geolokációval címmé alakítani.

A másik probléma maga a kulcsszó. Ez úgy néz ki, hogy egy keresést csinálok úgy, hogy a kulcsszó a bank neve. Na ez néha problémás…

Budapest bank

Belefutottam abba, hogy pl a Budapest Bank esetén a keresési kulcsszó a “budapest” szó volt (általánosságban minden bankhoz a saját egyszerűsített nevét társítottam kulcsszónak). A probléma az lett itt, hogy a találati listában minden olyan hely megjelent, aminek a nevében szerepelt a “budapest” szó.

K&H

A K&H bank esetén is az előzőhöz hasonlatos a probléma. A kereső szó itt is a “k&h”, viszont az “&” jelet logikai AND operátornak veszi a 4sq API, így minden olyan közeli helyet listáz aminek a nevében szerepel a “K” és a “H” betű.

jQtouch

Rengeteg nem várt probléma adódott még abból is, hogy maga a keretrendszer is csak béta, vagyis hibákat tartalmaz. Pl volt olyan, hogy a telefon böngészőjében nyitva tök jól működött a program, de homescreenre téve és onnan indítva nem érzékelte a scroll eventet. Mint kiderült ezt egy hibás CSS osztály okozta.

Na mindegy, jó szórakozás volt, tényleg csak az ünnepek alatti láblógatásra találtam ki magamnak a projektet, úgyhogy befejezettnek tekintem. Bár lehet ha majd nagyon ráérek csinálok belőle egy csomó klón alkalmazást: közeli benzinkutak, közeli gyógyszertárak, közeli kocsmák…

Akinek szüksége van rá, használja egészséggel: http://bankakozelben.eu

Akinek pedig hasonló alkalmazás kellene, keressen fel, biztosan meg tudunk állapodni ;)