Opencaching Polska - Forum

Miło mi to słyszeć, bo właśnie przecież o to chodzi, aby program sprawdzał się w praktyce.

Poproszę o linka

futrzak pisze:W porządku, a powiedz mi, planujesz zdobyć całą warszawkę przy jednej wycieczce? Wyobrażasz sobie wydruk opisów tylu skrzynek? Albo tylu ujęć mapy, aby wyraźnie zobrazować położenie każdej? Poza tym póki co mamy ograniczenie do 126 skrzynek na wycieczkę. Bądźmy realistami 30 skrzynek dziennie, to DUŻO, planując nawet trzydniowy weekend taką średnią trudno utrzymać.

ale jak jedziesz na 10-20 dni i nie masz neta to może się przydać

Zawsze można Locusa albo bazę filipsa wrzucić na telefon.

A planer sprawuje się świetnie, jak dla mnie, jedyne co można by dorzucić to możliwość przesuwania keszy na liście (np. jak sobie zaznaczę 10 keszy i potem zauważę jakiś fajny koło wcześniej dodanych miejsc, to muszę usunąć je z listy, dodać ten nowy a potem z powrotem resztę - chyba że tej opcji po prostu nie zauważyłem:) )

Wysłane z mojego GT-I5700 za pomocą Tapatalk

r00t7 pisze:ale jak jedziesz na 10-20 dni i nie masz neta to może się przydać

Podziel plan na pojedyncze dni - zresztą wydruk 20-dniowej wycieczki w Twoim tempie musiał by się skończyć ryza papieru a z czymś takim nie chciał bym latać

cześć,
prosiłbym o możliwość zalogowania do stronki, bo link udało się znaleźć

Maliniak pisze:cześć,
prosiłbym o możliwość zalogowania do stronki, bo link udało się znaleźć

ijjee hakier

Ranwers pisze:

r00t7 pisze:ale jak jedziesz na 10-20 dni i nie masz neta to może się przydać

Podziel plan na pojedyncze dni - zresztą wydruk 20-dniowej wycieczki w Twoim tempie musiał by się skończyć ryza papieru a z czymś takim nie chciał bym latać

Zdecydowanie przesadzasz

Ps: mysle ze bardzo dobra opcja byloby generowanie PDF z opisami

Sent using taptalk

futrzak pisze:Staram się ograniczyć korzystanie z API do minimum ze względu na opóźnienia jakie to generuje. Prawdopodobnie pozostaniemy przy zakładaniu kont (z tym, że będzie 'samorejestracja') + ew. połączenie konta w Planerze z kontem w OC w celu wymiany danych unikalnych dla użytkownika.

W tym przypadku nie generuje żadnych opóźnień, prawdopodobnie wręcz
przeciwnie, bo user zalogowany do OC nie musiałby się drugi raz
logować w Planerze. Ale rozumiem fakt, że dla niektórych OAuth
(szczególnie w wersji 1.0) to czarna magia :)

Jakby w przyszłości pozwolić użytkownikom logować się do OC poprzez
Facebooka lub Google-a (pewnie kiedyś taki moment przyjdzie), to takie
logowanie OAuth propagowałoby się dalej, tzn. byłoby JESZCZE mniej
opóźnień (bo użytkownicy są zalogowani do Facebooka niemal cały czas).

Nie wgryzałem się jeszcze w OAuth, patrzyłem powierzchownie, ale planuję w pewnym momencie go włączyć do projektu, ale nie w celu autoryzacji użytkowników w Planerze, a do powiązania konta planera z kontem OC. Opóźnienie wynika z faktu, że każdorazowo trzeba potwierdzić, czy autoryzacja nie została wycofana. Aktualnie proces autoryzacji w Planerze działa w ten sposób, że przy każdym wywołaniu zapisane w sesji dane użytkownika są weryfikowane z bazą danych. Nie wyobrażam sobie takiego modelu w połączeniu z OAuth.

Zastanawiam się nad połowiczną integracją (bez użycia OAuth), czyli użytkownik w Planerze podaje swoją nazwę użytkownika z OC, aplikacja pobiera przez OKAPI uuid użytkownika i przypisuje go do użytkownika planera. Pozwoliłoby to na zaznaczanie na mapie skrzynek, które użytkownik już odnalazł nie wchodząc na wyższy niż 1 stopień autoryzacji OKAPI.

Wycofanie autoryzacji to bardzo rzadka rzecz. Po co potwierdzać? Jeśli
została wycofana, to OKAPI zwróci błąd HTTP 403 przy najbliższym
wywołaniu Level 3 - wtedy dopiero trzeba użytkownika "wylogować".

Żeby potwierdzić, że przypisujesz użytkownikowi nazwę z OC, musisz
wejść na stopień 3 tak czy siak. To jest równoważne z autoryzacją i w tym
momencie nie ma już potrzeby trzymania osobnego identyfikatora konta.

EDIT: No ale fakt, że opcja z podawaniem przez użytkownika swojej własnej
nazwy jest dużo prostrza do zaimplementowania. Problematyczna może być
dopiero później, jeśli potem zmienisz zdanie. Jeśli autoryzować po OAuth, to
najlepiej od samego początku, niż potem musieć łączyć konta itp.

Problemy autoryzacji odpadłyby gdy cała aplikacje integrowac z kodem OC, nie wiem czy na tym etapie nie warto juz w ta strone jechac bo pozwoli to uzywac szerszej grupie userow niz aplikacja poza serwerem OC ale to juz decyzja "futrzaka" Wirtuala maszyna dostepna z kodem wiec wszystko w zasiegu reki
Powodzenia

wrygiel pisze:Żeby potwierdzić, że przypisujesz użytkownikowi nazwę z OC, musisz
wejść na stopień 3 tak czy siak. To jest równoważne z autoryzacją i w tym
momencie nie ma już potrzeby trzymania osobnego identyfikatora konta.

EDIT: No ale fakt, że opcja z podawaniem przez użytkownika swojej własnej
nazwy jest dużo prostrza do zaimplementowania. Problematyczna może być
dopiero później, jeśli potem zmienisz zdanie. Jeśli autoryzować po OAuth, to
najlepiej od samego początku, niż potem musieć łączyć konta itp.

Nie chciałbym porzucać autoryzacji wg obecnego schematu. W związku z tym autoryzacja całkowicie i wyłącznie przez OAuth odpada. Jedyna rzecz, którą zyskałbym na wdrożeniu połączenia kont poprzez OAuth (na obecnym etapie planowania) to pobieranie notatek do skrzynek, które pojawiły się w prośbach użytkowników. Do reszty wystarcza mi ogólna autoryzacja Level 1 w OKAPI.

Co do replikacji w OKAPI - nie podoba mi się jedna rzecz - w changelogu nie są automatycznie aktualizowane pola typu founds, notfounds (i pozostałe dot. skrzynek chyba też nie). Muszę obrabiać to ręcznie na podstawie wpisów w logach. Idealnie by było, gdyby po zmianie któregoś z tych pól w changelogu pojawiała się pozycja replace z jedynie zmienionymi polami.

Sp2ong: jeśli integrować to jak najszybciej albo wcale. Coraz dalej odchodzę od struktury danych OC (pomimo replikacji przez OKAPI) np. trzymam w osobnych kolumnach szerokość i długość geograficzną skrzynki, mam osobne tabele pomocnicze, które przyspieszają wyszukiwanie, itp. Przemyślę sprawę, przejrzę w przyszłym tygodniu strukturę bazy OC i podejmę decyzję.

Nie ma co się sugerować formatowaniem zwracanym przez OKAPI. Wyniki
jednego zapytania OKAPI pochodzą nawet z parunastu tabel. W
szczególności, w bazie szerokość i długość to dwie kolumny. Ale i tak
jestem zdania, że Twoja aplikacja może pozostać na Twoim serwerze -
będziesz mógł ją zrobić tak jak uważasz, bez dostosowywania się do
istniejącego kodu. Po to przecież powstało OKAPI, żeby tak właśnie móc
robić.

Co do changeloga, z tego co piszesz wynika, że kolumna last_modified w
bazie OC nie jest poprawnie modyfikowana przez kod OC (czyli nie jest
to do poprawienia w OKAPI). Postaram się uzgodnić odpowiednią poprawkę
z adminami OC. Dzięki za zwrócenie uwagi.

Hejka:)

Również poprosiłbym o dostęp do programu bo z chęcią przetestuję w najbliższych keszo-polowaniach .