Diskuze: Nejlepší způsob zpracování dat z webu

Člen

Zobrazeno 14 zpráv z 14.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |


Ahoj,
Já osobně bych volil 3. způsob, kde si vždy stáhneš data ze serveru a uložíš si je do nějakého místního uložiště (doporučuji se kouknout realm).
Při dotazování serveru, bych si vždy vyclearoval "db", vytvořil nové objekty (podle toho jsonu) a následně je uložil do "db" pomocí realmu. Kdyby náhodou, se zařízení nedokázalo dotázat na server tak v catchi nebo v nějakém callbacku (zaleží co používáš za knihovnu na http requesty) jen vyplníš tvoji activitu pomocí těch objektů, které sis v minulosti uložil do realmu.
Přesto že mi příjde ten to postup nehlehčí má 2 problemy...
Na práci s realmem, mám už připravených pár članků, které momentálně dopisuji.
Pokud jsi píšeš i backend sám, doporučuji se kouknout na Firebase.
Díky. Tvoje řešení je teda spíš ta moje druhá odrážka. Uvažoval
jsem o SQLite, ale Realm by asi neměl být problém.
K tomu zahlcení, backend mám na webhostingu. Těch dotazů budou max vyšší
stovky, to by nemuselo hosting zahltit.
Na Firebase se podívám.
Pokud máš webhosting, tak tě zahlcení asi v takovém množství
uživatelů nemusí zajímat 
Co jsem zapomněl napsat je, že Firebase umí pracovat i offline: https://firebase.google.com/…able-offline
To je proč jsem ti ho vůbec doporučil.
Zrovna se na to dívám. Offline? Takže se to kompiluje přímo s apk?
Teď nevím přesně jak to myslíš, ale ukládá si to si to výsledky dotazů/dotazy někam do mezipaměti a když se zařízení nemůže připojit k serveru, tak pouze vezme ty poslední stažené data a zobrazí je. Další věc co to umí je, že když by uživatel například z telefonu, který není připojený k internetu, poslal například nějaký komentář (nějakou update/write akci) tak si to uloží ten dotaz a pošle ho až bude zase připojený k internetu.
Furt to funguje podobně jak nějakej webhosting s db a apičkem, jen na to máš knihovnu a asi to bude lépe optimalizovaný než klasický webhosting.
OK, no ty aplikace budou především data tahat, ne ukládat. Takže asi
půjdu tím prvním řešením bez Firebase.
Zatím to mám namyšlené tak, že minimálně 2 z aplikací budou využívat
na webhostingu parser, který zpracovává webstránku a připravuje JSON. Tam
by se to dalo optimalizovat pravidelným spouštěním a ukládáním na hosting
a taháním těchto uložených dat.
Druhou možností je parsovat data přímo v aplikaci, ale do toho se mi moc
nechce. V PHP jsem totiž mnohem jistější než řešit toto přímo v
aplikaci.
Kdybych to zas řešil v aplikaci, nemusím řešit ukládání. Ale ten
mezikrok si raději udělám.
JSON se velmi lehce parsuje zrovna v Kotlinu/Javě pomocí knihovny Gson. Kód vypadá nějak tak to:
Gson gson = new GsonBuilder().create();
Person p = gson.fromJson(reader, Person.class);
Jak to myslíš "parsovat data z webu"? Že by jsi načetl html a projel to nějakým html selectorem?
Ano, přesně tak. Teď to stejné dělám na hostingu a výsledkem je JSON.
A ten právě chci v aplikaci zpracovávat.
Pokud bych se tomu chtěl vyhnout, asi by to šlo parsovat v Kotlinu přímo v
aplikaci. Ale na to si netroufám, aspoň zatím ne.
A od toho vznikl původní dotaz - jak tohle efektivně dělat
.
Určitě to půjde přes: https://jsoup.org/
Ale příjde mi to jako velmi špatný nápad a zvyk, protože:
Konec konců, myslím, že bude určitě i víc důvodů proč většina aplikací pracuje s jsonem a ne s html.
Zobrazeno 14 zpráv z 14.