Closed gplesz closed 5 years ago
Az authentikáció a regisztráción alapul, ami egy webes felületet és egy ellenőrző emailt használ, erre nincs API, ha jól láttam. Így a fehasználónak a saját API kulcsát vagy az én API kulcsomat kell használnia, az alkalmazásból most nem fogunk regisztrálni.
Az adatok lekéréséhez meghatározzuk a hívási paraméteket. Feladatok:
Ezeket a paramétereket (bár perzisztens adatok) egyelőre alkalmazás paraméterként fogom tárolni, nem érdemes erre adatbázist tenni az alkalmazás mellé.
A visual studio code REST Client extension-jével tudom tesztelni és dokumentálni is az API hívást, így ezt fogom használni a felderítéshez.
Az első hívás sikeres, egyelőre túl sok információt kapok vissza, nekem csak az aktuális és a hét napos előrejelzésre van szükségem naponta, így a fölösleget ki kell tiltanom. Ezek szerint valami ilyen lesz a kérésem:
a lang paramétert a felületről fogjuk kapni, a units=auto a mértékegységeket a lekérdezett hely szerint állítja be, ez veszélyes lehet, így inkább fixáljuk si-re:
ez ilyen mértékegységeket használ:
SI units are as follows:
summary: Any summaries containing temperature or snow accumulation units will have their values in degrees Celsius or in centimeters (respectively). nearestStormDistance: Kilometers. precipIntensity: Millimeters per hour. precipIntensityMax: Millimeters per hour. precipAccumulation: Centimeters. temperature: Degrees Celsius. temperatureMin: Degrees Celsius. temperatureMax: Degrees Celsius. apparentTemperature: Degrees Celsius. dewPoint: Degrees Celsius. windSpeed: Meters per second. pressure: Hectopascals. visibility: Kilometers.
Ezt már be tudjuk fixálni a felületre, nem lesznek téves adatok megjelenítve még véletlenül sem.
A visszatérő értékek közül az X-Forecast-API-Calls fejléc érdekes, ez jelzi, hogy a mai nap mennyi hívást indítottunk, így látszik, hogy mennyi inygenes lehetőség van még, illetve, ha fizetős szolgáltatásba csúsztunk akkor hol tartunk.
A visszaadott adatok modelljéhez induljunk ki egyrészt azokból az adatokból, amiket a feladat kiírás vár tőlünk:
illetve a bejövő adatokból, amit mindenképpen érdemes parse-olnunk. Ez az aktuális adatokra így néz ki:
"currently": {
"time": 1545123967,
"summary": "Közepes felhősödés",
"icon": "partly-cloudy-day",
"precipIntensity": 0,
"precipProbability": 0,
"temperature": -9.36,
"apparentTemperature": -9.36,
"dewPoint": -11,
"humidity": 0.88,
"pressure": 1030.74,
"windSpeed": 0.2,
"windGust": 1.4,
"windBearing": 353,
"cloudCover": 0.58,
"uvIndex": 0,
"visibility": 5.02,
"ozone": 333.8
}
a napi előrejelzés pedig ilyenekből áll:
"data": [{
"time": 1545087600,
"summary": "Ködös idő reggel.",
"icon": "fog",
"sunriseTime": 1545114502,
"sunsetTime": 1545144910,
"moonPhase": 0.35,
"precipIntensity": 0.0025,
"precipIntensityMax": 0.0076,
"precipIntensityMaxTime": 1545156000,
"precipProbability": 0.01,
"precipAccumulation": 0.053,
"precipType": "snow",
"temperatureHigh": -1.01,
"temperatureHighTime": 1545134400,
"temperatureLow": -4.87,
"temperatureLowTime": 1545184800,
"apparentTemperatureHigh": -1.01,
"apparentTemperatureHighTime": 1545134400,
"apparentTemperatureLow": -7.07,
"apparentTemperatureLowTime": 1545202800,
"dewPoint": -8.54,
"humidity": 0.86,
"pressure": 1030.03,
"windSpeed": 0.43,
"windGust": 2.62,
"windGustTime": 1545087600,
"windBearing": 322,
"cloudCover": 0.69,
"uvIndex": 1,
"uvIndexTime": 1545127200,
"visibility": 13.36,
"ozone": 328.87,
"temperatureMin": -12.68,
"temperatureMinTime": 1545112800,
"temperatureMax": -1.01,
"temperatureMaxTime": 1545134400,
"apparentTemperatureMin": -15.16,
"apparentTemperatureMinTime": 1545094800,
"apparentTemperatureMax": -1.01,
"apparentTemperatureMaxTime": 1545134400
}]
Felhasználva a visual studio szolgáltatását, a visszatérő adatok json-jéből generáltatok
Amire figyelni kell: unix időszámítást használnak az adatok, ezeket majd időponttá kell alakítani. Ezt az Automapperre bízhatjuk.
Küldéskor beállíthatjuk a
Accept-Encoding: gzip
fejlécet, hogy használjuk a http tömörítést.
A következő lépés a darksky api és a teszjeinek a létrehozása, ott tudom folytatni a modell készítését.
Az API wrapper-t dotnet standard környezetre írom, így wpf-ből is tudom hivatkozni, de (.net core) multiplatform is lehet. Ezen kívül kipróbálom a SpecFlow-t, .net core-ból még nem használtam, preview van csak, de egy próbát megér.
A wpf alkalmazás 4.7.1-es dotnet framework-öt fog használni, mivel nincs egyéb megkötés a feladatkiírásban.
egyből létrehozom a wpf alkalmazást is, hogy a referenciák biztosan működjenek végig.
hogy ne okozzon gondot a csomagok hivatkozása projekteken átívelő módon, beállítom, hogy a nuget ne packages.config.ot, hanem packagereferencet használjon:
https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx
illetve, kialakítom a teszt környezetet is, .net core és specflow alapokon
Fontos tervezési pont, hogy az API bemeneti adatokat hol állítjuk elő.
Mivel a RestSharp támogatja automatikusan a http tömorítést, ezért azt fogom használni a könyvtárhoz.
Az apikulcs a http tesztállományban szerepel, a tesztforgatókönyvekben is fog, mert ennek elrejtésével most nem akarok időt veszteni, az alkalmazást is egyszerűbb ellenőrizni, ha minden rendelkezésre áll.
Különösebben nagy hibakezelést nem építek be, az api egy boolean-t ad vissza, hogy sikeres volt-e a hívás vagy sem. Emellett naplót ír, később szofisztikálható, hogy mit csináljon a különböző hibáknál.
Az API Wrapper prototípus szinten elkészült, a tesztekkel kapcsolatosan lehet majd bővíteni és javítsani, de a prototípushoz eleget tud.
Ami az első látásra látszik, hogy a darksky API-t egyszer kell majd meghívni, egy kérésre visszaadja az aktuális időpont előrejelzését és az egyheti előrejelzést is. A következő feladatokkal érdemes lesz foglalkozni: