turistautak.hu

, bigmick hozzászólásai
Online és letölthető térképek, Windows, Android és iPhone alkalmazások

új hozzászólás | témák listája

Összesen: 676 db hozzászólás

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | következő

bigmick

hozzászólásai | válasz erre | 2019.07.01 11:59:28 (2462)

A fő probléma az az, hogy android 4.4.-től kezdve a Google elkezdte beszigorítani a külső sd-kártyákra pakolt fájlok korábban teljesen szabad felhasználhatóságát.
Az új irány az, hogy a külső sd-kártya az nem egy szabad tárhely, amit bármelyik alkalmazás szabadon használhat, hanem csupán egy cserélgethető médiatároló, amin képek, zenék, videók, csengőhangok tárolhatók leginkább, amikhez az erre (gyárilag) feljogosított alkalmazások férhetnek csak hozzá.
Anndroid 8? (9)-től tovább szigorodott a dolog.
6.1-en elvileg még mennie kell a külső sd kártyára rakott file olvasásának, de már itt is van egy csavar:
a külső sd-kártya elérésnek androidon nincs szabványos módja, ami minden android verzióban, bármely hardware-n ugyanúgy működne.
Sőt: saját telefonomon hosszasan babrálva (ugyanaz a vas, ugyanaz az android verzió) sikerült elérnem, hogy a külső sd-kártyára bemásolt térkép file-t hol képes beolvasni a program, hol pedig ezt írja, hogy az illető térkép file nem elérhető.
A dolog attól függ, hogy amikor a Térkép beállítások-ban kijelölöm a térkép file-t, akkor melyik file-kezelővel, és azon belül is pontosan hogy jutok el a file-ig.
Példa:
Ha az androidos alap file-kezelővel választom ki a térképet:
-SD-kártya/Maps/tuhu.map, akkor a g:hu ezt kapja vissza a file elérési útja gyanánt:
/storage/emulated/0/Maps/tuhu.map
Ha a telefon gyártó (nálam Huawei) által telepített file-kezelővel csinálom:
-Fájlok/Memóriakártya/Maps/tuhu.map, akkor a g:hu ezt kapja vissza a file elérési útja gyanánt:
/storage/6231-3737/Maps/tuhu.map

A kettőből nálam az utóbbi a nyerő.
Megnéztem, mi történik, ha felrakom a FileCommander app-ot, és azon keresztül jelölöm ki a térkép file-t:
- FC/SD-kártya/Maps/tuhu.map, akkor ugyanaz a helyzet, mint a Huawei gyárilag felrakott filekezelőjével, vagyis működik a dolog.

Szóval azt tudom csak tanácsolni, hogy rakjál a telódra valami értelmes file-kezelőt (FileCommander pl.), és amikor kijelölöd a g:hu-ban a térkép file-t, akkor azt ezen a file-kezelőn keresztül tegyed.

[előzmény: (2450) zsedely, 2019.06.25 23:11:17]

bigmick	hozzászólásai \| válasz erre \| 2019.06.11 21:34:17 (2449)
A térkép letöltést akkor NEM a g:hu-ba beépített térképletöltővel csináltad, jól értem? Honnan töltöttél le és mit? [előzmény: (2448) zsedely, 2019.06.11 19:36:57]

bigmick	hozzászólásai \| válasz erre \| 2019.05.28 20:11:59 (2442)
Az online térképen (http://www.turistautak.hu/maps/mapnik/geojaunt.php?lat=47.15237&lon=19.62158&zoom=8&layers=00B00&reset) sincs feltüntetve, csak egy HP85-3001/1 POI (magassági pont?) látszik a helyén [előzmény: (2441) Segafredo, 2019.05.28 19:14:04]

bigmick

hozzászólásai | válasz erre | 2019.05.24 15:52:45 (2437)

A g:hu-ban egy ideje már benne van a lehetőség, hogy a loggal együtt beküldjön a user egy karbantartás kérést is (maintenance=true). De mivel a jelek szerint nem sok hatása van, így azt sem tudni, hányan nyomogatják úgymond "véletlenül".
Azon még gondolkodom, hogy a villáskulcs bekapcsolási kérést app oldalon valami feltételhez kötném.

[előzmény: (2431) petrot81, 2019.05.24 09:33:44]

bigmick	hozzászólásai \| válasz erre \| 2019.05.15 18:00:04 (2425)
A most fejlesztés alatt levő g:hu+-ban lesz egy Szűrő funkció, amivel a ládalistában ill. a térképen megjelenő ládákat lehet majd szűrni, hogy ne kelljen rengeteg láda közül totózni, ha keresek valamit. [előzmény: (2424) efemm, 2019.05.15 16:45:03]

bigmick

hozzászólásai | válasz erre | 2019.04.03 08:34:55 (2387)

Úgy látszik, korán örültem :(
Valami még mindig nem kerek az openmaps.eu szerverével, mert most megint nem megy.
Mondjuk annyi változás van az elmúlt hetekben tapasztaltakhoz képest, hogy míg korábban mindig timeout üzenet lett a próbálkozás eredménye, most az esetek egy részében már más üzenet jön.
De térképet sajnos megint nem lehet letölteni...

[előzmény: (2385) fehérkút, 2019.04.03 07:07:20]

bigmick	hozzászólásai \| válasz erre \| 2019.04.02 20:24:26 (2384)
Az openmaps.eu háza táján valami történt: újra működik a térkép letöltés. Az elérhető térképek nem frissültek a szerver kiesés ideje alatt, így most 2019.03.11-én készült térképek érhetők el. A g:hu is újra látja ezeket a térképeket, megint lehet használni a térkép letöltés funkciót.

bigmick	hozzászólásai \| válasz erre \| 2019.03.31 20:28:33 (2383)
Elő tudtam kaparni egy 2 hónappal ezelőtti openmaps.eu-s Magyarország térképet, innen elérhető: hungary_openmaps_eu_europe.map.zip [előzmény: (2378) accu, 2019.03.31 07:35:10]

bigmick	hozzászólásai \| válasz erre \| 2019.03.29 20:20:37 (2377)
Egy ládaoldal betöltése most kb. 10 sec. [előzmény: (2375) LionDaddy, 2019.03.29 19:33:58]

bigmick	hozzászólásai \| válasz erre \| 2019.03.26 12:46:24 (2374)
g:hu 1.6.3a Apróbb javítások mellett a térképletöltés környéke módosult: - az openmaps.eu térképletöltő szerverének hetek óta tartó döglődése értelmesebben lett lekezelve - a turistautak.hu térképletöltés web-címének a megváltozása át lett vezetve, így újra lehet ezt a térképet letölteni

bigmick	hozzászólásai \| válasz erre \| 2019.03.16 13:57:45 (2366)
Nem a g:hu-val van gond, hanem az openmaps.eu letöltési szervere elhasalt Tudnak róla, jővő hétre remélhetőleg újra menni fog [előzmény: (2365) GSdriver, 2019.03.16 13:12:15]

bigmick

hozzászólásai | válasz erre | 2019.03.14 13:17:10 (2360)

g:hu 1.6.2xc
A visszatéréskori lefagyás kiiktatásának újabb állomása.
sanzi89 és vittorio visszajelzései segítettek megtalálni egy alattomos hibát, ami csak bizonyos körülmények között jön elő.
Nálam hosszas tesztelések során egyetlen egyszer sikerült előidézni (történetesen android 4.2-es emulátoron), de se előtte, se utána egyetlen más alkalommal sem.
A lényeg, hogy most ezt is javítottam, és remélem, hogy végelegesen sikerült ezt a bosszatnó hibaforrást is kigyomlálni.

[előzmény: (2358) sanzi89, 2019.03.14 11:25:53]

bigmick	hozzászólásai \| válasz erre \| 2019.03.14 12:20:19 (2359)
A lényeg, hogy nem fagy le. A megjelenő üzenetet majd kiirtom. [előzmény: (2358) sanzi89, 2019.03.14 11:25:53]

bigmick	hozzászólásai \| válasz erre \| 2019.03.14 09:45:19 (2356)
Te is meg tudod oldani. Az android Beállításokban visszaállítod a nagy betűméretet normálra... Azért megnézem, mit tehetek a SzemüvegEllenes Liga tagjainak érdekében :) [előzmény: (2355) V_Gabor, 2019.03.14 07:25:48]

bigmick	hozzászólásai \| válasz erre \| 2019.03.13 09:18:47 (2353)
g:hu 1.6.2xb Remélem sikerült meggyógyítani a logolás lépernyőre visszatérés problémáját

bigmick	hozzászólásai \| válasz erre \| 2019.03.13 09:02:45 (2352)
Nagyon köszönöm a visszajelzést, ez alapján meg tudom gyógyítani. [előzmény: (2351) vittorio, 2019.03.13 06:53:18]

bigmick

hozzászólásai | válasz erre | 2019.03.12 20:55:01 (2350)

Sajnos a Google Play developer konzolon nem jelent meg adat a Te próbálkozásodról :(

Csináltam egy kidekorált g:hu 1.6.2xa verziót, direkt neked.
Meg kéne próbálni a Galériáról visszatérést, és ha szerencsénk van, nem lefagyás lesz, hanem a program egy pár másodpercre feldob majd egy üzenetet, amit ha valami módon tudnál rögzíteni és nekem eljuttatni, akkor azzal előrébb lehetnénk.

[előzmény: (2341) sanzi89, 2019.03.11 19:11:51]

bigmick	hozzászólásai \| válasz erre \| 2019.03.12 15:09:26 (2348)
g:hu 1.6.2x Ennek már települnie kell mindenkinél.

bigmick	hozzászólásai \| válasz erre \| 2019.03.11 20:44:49 (2343)
Köszi, remélem meg tudjuk fogni, mi okozza [előzmény: (2341) sanzi89, 2019.03.11 19:11:51]

bigmick	hozzászólásai \| válasz erre \| 2019.03.11 18:54:46 (2339)
Az mit jelent, hogy nem engedi? Mi történik telepítési kísérletkor? [előzmény: (2336) V_Gabor, 2019.03.11 18:45:01]

bigmick

hozzászólásai | válasz erre | 2019.03.11 18:53:53 (2338)

Na, Android 4.4.4-hez nincs emulátorban futtatható image :(
4.4.2-t tudok próbálni, abban csont nélkül működik.

Esetleg még azt lehetne, hogy felraksz egy g:hu 1.6.2-t a Google Play-ről,
majd működő internet kapcsolat mellett reprodukálod a hibát,
amiről a telefon a háttérben küld egy logot a developer konzolra,
amit holnap már én is látni fogok,
és akkor talán kiderül, mi lehet a gond

[előzmény: (2333) sanzi89, 2019.03.11 18:32:17]

bigmick	hozzászólásai \| válasz erre \| 2019.03.11 18:45:44 (2337)
g:hu 1.6.1 g:hu 1.5.4 [előzmény: (2335) sanzi89, 2019.03.11 18:35:28]

bigmick	hozzászólásai \| válasz erre \| 2019.03.11 18:03:42 (2332)
A telefonon pontosan milyen verziójú az android? [előzmény: (2331) sanzi89, 2019.03.11 17:53:07]

bigmick	hozzászólásai \| válasz erre \| 2019.03.11 17:33:43 (2330)
g:hu 1.6.2w Javítások az alábbi hibákra: - logolás képernyőre visszatéréskor adatokat elfelejti / lefagy - iránytű használat közben néha előforduló lefagyás - ládalista képernyő lefagyás bizonyos körülmények között

bigmick	hozzászólásai \| válasz erre \| 2019.03.11 17:24:49 (2329)
Nálam nem fagy le a 4.4 emulátoron ilyenkor sem, de a visszatéréskor elfelejti a láda nevét, meg amit esetleg már beírtam bármelyik mezőbe, és ez hiba. Javítom, majd még ma csinálok egy tesztverziót, és meglátjuk, azzal mi lesz a tapasztalat. [előzmény: (2328) sanzi89, 2019.03.11 16:46:42]

bigmick

hozzászólásai | válasz erre | 2019.03.11 16:30:30 (2327)

Érdekes dolog, mert akik tesztelték az 1.6.2-t (magamat is beleértve), ilyesmiről nem panaszkodtak.
A Google Play developer konzolon mindig szoktam nézni új verzió telepítése után, hogy van-e hirtelen változás a lefagyások gyakoriságában.
Párat találtam, aminek köze lehet az 1.6.2-ben végzett módosításokhoz, ezeket próbálom gyomlálni, és pár napon belül lesz egy javított kiadás.
Közben raktam fel 4.4.2-es emulátort a gépemre, azon próbálom nyúzni a programot, hátha előjön az a gond, ami nálad is.
Van valami jellemző szituáció, ahol lefagy a program?

[előzmény: (2326) sanzi89, 2019.03.11 16:05:50]

bigmick	hozzászólásai \| válasz erre \| 2019.03.08 14:36:39 (2322)
OK, köszi, várok. [előzmény: (2321) gusty, 2019.03.08 12:24:55]

bigmick

hozzászólásai | válasz erre | 2019.03.07 17:18:41 (2319)

Bocs, nem cseszegetésből kifolyólag kérdezem, hogy mire számíthatok, csak a g:hu program utódjának (g:hu+) fejlesztése során eljutottam arra pontra, ahol legalább elvi szinten el kéne tudnom dönteni az API hívások stratégiáját.
Ehhez jó lenne tudni, hogy lesz-e lehetőség arra a 3 dologra, amiről pár hete írtam, és amivel összességében kevesebb html hívással, kevesebb select végrehajtásával, sokkal gyorsabban lehetne hozzájutni a láda adatokhoz.

Már egy (3) igen/nem válasz is segítség lenne.
Ha igen (amit nagyon remélek...), akkor esetleg a majdani megvalósítás iránya (pl. logok a cache adatokkal együtt, vagy külön hívással, de cache_id lista alapján, stb.) is jó lenne, ha tudható lenne.
Hogy mikor, az majd egy következő kérdés témája :)

[előzmény: (2249) gusty, 2019.02.21 19:20:30]

bigmick	hozzászólásai \| válasz erre \| 2019.03.04 19:29:02 (2308)
g:hu 1.6.2i Tovább faragtam a "zsebből elővéve elveszti a gps pozíciót" témakör javítását.

bigmick	hozzászólásai \| válasz erre \| 2019.03.04 16:48:28 (2307)
Gondolom, térképe válogatja.. Az érdekel,hogy a turistautak mi alapján jelennek meg az egyes térképeken, vagy hogy egy adott térkép egy adott nagyítási szintjén egy adott területen pontosan mi alapján mutakoznak pont ott a turistajelzés ikonok, ahol? [előzmény: (2305) petrot81, 2019.03.04 15:29:19]

bigmick	hozzászólásai \| válasz erre \| 2019.03.04 16:20:48 (2306)
Alapból szerintem nincs köze hozzá. De van saját külön beállítása: webView.getSettings() Ott lehet matatni pl. a fontméretet is. [előzmény: (2304) petrot81, 2019.03.04 15:09:27]

bigmick

hozzászólásai | válasz erre | 2019.03.03 21:56:45 (2302)

g:hu-ban a leírás és a logok szövegének betűméterét lehetne a "..." menüből elérhetően plusz 1-2-3-4 lépésben növelni?

Biztos lehetne, kérdésem, hogy mennyire nagy erre az igény?

Nejemnek jó pár évvel ezelőtt hasonló gondjaira az optikus kislány (lehetett úgy 15 évvel fiatalabb, mint Iza) azt mondta:
Hölgyem, az Ön korában már természetes, hogy szemüveget kell hordania...

a logok mintha kisebb betűvel jelennének meg, mint a leírás, nem?

Igazából nem tudom, mert a leírást a szabvány androidos webview jeleníti meg a letöltött html formázásnak megfelelően, a g:hu ebbe nem szól bele.
A logok betűmérete '16sp'. Ha nagyon nem olvasható szemüveg nélkül, akkor tudok rajta növelni picit.

A változtatható betűméret macerásnak tűnik, ezt még körbe kell járnom, hogyan lehetne viszonylag nem horribilis mennyiségű kódolással (theme-eléssel, style módosítással) megoldani.

[előzmény: (2293) V_Gabor, 2019.03.03 10:57:28]

bigmick	hozzászólásai \| válasz erre \| 2019.03.03 20:05:34 (2298)
mi kellene ahhoz, hogy a teljes nyomvonalat exportálni tudjam? Pl. próbáld meg a g:hu 1.6.2h verzióval :) Ebben javítottam az általad jelzett gpx export hibát. [előzmény: (2291) Akubb, 2019.03.02 16:46:03]

bigmick

hozzászólásai | válasz erre | 2019.03.01 21:30:25 (2290)

Megpróbáltam a saját telefonomon, letöltöttem az összes geoládát (sose szoktam egyébként, mert egyrészt sokáig tart, másrészt minek).
Bekapcsolt gps mellett Ládalista menüben Térképre funkcióban akármelyik opciót választom, pontosan az jelenik meg a térképen, amit vártam. A térképen a pozíciót jelző emberkét vagy nyíilat nem látom a nagy tömegben, csak ha belenagyítok a térképbe. De közben a g:hu fejléc sávjában a gps ikon folyamatosan zöld, vagyis van aktuális pozíció.
Nem tudom, nálad mi lehet a gond.

[előzmény: (2287) zsedely, 2019.02.28 09:36:06]

bigmick	hozzászólásai \| válasz erre \| 2019.02.26 09:54:53 (2278)
g:hu 1.6.2g Apró javítások, további optimalizálások.

bigmick	hozzászólásai \| válasz erre \| 2019.02.24 22:57:00 (2274)
Milyen g:hu verziót használsz? g:hu 1.6.2f-ben javítottam pont ezt a környéket. [előzmény: (2272) zsedely, 2019.02.24 22:18:20]

bigmick	hozzászólásai \| válasz erre \| 2019.02.24 16:59:41 (2267)
Hogyan próbálod? [előzmény: (2266) zsedely, 2019.02.24 16:49:08]

bigmick	hozzászólásai \| válasz erre \| 2019.02.24 14:43:33 (2262)
Ezt a g:hu fejlesztést már én is nagyon várom. Hát, mit mondjak, én is... Ehhez az API-ban kellene egy olyan bővítés, ami a láda betegre állítását lehetővé teszi. Jelenleg nincs ilyen lehetőség. [előzmény: (2261) V_Gabor, 2019.02.24 11:36:15]

bigmick	hozzászólásai \| válasz erre \| 2019.02.22 08:30:23 (2250)
Jó, köszönöm, várom. [előzmény: (2249) gusty, 2019.02.21 19:20:30]

bigmick

hozzászólásai | válasz erre | 2019.02.21 14:57:06 (2248)

Mindazonáltal én a jelenlegi formában nem bolygatnám nagyon az API-t, Gusty rengeteget dolgozott vele.
Alapvetően egyetértek. Sok munka van benne, stabilan működik, lehet használni. Nem is gondolnám, hogy alapjaiban kellene felforgatni. Én úgy vélem, az API jelenlegi struktúrájának a keretein belül mozognak a kéréseim, amik relatíve kis kiegészítést jelentenének néhány meglevő funkcióhoz, amivel jelentős optimalizálás lenne elérhető a használat közben.

Legközelebb akkor látnám értelmét hozzányúlni, ha az egész GC.hu oldal kapna egy 21.századi felületet a hozzá való szabványos REST API-val, ahol maga az oldal is azt használja.
Valahogy ennek elég pici esélyét látom mostanában...
Az egész GC oldal + a tuhu egy hatalmas falat. Max azt tudom elképzelni, hogy a meglevő mellett elkezdeni csinálni egy újat, kis lépésekben, fokozatosan építkezve, és ami már elkészült, azt a régi oldalról átirányításokkal használatba venni.
De aki belülről jobban ismeri a mostani php kódot, az majd megmondja, hogy mennyire marhaság, amit leírtam, vagy nem az.

[előzmény: (2247) petrot81, 2019.02.21 12:43:49]

bigmick

hozzászólásai | válasz erre | 2019.02.20 22:03:15 (2244)

Alaposan végigelemeztem (a teszt API-ban) a lehetőségeket, és hogy hogyan tudnám leghatékonyabban alkalmazni őket a mobil appban.

3 kritikus szitut találtam:

1. az elsőt már említettem: ha a láda adatok között letölthető lenne egy olyan adat, ami a láda logjaiban bekövetkezett utolsó lényegi változás (új log beküldés ill. meglevő log módosítás) időpontját tükrözi, akkor erre alapozva az egyszer már letöltött adatok későbbi frissítésekor sok felesleges /logsbycache hívást meg lehetne spórolni

2. Egy hosszabb (akár több napos) ládázás előtt az ember letölti a célterületen szóba jöhető ládákat, leírással, a legutolsó logokkal (ez nálam az utolsó 10 logot jelenti).
Egy ilyen akció során a szóba jöhető ládák száma akár több száz is lehet.
A régi API-val megoldható volt, hogy a ládadatok letöltésével egy menetben a logokat is megkapja a hívó. Így viszonylag kevés API hívással lejöttek a kért ládák adatai, logokkal együtt. 100 láda összes adatát (logokkal együtt) le tudtam kérni néhány (nagyságrendileg mondjuk 5) API hívással, és mindez elég gyors is volt.
Az új API-val viszont az nem megy. Ha van egy API hívással lekért 100 láda a kütyün, akkor az 100 újabb API hívást jelent, hogy mindegyikhez hozzájussak a logokhoz is.
Jelentősen több időbe telik így. Nem csoda, 20-szoros az overhead a szükséges http hívások felépítése/lebonyolítása során és ugyanekkora nagyságrend a szerveren az adatbáziskezelőnek is ennyi SELECT request-nek a felépítése/lezárása.
Ha itt megoldható lenne, hogy az API egy /logsbycaches hívással több láda logjait is le tudja kérni egyetlen hívással (cache_id lista alapján), akkor az megint egy nagyságrenddel gyorsítani tudná a logok letöltését

3. Az előzőhöz teljesen hasonló a helyzet a láda leíráshoz tartozó kép adatok letöltésénél is.
Itt is sokat gyorsítana egy /cachesimages hívási lehetőség (szintén cache_id lista alapján), amivel egyszerre több ládához tartozó képeket is le lehetne tölteni (a mezőlista is bővítendő ez esetben a cache_id-vel)

@gusty: látsz esélyt ezeknek a kéréseknek a megvalósítására?

[előzmény: (2240) bigmick, 2019.02.19 20:33:59]

bigmick

hozzászólásai | válasz erre | 2019.02.19 20:33:59 (2240)

Akkor elkezdem:
1. Már betöltött ládaadatok frissítésekor első körben id lista alapján kötegben le tudom kérni, hogy az egyes ládák adatai mikor frissültek utoljára.
Ezt összehasonlítva a lokálisan eltárolt adatokkal le lehet szűrni, melyik ládák változtak, elég csak az ő adataikat lekérni egy újabb körben, részletesen, az összes mezőre kiterjedően.
Ez így remekül működik.
Jó lenne valami hasonló a logokra vonatkozóan is.
A geoládáknál lekérhető egy utolsolog nevű mező, amiről azt gyanítom, hogy a ládához utoljára beküldött log létrehozási dátuma lehet. Valami ilyesmire lenne szükség, de mivel egy logot lehet utólag is szerkeszteni (akár API-n keresztül is), igazából azt kellene tudni, hogy az adott láda logjaiban mikor volt az utolsó módosulás (ami lehetett akár új log beküldés, akár korábbi log módosítása, akár még log törlés is).
Ennek az adatnak a birtokában lehetne igazából biztonsággal eldönteni, hogy az adott ládánál kell-e frissíteni a letöltött logokat, vagy sem.

Jelenleg hiába tudom, hogy a ládához az utolsó log 1 napja (v. 1 hete) került be az adatbázisba, adatfrissítéskor akkor is minden esetben le fogom tölteni a logokat minden egyes ládához, mert hátha változott valamelyik log tartalma, ami adott esetben fontos infót tartalmazhat.
Mozgó ládáknál pl. tipikus, hogy az újrarejtésről szóló infót nem új logba írják a megtalálók, hanem a megtalálás logot egészítik ki később (esetleg napok, ne adj isten hetek múlva).
Másik jellemző szitu, hogy normál ládához a helyszínen appon keresztül logolnak egy gyors Megtaláltam/Nem találtam/Jelszó nélküli logot, majd később (este otthon, vagy a szálláson, vagy több napos túra befejeztével hazulról kényelmesen) leírják az egyéb, adott esetben a későbbi keresők számára lényeges információkat is.

Tehát: a cache lekéréseknél jó lenne, ha lenne lehetőség egy mondjuk logsmodified nevű mezőben megkapni, hogy az adott láda logjaiban mikor történt az utolsó érdemi módosulás. Ha a törölt logokról nem marad elérhető infó (a törlés időpontja), az nem akkora nagy baj, de ha legalább az új log kreálásokat és a log módosításokat figyelembe tudná venni, az szuper lenne.

[előzmény: (2222) gusty, 2019.02.13 00:54:19]

bigmick	hozzászólásai \| válasz erre \| 2019.02.13 06:47:38 (2223)
Köszi, összeszedek pár példát, hogy milyen szituációban alkalmasabb a régi API, és miért. [előzmény: (2222) gusty, 2019.02.13 00:54:19]

bigmick

hozzászólásai | válasz erre | 2019.02.12 23:28:16 (2221)

Nagyon remélem, hogy nem.
Jó pár dolgot meg lehet benne csinálni egyetlen gyors hívással, ami az új API-ban csak sok-sok egyedi hívás egymás utáni végrehajtásával működik.

Ha jó tudom, az volt az elv az új API kapcsán, hogy lehetőleg csak egy-egy táblát érintő, egyszerű lekérdezésekkel ki lehessen szolgálni a kéréseket. Ami végül is sikerült, de szerintem ettől nem lett alacsonyabb a szerver terhelése.
Egy nagyobb, mondjuk 20 egységnyi terhelést okozó lekérdezés adatmennyiségét az új API-val úgy tudom csak összevadászni, hogy indítok 1 egységnyi lekérdezésből 100-at.
Sok éves (nem GC) mobil app fejlesztési gyakorlatomban is az volt a tapasztalat a cégnél, hogy a user összességében jobban járt a komplexebb, de sokkal kevesebb lekérdezéssel, mint a sok-sok egyszerűbbel.
A szerver össz terhelése is így volt alacsonyabb.

[előzmény: (2220) petrot81, 2019.02.12 21:06:34]

bigmick

hozzászólásai | válasz erre | 2019.02.09 18:40:43 (2214)

Menjünk sorban.

hogy van tartózkodási hely bekapcsolva, bepipálva hogy a közelben lévőket,...10km-en belül, mégis letöltött...
Ha a Láda kód mező elejére automatikusan kitöltött GC karaktereket kitörölve használod a ládaletöltés funkciót, akkor egy programhiba folytán sajnos simán előfordulhatott ilyen szituáció :(
Erre nemrég hívta fel a figyelmemet Hev ugyanezen a fórumon. Az 1.6.2f verzióban ezt már javítottam, szerintem pár héten belül kikerül a Googla Play-re is.

A mozgókat pedig nem frissíti,
A mozgók frissítése sajnos jóval lassabb lett, mióta a legfrissebb API-t használom (főleg a logbeküldési tudása miatt).
Ha épp olyan helyen vagy, ahol lassú a mobilnet, akkor a mozgók frissítése akár fél-egy percig is eltarthat.
A program most készülő utódjában megpróbálom a régi és az új API-t kombinálva használni úgy, hogy az újnak a funkcionalitását is kihasználjam, lehetőleg a régi sebessége mellett...

A térképen viszont csak azokat a ládákat látom, amit még nem találtam meg
Ha a ládalista menüben a Megtaláltakat mutat/elrejt funkcióval elrejted a megtalált ládákat, és utána választod a Térképre funkciót, akkor a térképen sem fognak megjelenni a megtalált ládák.

[előzmény: (2212) stmester, 2019.02.09 09:42:36]

bigmick	hozzászólásai \| válasz erre \| 2019.02.09 00:32:57 (2211)
:-)) [előzmény: (2210) Nemi91, 2019.02.08 23:05:48]

bigmick

hozzászólásai | válasz erre | 2019.02.08 22:25:25 (2209)

greenify alkalmazást használom
Akkor lehet, hogy megvan a bűnös :)

Fejlesztői fórumokon körbenézve kb. ez a mondat summázza legtömörebben a greenify és az android 8-as együttműködéséről szóló véleményeket:
everyone says Greenify is trash on Oreo

Szóval, én a helyedben kipróbálnám, hogy viselkedik a g:hu-s térképletöltés greenify nélkül...

[előzmény: (2208) Nemi91, 2019.02.08 21:43:39]

bigmick

hozzászólásai | válasz erre | 2019.02.08 20:29:24 (2206)

Hm. Érdekes. Normál szituációban nálam teljesen jó sebességgel megy a letöltés, kicsomagolás.
Mostanában a térkép használat közben tapasztaltam ilyen lefagyásos jelenségeket (ha extrém nagy számú geoláda van rátöltve a telefonra, és ezeket mind látni is akarom a térképen...)
A mostanában elkövetett kód optimalizálások mind pont az ilyen extrém szituációkban előforduló lefagyások elhárítását célozzák.
Az említett lefagyások, belassulások oka sok esetben az, hogy egy időben ezer alkalmazás van nyitva a telefonon, amik mind tülekednek a szűkös erőforrásokért (CPU, de főleg memória), és ezen a helyzeten az android úgy próbál meg úrrá lenni, hogy menet közben kiirt mindent, amit csak tud, hogy a többiek éljenek...
Az ilyen jellegű extrém helyzetek fájdalommentesebb kezelését próbálom mostanában megoldani.
Már nagyon sok ilyen problémaforrást kiküszöböltem a g:hu programon belül, de tartok tőle, hogy vannak még...

[előzmény: (2205) Nemi91, 2019.02.08 20:00:45]

bigmick	hozzászólásai \| válasz erre \| 2019.02.07 21:10:37 (2201)
g:hu 1.6.2f Újabb kódoptimalizálások, elsősorban a térkép és az iránytű használat környékén.

bigmick

hozzászólásai | válasz erre | 2019.02.04 17:13:40 (2197)

A BaseCamp-nek (ill. a Mapsource-nak) az a része, amivel a PC-re rádugott kütyüre tudja tolni a kiválasztott térképet (azt hiszem Mapinstall a neve), egy bizonyos verzió óta hibás. Rossz. A vele felrakott térkép nem működik (ahogy nálad sem).
A Garmin pedig magasról tesz rá, hogy javítsa ...

Így vagy az marad, hogy BaseCamp/Mapsource nélkül direktben másolod a kütyüre a térképet, és örülsz, hogy működik (ha a kütyü támogatja ezt a módit), vagy beszerzel egy kellően RÉGI Basecamp/Mapsource verziót, amiben még jó Mapinstall volt, és azzal csinálod a térkép felrakást.

[előzmény: (2196) Turistaember, 2019.02.04 15:27:59]

új hozzászólás | témák listája

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók