Implementation av automatisk datainsamling, lagring och presentation för salubjudna fastigheter och bostadsrättslägenheter på Internet

Implementation av automatisk datainsamling, lagring och presentation för salubjudna fastigheter och bostadsrättslägenheter på Internet Mattias Nilsson mnn01007@student.mdh.se Värdia Jaeger & J:son Kontakt: Jan Persson Mälardalens Högskola Institutionen för Datavetenskap och Elektronik Handledare: Johan Stärner 2006-02-16

Sammanfattning Värdia Jaeger & J:son, är ett konsultföretag som utför alla typer av värderingar och besiktningar av fastigheter och byggnader. I deras värderinsgverksamhet kontrolleras ständigt alla typer av objekt som finns till salu på webbsidan hemnet.se. Ett objekt i Hemnets databas tas bort så fort det blivit sålt eller inte längre är till salu. Detta medför att Värdia inte längre kan kontrollera vad detta objekt hade för utgångspris eller när det var till salu. Dessutom kontrollerar Värdia vilka objekt av typen villa/radhus som är sålda den senaste tiden via ett program som heter VDPro. Uppdateringar av objekt i VDPro måste göras manuellt och jämförelser mellan dessa sålda objekt och objekt till salu från hemnet är krångligt. Denna rapport går igenom hur man kan lösa dessa problem genom att automatiskt hämta all information om olika objekt från Hemnet och lagra denna information i en egen databas som man sedan söker i med ett eget användargränssnitt. Genom att även hämta information om de sålda objekten och lagra dom i en egen databas samt uppdatera denna databas automatiskt slipper man även undan manuella uppdateringar. Det tas även upp hur man genom ett gemensamt användargränssnitt gör det lätt att jämföra objekt från de två databaserna. 2

Innehållsförteckning 1 BAKGRUND, SYFTE 4 1.1 Bakgrund 4 1.2 Syfte 4 2 RELEVANT TEORI 5 3 PROBLEMBESKRIVNING, AVGRÄNSNING 6 4 IMPLEMENTATION 7 4.1 Dataåtkomst 8 4.1.1 Hemnet 8 4.1.2 VDPro 12 4.1.3 Automatisk uppdatering 15 4.2 Användargränssnitt 16 4.2.1 Hemnet 16 4.2.2 VDPro 17 4.3 Presentation av data 20 4.3.1 Använda en datagrid 20 4.3.2 Datagridar och tabell sortering på klientens sida 20 4.3.3 Hemnet 23 4.3.4 VDPro 24 4.4 Inloggning 26 5 MANUAL 27 5.1 Inloggning 27 5.2 Söka 27 5.3 Navigera resultat 28 5.4 Uppdateringar 29 6 RESULTAT, ANALYS AV RESULTAT 30 6.1 Prestanda 30 7 FRAMTIDA ARBETE 31 8 SUMMERING 31 9 REFERENSER 33 3

1 Bakgrund, syfte 1.1 Bakgrund Värdia Jaeger & J:son, är ett konsultföretag som utför alla typer av värderingar och besiktningar av fastigheter och byggnader. Värdia Jaeger & J:son finns representerade i Stockholm, Norrtälje samt Västerås (under namnet VärderingsInstitutet). I deras värderinsgverksamhet kontrolleras ständigt alla typer av objekt som finns till salu på webbsidan hemnet.se. Dessutom kontrolleras vilka objekt av typen villa/radhus som är sålda den senaste tiden via ett program som heter VDPro, tillhandhållet av företaget Värderingdata. Problemet med detta system är att objekt på Hemnets sida tas bort då dom är sålda, i och med detta kan inte informationen som dessa objekt hade vid salufört tillfälle längre granskas, och ofta vill man granska objekts saluförda information även efter dom är sålda. Det blir också svårt att jämföra vad ett sålt objekt salufördes för på grund av detta. VDPro är en Windows applikation som används för att få information om sålda objekt av typen villa/radhus. Programmet VDPro kräver manuell uppdatering. Detta är långt ifrån optimalt då det är lätt hänt att man glömmer uppdatera. Då en uppdatering tar lång tid med programmet så kan detta slösa tid om användaren vill ha tillgång till ett färskt objekt. Programmet är även en Windows applikation vilken kräver installation av mjukvara på varje dator där man vill använda det. 1.2 Syfte Detta examensarbete har skapats för att lösa bland annat problemet med att saluförda objekt försvinner efter en viss tid från hemnet, genom att automatiskt och dagligen spara alla objekt som kommer in på Hemnet i en egen databas. Dessa objekt kan då granskas när så önskas. Extra kolumner där pris per kvadratmeter visas och även kostnad per kvadratmeter per år för lägenheter skall finnas med, då företaget beräknat dessa data manuellt för varje objekt tidigare. Eftersom VDPro är en Windows applikation krävs det att klienten installeras på varje dator där man vill få tillgång till informationen av sålda objekt. Vidare kräver applikationen manuell uppdatering av dess databas, vilket tar mycket lång tid. Har användaren glömt att uppdatera sin klients databas och vill ha information om ett nyinlagt objekt, måste han vänta en lång tid medan databasen uppdaterar innan han kan få den information han behöver. För att förbättra detta behövs både en ny klient som inte kräver installation på varje dator samt automatiska uppdateringar till den nya klienten. För att lätt och smidigt kunna jämföra ett salufört objekt med t.ex. vad det såldes för eller vem köparen var, så bör databasen över saluförda och databasen över sålda objekt kunna visas i samma klient. 4

2 Relevant Teori I detta projekt har programmeringsspråket C#[17] använts som kod bakom till en ASP webbsida. Kod bakom innebär att det är koden som utför alla funktioner bakom det ytliga skalet. C# är ett objektorienterat språk utvecklat av Microsoft. Syftet med detta språk var att använda de bra sakerna från redan existerande språk och lägga till nya förbättringar för att skapa någonting bättre och enklare. Syntaxen i C# är väldigt lika dom i C++, så har man använt C++ känner man snabbt igen sig. För mer information om C# hänvisas läsaren till C# en rapport om C# och dess fördelar skriven av mig själv och Javier Ubillos. Rapporten går i skrivande stund att få tag på genom följande referens[10]. Den mesta av den ASP kod som används är automatiskt genererad av Microsoft Visual Studio och dess designläge för ASP webbsidor. I designläge man kan dra och släppa komponenter till sin webbsida. ASP koden för denna komponent skapas då automatiskt och man kan sedan flytta den dit man vill för att få den design man behagar. Som förtydligande kan man till exempel dra en ASP textruta till sin webbsida i designläge, koden för denna textruta skapas då automatiskt och man kan sedan flytta detta lilla kodstycke i kodläge dit man vill att denna textruta skall ligga på webbsidan, till exempel längst ner på sidan eller inne i en tabell. För mer information och fakta om ASP se referens[11]. En databas kan ses som en fil som permanent lagrar information, man kan sedan hämta, lägga till eller ta bort information från denna fil och så vidare. Vanligast är att kort textinformation lagras i databasen men det går även att lagra längre texter som hela dokument. En databas är uppbyggd av tabeller med fält uppdelade i rader och kolumner och påminner visuellt i sin vanligaste presenterade form om ett kalkylblad. För att hantera och manipulera data i en databas använder man sig av språket SQL(Structured Query Language). Det finns dock många olika versioner av SQL men de flesta versioner stöder dom vanligaste nyckelorden för att manipulera data såsom SELECT, INSERT, DELETE, WHERE, UPDATE och flera andra. Många databasprogram har dessutom sina egna tillägg till SQL språket. För vidare information om SQL kommandon hänvisas läsaren till referens[12]. En webbserver kan lagra och leverera html sidor till webbklienter över Internet. Vilken dator som helst som är uppkopplad mot Internet kan konfigureras och användas som en webbserver. Webbservern i sig är inte själva datorn utan en process som körs på datorn och en enda dator kan konfigureras för att köra flera webbservrar om en speciell port dediceras till varje webbserver. Däremot är det vanligt att man har en dator helt dedicerad för att vara en webbserver och man brukar då kalla den datorn för webbserver. En vanlig webbserver är Microsofts Internet Information Services[13]. Denna webbserver följer med Windows XP Proffesional, Windows 2003 server och Windows NT och är även den webbserver som använts i detta projekt. 5

3 Problembeskrivning, avgränsning Företaget önskar ett program som kan läsa av webbsidan för salubjudna objekt, dessa ska kunna jämföras mot databasen över sålda objekt, för att kunna se om salubjudna objekt säljs till utsatt pris. Vidare skall programmet spara de salubjudna objekten i en databas för att kunna tas fram vid senare tillfälle när behov finns av detta. I princip innebär detta följande: Ett program skapas för att kunna läsa av webbsidan för salubjudna objekt samt spara dessa i en databas. För att detta ska vara möjligt på ett användbart sätt måste tillgång till webbsidans databas finnas tillgänglig. Kontakt med berört företag måste tas för att diskutera och förhandla åtkomst till deras databas, eventuellt kommer direkt parsing av html sidor bli aktuellt om inte tillgång kan fås. Programmet vidareutvecklas för att kunna läsa av och spara ner försäljningspriser och annan data från Värderingsdatas databas. Tillgång till deras databas finns genom programmet VDPro efter avtal mellan Värdia Jaeger & J:son och Värderingsdata. En undersökning huruvida dessa data är tillgängliga utan användning av programmet VDPro måste utföras. Samtliga data samlas i tabellform. I denna eller dessa tabeller skall framgå objektets adress, vad man begärde då det var till salu samt eventuella ändringar som skett med salupriset under tiden det varit exponerat på webbsidan. Det skall även framgå ifall objektet sålts, när detta har skett och i så fall till vilket pris. Vidare skall diverse andra objektdata som till exempel pris per kvadratmeter, kostnad per kvadratmeter per år, kommun, område, boyta finnas med i tabellerna. 6

4 Implementation Programmet kommer att skapas som en webbapplikation. Anledningen till detta val är att företaget ska kunna använda programmet där dom befinner sig. Hade en klient/server Windows applikation skapats så skulle klienten behöva installeras på alla maskiner där företaget önskar komma åt informationen. Med en webbapplikation behöver bara en webbläsare finnas tillgänglig. Vidare valdes att programmet ska utvecklas i ASP.NET med C# på en IIS webbserver, då IIS var den webbserver som fanns tillgänglig hos företaget. Visual Basic kunde ha använts istället för C# men valet föll på C# av den enkla anledning att syntaxen är mer lätthanterliga. All kod har skrivits i Microsoft Visual Studio. Vid tester av programvaran har eventuella fel och crash information skrivits till debugfiler för att enkelt kunna se och reparera dessa. Detta har skett genom att använda try och catch block. Visual Studio genererar även automatiskt en sida med vad som gick snett om nånting gick snett, denna autogenererade sida har även använts för att hitta fel. Funktionalitet som skall köras kontinuerligt med vissa tidsintervall har testats genom att med korta tidsintervall köras över natten. Utomstående personer har även fått testa applikationen för att eventuellt hitta buggar. Figur 1 visar en översiktlig bild på hur alla delar i systemet hänger ihop. Alla dessa delar gås igenom senare i kapitlet. Figur 1 Översiktsbild av implementationen 7

4.1 Dataåtkomst 4.1.1 Hemnet Hemnet.se är en webbsida där man kan söka på saluförda boendeobjekt, det vill säga olika villor, lägenheter, tomter med mera som är till salu. Till varje objekt finns det mycket information tillgänglig som adress, boyta, utropspris och så vidare. Huruvida det är möjligt att använda denna information i den egna applikationen är ett problem som måste undersökas och lösas. Problem Webbsidan Hemnet.se lagrar sin information över saluförda objekt i någon form av databas. Problemet som måste lösas är hur denna information ska kunna lagras i en egen databas för applikationen, så att all objektinformation finns tillgänglig även när objekten inte längre finns kvar hos Hemnet, samt enkelt kunna söka efter gamla och nya objekt i den egna applikationen. Så problemet är alltså: Hur ska man kunna få tillgång till och använda i den egna applikationen, den information Hemnet.se tillhandahåller via sin offentliga hemsida. Lösning1 Den första iden som undersöktes var att man skulle få tillgång till Hemnets objektdata via XML (Extensible Markup Language)[14]. XML låter användaren identifiera data på ett mycket enkelt och flexibelt sätt. XML har inte förbestämda taggar som HTML utan man kan skapa dom som det passar. Ett exempel på hur XML kan se ut följer nedan. <?xml version="1.0"?> <ObjektKatalog> <objekt> <kommun>västerås</kommun> <adress>vasagatan 12</adress> <pris>350000</pris> </objekt> </ObjektKatalog> Till följd av flexibiliteten, strukturen och ordningen i en XML fil blir det mycket enkelt att plocka ut det data man vill ha. Fördelar Fördelarna med denna metod är många. Dels blir det väldigt smidigt då det finns inbyggda klasser i C# för att hantera och hämta data från en XML fil. Uppdateringar av objektinformationen kommer även att gå snabbt eftersom informationen tillhandahålls på ett strukturerat sätt. Nackdelar Den enda tydliga nackdelen med denna metod är att applikationens uppdateringar kommer vara beroende av att Hemnet fortsätter att tillhandahålla sin information som XML. Om Hemnet skulle besluta att inte ge ut XML längre så skulle uppdateringarna i den egna applikationen att sluta fungera. 8

Genomförande Efter flertalet samtal och e-post till Hemnet så beslutade dom att XML inte skulle lämnas ut på grund av principskäl. Vilket låter som att dom har sin information tillgänglig som XML men av principskäl inte vill ge ut den på det sättet, utan man får hålla sig till Hemnet.se där informationen finns tillgänglig. Detta medförde tyvärr att nämnd lösning inte var möjlig att genomföra. Slutsats Metoden hade varit bra och framtidssäker om tillgång till XML hade varit en möjlighet. Tillgång till XML nekades dock tyvärr vilket lämnar denna metod obrukbar. Lösning2 Eftersom all information som behövs finns tillgänglig på Hemnet.se, är en alternativ lösning att söka upp och läsa av en mängd html-sidor innehållande den information som söks. Fördelar Den enda riktiga fördelen med denna lösning är att ingen kontakt med Hemnet krävs för att det ska fungera. Metoden är heller inte beroende av att Hemnet kontinuerligt tillhandahåller information på ett visst format utan endast att dom har kvar sin hemsida någorlunda oförändrad. Nackdelar Uppenbara nackdelar är att metoden kommer vara något långsam då en stor mängd html sidor måste sökas upp och sedan filtreras på den information som söks. Samt att det finns en möjlighet att korrektioner måste göras i koden i det fall att Hemnet skulle bygga om sin hemsida. Genomförande Metoden är fullt genomförbar och kan genomföras på följande sätt. För att söka upp och hämta all information från Hemnet måste ett stort antal sökningar ske då det finns många objekt i många olika kommuner och län. En metod som kan används för att utföra en sökning är att använda sig av Hemnets URL 1 och olika variabler i densamma. Den URL som används ser ut som följer. http://www.hemnet.se/search/maklarutbud/npilista.asp?type=sok&service=hemnet&action=sok&caller=main&statisticsservice=hemnettodn&urval=1& area=14&kommun=112&kontraktid=1&boendegrupp=2&boendetypid=130&agandeformid=100,101,102,103,104,105,106&prismin=0&prismax=max&nrofrooms1=0&nrofrooms2=max&livingarea1=0&livinga rea2=max&avgiftmin=0&avgiftmax=max&prod=0&visning=no&daysago=max&pagesize=20&order=ko mmun,omrade&searchview=1&page=1& Den första delen av URL en innehåller inget speciellt utan bara parametrar för Hemnets sökmotor. http://www.hemnet.se/search/maklarutbud/npilista.asp?type=sok&service=hemnet&action=sok&caller=main&statisticsservice=hemnettodn&urval=1& Den andra delen innehåller de mest intressanta variablerna, dessa variabler bestämmer vilka objekt som kommer att visas som resultat av sökningen. Där area anger län, kommun vilken kommun, boendegrupp om det är villa, lägenhet eller tomt. Resten av 1) Uniform Resource Locator, Den globala adressen till dokument och andra resurser på Internet. 9

variablerna är förbestämda och är alltid samma för en viss boendegrupp. Som synes är län och kommun angivna med ett nummer. En textfil skapades innehållande varje kommun och län kod tillsammans med kommunens eller länets riktiga namn. Informationen i denna textfil separeras med ett komma mellan kod och namn och ny rad för ny kommun eller län. Anledningen att en textfil valdes istället för till exempel en tabell är att det helt enkelt var smidigt med en textfil och det fanns inget behov av en annan lösning. area=14&kommun=112&kontraktid=1&boendegrupp=2&boendetypid=130&agandeformid=100,101,102,103,104,105,106& Den tredje delen anger hur resultatet ska filtreras. Till exempel visa enbart objekt i ett visst prisintervall. För att få med så många objekt som möjligt per sökning sätts här alla variabler från minimum till maximum. En intressant variabel här är pagesize. Med pagesize kan man ange hur många träffar som ska visas per sida. För att slippa flera sidor per sökning kan man sätta denna variabel till ett högt värde. Tester som gjordes visade dock att denna variabel inte bör sättas högre än hundra då sökningar blev väldigt långsamma och till slut kraschade hemsidan. prismin=0&prismax=max&nrofrooms1=0&nrofrooms2=max&livingarea1=0&livingarea2=max&avgiftm in=0&avgiftmax=max&prod=0&visning=no&daysago=max&pagesize=20&order=kommun,omrade&sea rchview=1&page=1& Det ska även gå att på ett enkelt sätt ange vilka kommuner eller hela län som ska finnas med i uppdateringar av databasen. För att lösa detta skapades en fil med följande format. <catalog> <kommun>stockholm</kommun> <län>västmanland</län> </catalog> Metoden syftar till att det ska gå att lägga till eller ta bort län och kommuner i denna fil när som helst och på så sätt påverka vad som kommer att läggas in i databasen. Programmet läser in uppdateringsfilen där det finns angivet vilka kommuner och län som ska finnas med i uppdateringen. När en kommun ligger på tur i listan så hämtas kommunens nummerkod från en fil, även koden för det län som denna kommun ligger i hämtas från fil. Om ett län finns med i listan så utförs proceduren för kommuner på varje kommun i det länet. En URL för varje bostadstyp, villa, lägenhet, tomt skapas med den kommun och län kod som hämtats, denna URL kommer att visa en html sida med en tabell innehållande alla objekt som finns av den angivna bostadstypen i den angivna kommunen. En kontroll görs för att kolla om resultatet visas på flera sidor, i så fall skapas URL adresser för de sidorna också. Denna kontroll utförs genom att kontrollera en text på första sidan som lyder till exempel Sidan 1 av 3 eller Sidan 1 av 1. HTML källkoden för dessa URL adresser laddas sedan ner. Proceduren upprepas för alla angivna kommuner och län i uppdateringslistan. När en lösning för att hämta html källkod innehållande objekts data är färdig, måste källkoden filtreras och bara det data som ska användas ska hämtas ut. Tabellen innehållande objektdata har inget id men den har en unik CSS (Cascading Style Sheets)[15] klass som identifierar den. Tabellen identifieras då genom denna CSS klass och allt annat i källkoden utom denna tabell kastas bort. Resultatet blir en ensam html 10

tabell kvar av källkoden. Den resterande html tabellen innehåller dock cellformateringar, hyperlänkar och annan data som inte ska användas, så ytterliggare filtrering är nödvändig för att enbart den information som söks ska finnas kvar. All filtrering av källkoden sker med string klassen i C# och dess metoder. När filtreringen är klar har den resulterande tabellen följande format. <table> <tr> </tr> </table> <td>data</td> <td>data</td> <td>data</td> När tabellen nu är fint formaterad kan klassen System.Xml.XmlDocument användas för att läsa in tabellen som XML och enkelt hämta all data. Efter filtrering av data så läggs objekten in i en lokal databas. Vid varje inläggning till databasen så kontrolleras om objektet redan finns, i fallet att det redan fanns så läggs objektet enbart in om utropspriset har ändrats. Detta för att man ska kunna se olika priser ett objekt har haft under sin saluförda tid. Detta innebär att om priset på ett objekt har ändrats så kommer det objektet läggas in igen med nytt datum, det finns då två instanser av det objektet med olika pris och datum i databasen. Varje gång ett objekt hittas så uppdateras även senast sedd datumet, i och med det så kan man se när ett objekt senast sågs och när det försvann från hemnets hemsida. Databasen i sig är en Access databas. Access valdes på grund av att det är enkelt att skapa tabeller och jobba med denna databas samt att Värdia har licens på Office paketet och Access var därmed det som fanns tillgängligt. Slutsats Då XML inte längre var ett alternativ var denna lösning den enda möjliga. Metoden visade sig fungera bra och är inte bunden till att Hemnet tillåter dataåtkomst vilket man hade varit i en lösning med XML. Metoden är dock beroende av att Hemnet inte ändrar sin hemsida allt för mycket eftersom uppdateringarna då i värsta fall kan sluta fungera. Att Hemnet ändrar sin hemsida ses dock som en liten risk då den sett likadan ut väldigt länge. 11

4.1.2 VDPro VDPro är en Windows applikation i vilken man kan söka på sålda objekt av typen villa. Här kan man till exempel få reda på till vilket pris ett objekt såldes för, när det såldes och en hel del annan väsentlig information som fastighetsnamn och när objektet byggdes. VDPro är som sagt en Windows applikation och kräver en installation på varje dator man vill använda det på. I och med att VDPro inte är webbaserad så är det inte möjligt att filtrera webbsidor för att komma åt och använda VDPros data som gjordes för Hemnet, här uppstår ett problem som måste lösas. Problem Hur ska man få tillgång till den objektinformation som applikationen VDPro tillhandahåller utan att använda sig av applikationen i fråga, för att kunna använda denna objektinformation i den egna applikationen. Det finns inga förutsättningar för att detta skall vara möjligt. Värdia betalar för att genom VDPro få tillgång till det objektinformation som söks. Det finns inget som säger att direkt tillgång till VDPros data är möjligt utan användning av VDPro. Detta måste undersökas på egen hand. Lösning En bra start är att undersöka hur applikationen VDPro fungerar och dess uppdateringar. I och med att all information finns tillgänglig i VDPro utan att ha en Internetuppkoppling tillgänglig, så kan man dra slutsatsen att en intern databas används. Det vill säga programmet hämtar inte sina sökresultat från en server någonstans utan har allting lagrat lokalt. Det visar sig vara korrekt att VDPro använder sig av en intern databas för att lagra objektinformationen, formatet på databasen som används är cdx/dbf. Detta är för mig, författaren av denna rapport ett okänt format, men det verkar som om cdx filen är någon sorts headerfil till dbf filen som innehåller datat. Att det finns en lokal databas tillgänglig hjälper dock inte till att lösa problemet, då om man skulle använda sig av denna skulle det egna programmet vara beroende av att man uppdaterade VDPro för att sedan kunna använda dess lokala databas. Den andra slutsatsen som kan dras är att när en uppdatering sker så måste objektinformationen hämtas från Internet och sedan lagras lokalt, alltså finns objektinforationen på ett eller annat sätt tillgänglig någonstans på Internet. Genom att undersöka uppdateringsfunktionen i VDPro ytterligare går det med ett snabbt öga att upptäcka adressen till den första filen som hämtas ner. Filen som adressen leder till är komprimerad och innehåller en textfil. Genom att undersöka denna textfil går det snabbt att upptäcka att den innehåller en lista över en stor mängd Internetadresser till fler filer. Filerna som listan länkar till har alla ändelsen.imp men det visar sig vara vanliga textfiler i alla fall. Varje fil innehåller en hel del information, det är inte helt tydligt om detta är information över sålda objekt till en början, men efter lite närmare undersökning visar det sig att så är fallet. Eftersom det nu finns ett sätt att hämta objektinformation utan användning av VDPro bör det gå att använda sig av denna i den egna applikationen. Fördelar Ingen användning av VDPro behövs för att få tillgång till informationen som behövs. Metoden är stabil och relativt framtids säker. Då uppdateringar i VDPro förmodligen sker på ett mycket likt sätt är risken liten att strukturen på impfilerna ändras. 12

Nackdelar Det finns inga direkt uppenbara nackdelar. Genomförande Till att börja med är det en bra ide att studera imp filerna och ta reda på huruvida det går att tyda informationen som dessa innehåller. Strukturen på en imp fil ser ut som följande. 01;6516060;20050805;11;20050630;3030;01;220;01;14;6599359;1621442;788;1665;10;0;99;22612;366 ;0;0;0;100;1;0;1;134;154;788;558;1107;0;0;0;0;0;0;0;0;0;0;1665;1,82;22612;19675;3845,18;0 01;6516077;20050805;11;20050630;2325;01;220;01;14;6602649;1621056;820;1446;10;0;99;21528;366 ;0;0;0;100;1;0;1;108;128;820;503;943;0;0;0;0;0;0;0;0;0;0;1446;1,61;21528;18164;2835,37;0; 03;6516060;5;0;0,00;03 03;6516077;1;0;0,00;03 06;6516060;1;1;BERGKLINTVÄGEN;7;BOLLSTANÄS 06;6516077;1;1;VADAGRÄND;4;VIK 17;6516060;1724570005;41;1;788;01;11;05;01 17;6516077;1682120005;41;1;820;01;11;05;01 Som synes är det vid första anblick inte speciellt enkelt att veta vad som är vad i virrvarret av siffror, andra saker som till exempel adressen är lättare att identifiera direkt. Den enda möjligheten att få reda på vad alla siffrorna motsvarar är att lista ut det själv, det finns ingen manual eller support till förfogande. Den enda metoden för att ta reda på vilken information i imp filerna som motsvarar vad är helt enkelt att ladda ner ett stort antal imp filer. Sedan söka upp all de objekt som fanns i varje imp fil med progammet VDPro, detta går att göra i och med att gatuadressen går att identifiera för varje objekt. Till slut får man jämföra objektinformationen i VDPro med den informationen som står i imp filerna för att komma fram till vad varje siffra motsvarar. Varje siffras betydelse kommer inte att gås igenom, utan bara en ytlig beskrivning av strukturen på imp filerna. Ett objekts information är uppdelad i flera olika grupper inne i imp filen, till exempel så finns alltid information om pris, datum, boyta och så vidare i grupp ett och adress, ort med mera i grupp sex. Vidare är varje grupps information separerad med ett semikolon. Det första talet på varje rad anger vilken grupp av information raden tillhör. Börjar raden på till exempel 01 så betyder det att detta är grupp 01 av information. Alla rader som börjar på 01 i alla imp filer innehåller samma typ av information fast för olika objekt och alla rader som börjar på 03 innehåller samma sorts information och så vidare. Det andra talet på varje rad är objektets unika identifieringsnummer. Alla rader med samma identifieringsnummer innehåller information för samma objekt. Vidare innehåller varje impfil information för alla sålda objekt i en viss kommun på ett visst datum. Varje impfils namn innehåller dessutom id numret för den kommun vars objekt den innehåller. Eftersom det går att tyda och särskilja information i en impfil och det finns en lista med länkar till alla tillgängliga impfiler så går det att ladda ner alla impfiler och hämta informationen i dom samt lägga in i en egen databas. Listan med länkar till alla impfiler är komprimerad som en zipfil. Det finns inga klasser i C# som tillåter läsning av en zipfil. För att lösa detta har SharpZipLib[3] använts som bland annat tillåter läsning av zipfiler, vilket också är det enda som SharpZipLib använts för i detta projekt. Varje impfil innehåller endast objekt för en kommun och alla kommuner har ett unikt id att identifieras med, så det går även att filtrera vilka kommuner man vill ha med i sin 13

databas. För att ange vilka kommuner som ska vara med i uppdateringen av databasen har en XML fil på följande format använts. Filen kallas vdpuppdatera.xml. <catalog> <kommun> <id>0114</id> <namn>upplands-väsby</namn> </kommun> <kommun> <id>0115</id> <namn>vallentuna</namn> </kommun> </catalog> Det är id taggen för varje kommun som är det väsentliga här, det är detta id som används för att välja ut vilka impfiler som ska hämtas vid en uppdatering, i och med att detta id finns med i impfilens filnamn. Namn taggen för varje kommun är enbart där för att hjälpa användaren att enklare kunna identifiera vilken kommun som id numret tillhör. I det fall att användaren vid ett senare tillfälle vill ta bort en kommun från listan så hjälper namnet till att enkelt finna den kommun man vill ta bort. När en uppdatering körs kommer alla impfiler för varje kommun som är specificerad i filen vdpuppdatera att laddas ner. Dock laddas bara en fil i taget ner, och nästa fil kommer att skriva över den första så det finns alltid bara en fil på serverns hårddisk som mest. Varje impfil som laddas ner kan innehålla flera objekt. All relevant informationen för varje objekt i den aktuella filen filtreras ut och sparas undan i temporära behållare. Detta är relativt enkelt då man vet strukturen på impfilen samt det faktum att all information är separerad med semikolon. Om man till exempel ska ha tag på priset för det första objektet så vet man att denna information ligger på den första raden som börjar med 01 och efter det fjortonde semikolonet. Så då är det bara att identifiera 01 raden och sedan gå till det fjortonde semikolonet. När all objektinformation har lästs in från impfilen så läggs objekten in i databasen. Vid varje objekt som läggs in i databasen görs även en kontroll om detta objekt inte redan fanns. Om objektet redan fanns så läggs det inte in i databasen igen för att förhindra dubbletter. Fanns det däremot inte i databasen så läggs det in. Alla kommuner och alla områden i kommunerna motsvaras med en kod i det data som läses in från impfilerna. En kod är inte optimalt för att beskriva en kommun eller ett område, ett namn är mycket tydligare. Av denna anledning översätts alla kommun och områdes koder till dess motsvarande namn innan dom läggs in i databasen, detta sker genom att läsa från en lista där alla kommuners och områdens koder finns angivna tillsammans med dess motsvarande namn. Hela proceduren för att läsa in en impfil upprepas sedan för varje impfil som laddas ner. Slutsats Efter en noggrann undersökning av hur programmet VDPro och dess uppdateringar fungerar visade det sig att det gick att hämta objektinformation oberoende av programmet VDPro. Man är dock bunden till den lösning som har använts då informationen inte finns tillgänglig på något annat sätt, såvida man inte vill köra uppdateringarna i själva VDPro och sedan använda sig av dess lokala databaser. Den lösningen är dock mindre optimal då man går miste om uppdateringsautomatik eftersom alla uppdateringar i VDPro måste ske 14

manuellt. Man är dessutom beroende av programmet VDPro och möjligheten att göra en helt separat applikation försvinner. Den lösning som har använts är dock inte dålig på något sätt. Om man jämför tiden det tar att göra en uppdatering i VDPro med tiden det tar att göra en uppdatering med den lösning som presenterats så går det lika snabbt eller snäppet snabbare med den presenterade lösningen. Inget agerande från Värderingsdata som tillhandahåller programmet VDPro har krävts för att få denna metod att fungera. 4.1.3 Automatisk uppdatering Nackdelen med att uppdatera information manuellt är att man inte alltid har koll på när den senaste uppdatering gjordes och det är möjligt att man glömmer uppdatera då och då. Säg att en användare har glömt att uppdatera eller inte haft möjlighet att uppdatera sin information. När denna användare nästa gång ska söka upp ny information kommer informationen inte existera, vilket leder till att han måste uppdatera vid det tillfälle han märker att informationen är förlegad. Om en uppdatering dessutom tar tid på sig så får användaren sitta där och vänta ett bra tag innan han kan fortsätta med vad han höll på med. Om alla uppdateringar sker automatiskt med ett visst tidsintervall så kommer detta scenario aldrig att inträffa. För att implementera automatiska uppdateringar kan man använda sig av så kallade timers[8]. En timer kan användas för att exekvera en viss händelse efter en viss tid. I C# går det även att ställa in så att timern nollställer sin räknare och börjar räkna igen efter att händelsen inträffat, detta medför att man kan få en händelse att inträffa kontinuerligt med ett visst tidsintervall. Det som däremot inte går är att få timer att köra sin händelse vid ett visst klockslag varje dygn. Om man vill att timern ska köra sin händelse vid exakt klockan 14:00 varje dygn så måste man i så fall se till att timer startar vid exakt klockan 14:00 och sedan ställa in den på tjugofyra timmars intervall. Detta är ju dock inte en bra lösning. Antag till exempel att servern som programvaran med timern ligger på måste startas om eller kraschar klockan 15:00, då måste administratören vänta tjugotre timmar innan han kan starta timern igen för att få den att köra klockan 14:00. För att undvika detta problem kan man använda sig av en lösning med två stycken timers. Genom att använda sig av två stycken timers kan man åstadkomma en lösning som klarar av att utföra en händelse på ett visst klockslag med ett visst tidsintervall, till exempel klockan 03:00 varje dygn. Det första som händer är då att räkna ut hur lång tid det är kvar från nuvarande klockslag till det klockslag som angivits för att köra händelsen. När detta är gjort så startar man den första timern och ställer in den på att exekvera sin händelse om så lång tid som det va kvar till det angivna klockslaget. Denna timer ställs även in på att inte nollställa sin räknare så den bara kör en enda gång. Den händelse som den första timern exekverar är att den startar timer nummer två. Timer nummer två kommer då att starta på exakt det klockslag som var angivet. Vidare ställer man in intervallet för timer nummer två till tjugofyra timmar och att den ska nollställa sin räknare och börja om igen när den är klar. Den händelse som timer nummer två exekverar är uppdatering av information. Så med denna lösning kommer informationen att uppdateras varje dygn på angivet klockslag. Detta är också den metod som används i detta projekt. 15

4.2 Användargränssnitt För att lätt kunna visa och söka bland alla objekt som lagras i databaserna behövs ett användargränssnitt. För att det lätt ska gå att söka i databaserna var man än befinner sig så bör användargränssnittet vara webbaserat. Med ett webbaserat användargränssnitt behöver det bara finnas en webbläsare tillgänglig på den dator man använder för att kunna använda applikationen och ingen installation av mjukvara är nödvändig. Detta är mycket bra om man inte sitter vid sin egen dator men behöver komma åt applikationen där man befinner sig. 4.2.1 Hemnet En bra start för att kunna begränsa sökningen från att visa allt i hela databasen är att kunna välja vilket län och kommun som objektet eller objekten man söker finns i. Till detta kan man använda så kallade rullgardinsmenyer. En rullgardinsmeny tar inte mycket plats men den kan i alla fall innehålla många alternativ. När man sedan klickar på rullgardinsmenyn så vecklas den ut och allt data den innehåller visas i en lista där man sedan kan klicka på den post man vill markera. Detta är ett bra val av komponent för markering av vilket län och kommun man vill söka på. För att det inte ska finnas överflödig information i rullgardinsmenyn där man väljer län och för att undvika sökningar på sånt som inte finns med i databasen kan man fylla rullgardinsmenyn med just dom län som finns i databasen för tillfället. Detta genomförs enkelt genom att göra en sökning i databasen efter alla län och exkludera dubbletter. Sedan infogar man dessa län att visas i rullgardinsmenyn. När användaren har valt vilket län han vill söka på är det en bra ide att bara visa dom kommuner som finns i det valda länet i den rullgardinsmeny där man väljer kommun. Detta är också en enkel uppgift som går att lösa genom att göra en sökning i databasen på kommuner som finns i det valda länet. En sån sökning görs enkelt med hjälp av SQL och kan se ut så här. SELECT DISTINCT Kommun from Table WHERE Län= valt län Ordet DISTINCT betyder att man inte vill ha med några dubbletter i sökningen och Table är den tabell man vill söka i. I och med att rullgardinsmenyerna för län och kommuner fylls på detta sätt så kommer dom alltid att innehålla bara dom län och kommuner som finns i databasen, helt dynamiskt. Vidare vill man kunna söka på ett område och en gatuadress. Här kan det vara en bra ide att använda sig av vanliga textrutor där man kan fylla i valfri text. Anledning till detta är att det finns väldigt många områden och ännu fler olika gatuadresser att välja mellan, så en rullgardinsmeny eller någon annan komponent med fördefinierade alternativ skulle bli extremt svårnavigerad. Nackdelen med fritextsökning är dock att man måste veta vad området eller adressen heter. För att underlätta detta går det att söka på delar av namn, till exempel Kallhäll kan anges som Kall eller häll. Om användaren inte är ute efter ett speciellt objekt utan snarare en klunga av objekt krävs det fler sökkriterier för att minimera sökningar ytterligare. Pris, boyta, antal rum, hur lång tid som gått sen objektet blev inlagt är utsökta alternativ att utöka sökkriterierna med, även månadsavgift för bostadsrätter är bra att ha med. Här är det återigen önskvärt att använda sig av rullgardinsmenyer för att ange de olika kriterierna. För att kunna ange ett intervall för varje sökalternativ kan två stycken rullgardinsmenyer användas, den ena för att ange intervallets start och den andra för att ange intervallets slut. Där användaren 16

anger intervallets slut bör det även gå att ange oändligheten så att man som exempel kan söka på priser från 700 000kr och allt däröver. När man ska ange hur gamla objekt man vill ha med i sökningen är den första tanken som kommer upp förmodligen att ett till och från datum ska kunna anges. Vid närmare eftertanke är detta dock inte en optimal lösning för ändamålet, då detta medför att användaren för det första måste kontrollera dagens datum och sedan räkna datum bakåt för så många dagar han vill ha med i sin sökning. En sökning på en mängd av objekt alla inlagda en lång tid tillbaka kommer sällan att ske, och om så skulle behövas är de övriga sökkriterierna fullt tillräckliga för minimera resultaten och hitta vad man söker. En bättre lösning är därför att med hjälp av en rullgardinsmeny kunna ange hur många dagar tillbaka i tiden sökningen ska visa objekt av, till exempel objekt inlagda för senast 14 dagar sen. Eftersom objekt kan vara av många olika typer så som villor, fritidshus, gårdar, bostadsrätter, hyresrätter och tomter måste det gå att filtrera ut vilken typ man vill söka på. Ett snabbt och enkelt sätt att välja vilken typ av objekt man vill söka på är att använda sig av så kallade kryssrutor. En kryssruta blir markerad om man klickar på den och avmarkeras om man klickar igen, på så sätt kan man snabbt och enkelt välja vilka typer av objekt som ska vara med i sökningen genom att klicka i en eller flera kryssrutor. Det var även önskvärt att det inte skall gå att söka på vissa typer samtidigt. Villor, fritidshus och gårdar skall inte gå att kryssa i samtidigt som bostadsrätter och hyresrätter inte heller samtidigt som tomter och vice versa. Detta löses mycket enkelt med hjälp av JavaScript. Ett simpelt JavaScript tillför funktionaliteten att när man klickar på någon av dom typer som inte skall gå att söka på tillsammans med den eller de typer som redan är förkryssade så avmarkeras automatiskt den eller de typer som är otillåtna. 4.2.2 VDPro För att söka i databasen över sålda objekt behövs även här ett användargränssnitt. För att det enkelt ska gå att söka på både objekt till salu och objekt som är sålda samtidigt. Samt eventuellt jämföra ett specifikt objekts saluförda pris med vad det såldes för så bör gränssnittet för att söka på sålda objekt visas på samma sida som det för saluförda objekt. Resultaten för respektive sökning bör även visas på samma sida. Bilden nedan visar hur användargränssnittet för sökningar i de båda databaserna har gjorts i detta projekt. Anledningen till att samma objekt inte söks upp i båda databaserna med en enda sökning, utan en separat sökning i var och en av databaserna är nödvändig, är att det blir jobbigt i längden då man inte bara använder applikationen för jämförelser mellan databaserna. Söker man till exempel ett objekt i VDPro databasen blir det jobbigt om även Hemnets resultat kommer upp varje gång. Databaserna har dessutom inte identiska sökkriterier. 17

Figur2 Applikationens användargränssnitt som används för att söka i databaserna. Precis som i användargränssnittet för saluförda objekt så används en rullgardinsmeny för att specificera vilken kommun man vill söka på i användargränssnittet för sålda objekt, det går även att välja alla kommuner. Det går inte att ange ett län att söka på och det är för att det inte finns någon information om län i databasen över sålda objekt. Detta är dock ingen större nackdel då man ofta vill minimera sökningar till åtminstone kommun nivå för att få färre sökträffar att gå igenom. För att söka på församling och gatuadress så används fritextsökning, detta för att det finns oerhört många olika alternativ att välja på här och statiska alternativ skulle vara alldeles för jobbigt att leta igenom. Församling är en annan benämning på område till exempel Gåsmyren. VDPro använder sig av denna benämning istället för att säga område, därför har det även använts här för att användare av VDPro programmet ska känna igen sig. Det går även att söka på delar av ett områdes namn eller en del av en gatuadress namn. Till skillnad från databasen över saluförda objekt där man angav hur många dagar tillbaka i tiden man villa att sökningen skulle visa resultat ifrån genom att välja i en rullgardinsmeny, så får man ange ett tidsintervall när man söker i databasen över sålda objekt. Detta sker genom att ange ett från datum och ett till datum som sökningen ska visa resultat från. Denna lösning är något mer tidskrävande för användaren än den för objekt till salu i och med att man manuellt måste skriva i två fullständiga datum för att kunna göra en datum specificering. Anledningen att man här kan specificera vilket eller vilka datum som ska visas i sökningen är att det är sålda objekt man letar efter här, det är en större sannolikhet att man här vill söka upp gamla objekt utan att han ett speciellt objekt i åtanke än vad det är för objekt som är till salu. Därför är det en befogad kompromiss med ett lite jobbigare handhavande när man anger datum att söka på. För att specificera köpesumma och boyta i sin sökning har rullgardinsmenyer använts, en för från och en för till, detta är samma lösning som använts till användargränssnittet för objekt till salu. I databasen över sålda objekt finns något som kallas typkod för varje objekt. Typkoden anger vad för sorts typ detta objekt är. Till exempel kan ett objekt vara småhusenhet fritidsbostad för 1-2 familjer, småhusenhet helårsbostad för 1-2 familjer, småhusenhet tomtmark och så vidare. För att ange vilken eller vilka typkoder man vill söka på används en listbox. Som synes i Figur2 visar en listbox flera alternativ samtidigt, det går även att scrolla ner för att komma åt resten av alternativen. En listbox tar väsäntligt mer plats än en rullgardinsmeny, men det går att välja fler än ett av alternativen i en listbox. För att välja ett alternativ i listboxen klickar man på det med musen. Vill man sedan välja flera alternativ är det bara att hålla in ctrl på tangentbordet och klicka på alla alternativ man 18

vill ha med. Man kan även markera en rad av alternativ genom att klicka på det första alternativet man vill ha med sedan hålla in shift på tangentbordet och sedan klicka på det sista alternativet, alla alternativ däremellan kommer då att bli valda. Detta är samma metod som används i Windows utforskaren för att markera filer. För att avmarkera allt man har markerat högerklickar man i listboxen, detta är inte standardbeteende för en listbox utan funktionaliteten har lagts till genom ett enkelt JavaScript. Detta JavaScript känner av om ett högerklick gjordes i listboxen varpå det rensar allt som var markerat. Anledningen till att den här funktionaliteten lades till var att det inte fanns något sätt att rensa listboxen, utan ett alternativ var alltid markerat efter att man klickat i den en gång. Alternativet hade varit en tom cell eller en alla cell högst upp, men den valda lösningen bedömdes som snyggare. 19

4.3 Presentation av data All information som presenteras hämtas från de lokala databaserna. Dessa databaser innehåller endast en tabell var, det vill säga alla objekt i en databas ligger i samma tabell. Detta för att olika bostadstyper i Hemnet databasen har väldigt få kolumner som skiljer dem åt och för att det blev smidigt att hantera objekten på detta sätt. I den lokala VDPro databasen har alla objekt samma kolumner vilket medför att fler än en tabell vore bara dumt. 4.3.1 Använda en datagrid Efter att man gjort en sökning måste resultaten visas på något sätt, det optimala redskapet för att visa denna typ av data är naturligtvis en tabell med kolumner och rader. För detta ändamål kan en datagrid användas. En datagrid är en serverkontroll som finns tillgånglig i ASP.NET. Det finns många konfigurationsmöjligheter för utvecklaren att ställa in med hjälp av enkla menyer i en datagrid. Såsom färger, visa resultatet på flera sidor, antal resultat per sida, teckensnitt och så vidare. En datagrid kan även bindas till att visa de poster som man sökt upp i en databas. När html sidan som datagriden ligger på sedan byggs upp kommer en html-tabell innehållande de poster man sökte upp i databasen att genereras med formateringar motsvarande de man ställde in med menyerna. Det finns även nackdelar med datagriden. Vissa saker går inte att göra och allt går inte att ställa in, det kan därför vara en ide att själv lägga till de saker man saknar genom att göra en egen datagrid komponent som ärver av originalet. 4.3.2 Datagridar och tabell sortering på klientens sida För att kunna sortera en tabell snabbt och utan anrop till servern så krävs det att sorteringen utförs med JavaScript. Det finns ett relativt väl fungerande JavaScript för tabell sortering som heter Sortable Table[9] skapad av Erik Arvidsson. För att detta JavaScript ska kunna sortera en tabell så krävs det att tabellen är skapad med THead, TBody och TFoot taggar. Tabellen identifieras av JavaScriptet genom tabellens unika id. Det går sedan att klicka på tabellens kolumnrubriker för att sorter efter den kolumnen. Sorterting sker på klientens sida och går mycket snabbt, detta är förstås mycket bättre än att göra ett anrop till servern och sortera och sedan ladda om sidan med den sorterade tabellen. En datagrid i Visual Studio bygger upp sin tabell utan THead, TBody och TFoot taggar. Detta medför att Erik Arvidssons JavaScript för sortering inte kommer att fungera på en datagrid. Det finns två alternativa lösningar på detta problem, den första är att skriva om javascriptet så det fungerar på en datagrid vilket kan vara problematiskt om man inte är väldigt duktig med JavaScript. Den andra lösningen är att skriva om datagriden så den fungerar med javascriptet. Lösning nummer två har valts för detta projekt. Hos Microsoft Development Network[1] finns det ett exempel på hur man kan göra sin egen datagrid genom att ärva från standard datagriden och överlagra dess render metod, vilket är metoden som skapar html tabellen. När datagridens html tabell skapas görs en kontroll om det är rubriker för tabellen som skapas, i detta fall så omsluts den genererade html koden för rubrikerna med THead taggar. Samma procedur utförs för tabellens kropp och fot. På så sätt får datagridens html tabell ett kodmössigt utseende som är nästan fullt kompatibelt med Erik Arvidssons Sortable Table JavaScript. Det finns dock ett problem till med datagriden som måste lösas. En Visual Studio datagrid kan ha varierande CSS klasser för varannan rad i tabellen, detta för att till exempel kunna åstadkomma en tabell 20