Klientprogrammering:Laboration

From Juneday education
Jump to: navigation, search

Om innlämningsuppgiften

Version: Klientprogrammering och Systemintegration - YRGO 2017

Bakgrund

Som examination av kurserna Systemintegration och Klientprogrammering, Java Enterprise-utvecklare 2017, ska eleverna lösa denna obligatoriska laboration.

Laborationen (inlämningsuppgiften) innehåller moment som är hämtade från målen i respektive kurs kursplan.

Moment i laborationen från respektive kurs

Från kursen Klientprogrammering är följande mål integrerade i laborationen:

  • Arbeta med strukturerad programmering för att göra koden överblickbar och hanterlig
  • Kommunicera med ämnesrelaterad terminologi
  • Beskriva tekniska skillnader mellan olika gränssnitt
  • Planera struktur, funktioner och gränssnittsdesign
  • Hantera händelser
  • Felsöka och lösa problem
  • Anpassa applikationsutveckling för olika plattformar
  • Skriva säker kod med avseende på
    • Indatakontroll
    • URL‐kontroll
    • Datatypskontroll (och Datumkontroll)

Från kursen Systemintegration är följande mål integrerade i laborationen:

  • (hur man) skapar xmldokument
  • (hur man) tar emot, packar upp, verifierar dokumentet mot ett schema
  • felhantering, importhantering

Beskrivning av laborationen

Tanken med laborationen

Tanken är att vi skall göra en klient och en server. Servern skall hantera lagring av studenter samt vilka kurser studenterna är registrerade på och presentera detta via ett API för XML och JSON. Servern skall implementeras som en Java-servlet med JDBC-kopping till en databas (SQLite3) och implementera någon form av lagrad arkitektur. Teknisk beskrivning av laborationen

Klienten skall implementeras i Android och interagera med servern. Som överkursutmaning skall klienten kunna mellanlagra data i fall nätverket går ner.

Teknikerna som används är centrerade kring Java men låter er samtidigt inrikta er på API:er som används i industrin (Android, XML, JSON, JDBC). I laborationen används också så kallade designmönster, t ex Singleton och någon form av en Factory.

Mål med laborationen

Ett mål när vi tog fram uppgiften var att ge er något att visa upp eller kunna beskriva för potentiella arbetsgivare (och/eller LIA-platsanordnare). Vi vet att det är viktigt i dag att kunna visa upp vad man gjort (i kod och dokumentation) och vi hoppas att detta höjer er motivation att prestera samt arbeta med laborationen.

Kursmässigt innehåller laborationen väsentliga delar av lärmålen från kursplanerna i kurserna Klientprogrammering och Systemintegration och passar därför bra som en kursövergripade laboration för examinering av bägge kurserna.

Vi har märkt att arbetet med en längre laboration som sträcker sig över hela terminen upplevs som stimulerande för elever i det att varje teoretisk del i kurserna ingår i ett större sammanhang i en laboration som byggs på och utvecklas stegvis mot ett fungerande system. När vi använt detta upplägg tidigare har vi fått återkoppling från eleverna om att det var bra att laborationen hänger ihop och formar ett mer realistiskt system som växer fram, jämfört med mindre isolerade övningar som inte hänger ihop tematiskt.

Uppgiften är indelad i obligatoriska och icke-obligatoriska delar. Vi valde detta för att underlätta betygssättning samt för att erbjuda utmaningar för dem som vill ha lite mer att arbeta med samtidigt som de som siktar på G ska ha en rimlig chans att klara kurserna.

Nyckelord (att lägga i CV)

Java, Servlet, Android, HTTP, Nätverk, Bash, Test, Json, XML, Databas, SQLite, JDBC, Singleton, Factory, lagrad arkitektur, Exception-hantering, client-server, REST, API:er, Full stack.

Server-delen

Laborationen består av två delar - en server-del som publicerar data via ett API som ni skriver själva, och en klient-del som består av en Android-app som hämtar data från server-delen via internet och ert API.

Serverdelen skall vara en eller flera Java-Servletar som publicerar ett API för att hämta data. Serverdelen skall hämta data via JDBC från en databas (med studenter och kursregistreringar) på servern och publicera dessa data som Json och/eller XML. Att publicera data via ett webbaserat API visar på ett sätt att integrera en backend med en eller flera klienter. Att överföringen av data sker med XML eller Json som kodning av data visar på hur ni skapar en abstraktion (och ett oberoende) mellan datakälla och klienterna som konsumera data.

Serverfunktionalitet

Servern skall publicera data till klienten. Detta sker förslagsvis över HTTP med GET-anrop från t ex en Android-klient. Ni kan därför implementera ett student-api för åtkomst av student-data med hjälp av en eller flera servletar. Ni kan använda ett enkelt protokoll/api till exempel räcker det med två GET-parametrar, id respektive format .

För att få en lista på studenter med namn och id kan man svara på anrop med id=all och för att få data om kurser för en student med ett visst id kan man sätta id-värdet så att man istället för id=all till exempel frågar efter id=2 (för att få kursdata om studenten med id 2).

För att er server skall kunna servera klienten svar i XML eller Json så kan ni skicka med en andra GET-parameter, format till exempel format=json. Databasschema (för databasen på servern)

CREATE TABLE students(id integer primary key asc,
                      name varchar(30));
CREATE TABLE courses(id integer primary key asc,
                     course_code varchar(12));
CREATE TABLE registrations(student_id int(8),
                           course_id int(8));

Server-api för åtkomst av studentdata

Er server skall erbjuda följande API för åtkomst av data om studenterna och dessas kursregistreringar.

Json-data från servern

Server-API:et skall klara av att svara med Json t ex enligt specifikation här: StudentAPI

XML-data från servern

För XML skall servern klara av att generera XML t ex enligt följande två exempel:

Alla studenter (t ex anropet /student-api?format=xml&id=all ):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<STUDENTS>
  <STUDENT id="1">
    <NAME>Anders Andersson</NAME>
  </STUDENT>
  <STUDENT id="2">
    <NAME>Beata Bengtsson</NAME>
  </STUDENT>
  <STUDENT id="3">
    <NAME>Charlie Christensen</NAME>
  </STUDENT>
  <STUDENT id="4">
    <NAME>Dick Dale</NAME>
  </STUDENT>
  <STUDENT id="5">
    <NAME>Edward Eriksson</NAME>
  </STUDENT>
</STUDENTS>

Kurser för student med ID 2 (t ex anropet /student-api?format=xml&id=2 ):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<COURSES studentID="2" studentName="Beata Bengtsson">
  <COURSE>TIG058</COURSE>
  <COURSE>TIG059</COURSE>
</COURSES>

Övrigt

Ni får naturligtvis hitta på egna standarder för dataöverföringen, så ovanstående är bara förslag från vår sida. Huvudsaken är att Android-appen (klienten) skall kunna hämta data över nätet från er server-backend. Krav är dock att ni ska få data i XML och Json (på bägäran från klienten, dvs servern skall kunna servera båda formaten utifrån vad klienten frågar efter).

Kodexempel för Servletarna

Servlet-intro

Wiki-kapitel:

  • Introduction to Winstone
  • Exercise - Introduction to Winstone
  • Dispatcher - servlet som väljer mellan xml och json TODO
  • RequestDispatcher - servlet som gör själva forward TODO
    • XMLOrJson.java TODO
    • Json-servlet - som tar hand om Json om formatet var json TODO
    • JsonDummy.java TODO
    • XML-servlet - som tar hand om XML om formatet var xml TODO
    • XMLDummy.java TODO

Föreläsningsbilder:

  • RequestDispatcher.pdf TODO

Kodexempel för Java och Json

Föreläsningar

Kodexempel för Java och XML

Föreläsningar

Datalagret på servern

Ett icke-funktionellt krav är att Servletarna inte ska kunna komma åt data direkt från databasen. Det innebär att ingen JDBC-kod får förekomma i servletklasserna. Skapa i stället ett interface för dataåtkomst som returnerar data i form av någon datatyp ni själva skapar.

För alla studenter rekommenderar vi att interface:et har en metod getAllStudents() som returnerar en List<Student>. En Student kan vara en enkel klass med name och id.

För listan på kurser för en student, så föreslår vi att ni hämtar en student via en metod i interface:et som heter getStudentById(int id) som då returnerar en Student utifrån givet id. En metod för själva listan på kurser behövs också getCoursesFor(int id) som returnerar en List<Course> med kurs-objekt. Course kan vara en enkel klass som bara innehåller courseCode (t ex “TIG015” eller vilka kurskoder ni hittar på).

Servleten kan då på frågan efter kurser för ett visst id först skapa en Student via anrop till getStudentById(int id) och sedan hämta en List<Course> via getCoursesFor(int id). Därifrån kan Servleten skapa antingen ett Json-dokument eller XML-dokument via lämplig hjälpklass. Diskussion om detta kommer och vi lägger in en rekommenderad lösning här när vi gemensamt valt design.

För den som vill ha lite hjälp, så kommer här student-tabellen:

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE students(id integer primary key not null, name text not null);
INSERT INTO "students" VALUES(1,'Anna Andersson');
INSERT INTO "students" VALUES(2,'Beata Bengtssson');
INSERT INTO "students" VALUES(3,'Cecilia Carlsson');
INSERT INTO "students" VALUES(4,'David Davidsson');
INSERT INTO "students" VALUES(5,'Erik Eskilsson');
INSERT INTO "students" VALUES(6,'Fader Fourah');
COMMIT;

Och courses:

CREATE TABLE courses(id integer primary key asc,course_code varchar(12));
INSERT INTO "courses" VALUES(1,'TIG015');
INSERT INTO "courses" VALUES(2,'TIG058');

Och registrations:

CREATE TABLE registrations(student_id int(8), course_id int(8));
INSERT INTO "registrations" VALUES(1,1);
INSERT INTO "registrations" VALUES(1,2);
INSERT INTO "registrations" VALUES(2,2);
INSERT INTO "registrations" VALUES(3,1);
INSERT INTO "registrations" VALUES(4,1);
INSERT INTO "registrations" VALUES(4,2);
INSERT INTO "registrations" VALUES(5,2);

Notera dock att det vore bra om tabellerna hade foreign key till de kolumner som refererar till andra tabeller så att ni inte får in dåliga data. Det är upp till er hur noga ni vill implementera tabellerna och databasen. Vi rekommenderar noggrannhet men då detta inte är en databaskurs, så är det upp till er.

Betygskrav på server-delen

Obligatoriska krav (G)

För godkänt så måste servern kunna svara på frågor om alla studenter respektive kursinformation om en student. Servern skall kunna servera data i Json eller XML (vilket format som serveras skall styras av anropet). Data skall komma från en databas men servlet-koden skall inte innehålla någon databasspecifik kod.

Kod skall vara skriven i konsekvent stil (gärna enligt t ex Googles kodstandard) och korrekt samt konsekvent indenterad. Avsnitt som inte är självförklarande skall kommenteras på engelska. Alla klass- interface, metod- och variabelnamn skall vara på engelska. Det skall vara möjligt för lärarna att bygga projektet från kommandoraden enligt era anvisningar (vilka bifogas inlämningen).

Frivilliga krav (VG)

Servern skall använda en factory för att skapa en komponent för rätt utmatningsformat (Json eller XML). Servern skall svara med korrekta HTTP status-koder enligt API-beskrivningen (200 OK, 400 Bad Request, 404 Not found) för att signalera till klienter om anropet lyckades. Vid fel så skall felmeddelanden levereras i respektive format (Json eller XML). Det skall vara möjligt att lägga till ett format, t ex CSV utan att behöva kompilera om servlet-koden (detta innebär att ni får göra er factory generell så att den kan skapa en formaterare för ett format som den får som parameter av servleten, t ex).

Klient

Androidapp som presenterar datat från servern. Se funktionella och ickefunktionella krav nedan.

Kodexempel TODO:

Under http://129.16.213.216/yrgo/Android/ hittar ni exempel på:

  • Databas (SQLite) TODO
  • ListView TODO
  • Abstraktion av databas TODO
  • Kontextmeny TODO

JSON och http hittar ni här:

Funktionella krav

Obligatoriska

Visa studenter i en lista - antingen när appen startar upp eller som resultat av att användaren klickar på t ex en knapp med texten “Visa alla studenter”.

Visa en students kurser i en lista (t ex via en Context Menu). Användaren klickar på en student i listan och tas till en ny aktivitet (typ skärmsida) som visar denna studs kursregistreringar.

Icke obligatoriska (VG-nivå)

Appen skall kunna lista studenter offline (d v s ni måste cache:a). Om internetaccess saknas, så skall appen kunna visa en gammal sida (helst med en varningstext som förklarar att detta är sparade data och inte senaste aktuella).

Filtrera lista över studenter - t ex kan ni använda filter för att välja ut vissa studenter enligt något kriterium t ex studenter med namn som börjar på “A”.

Icke funktionella krav

Obligatoriska (G)

  • Strukturerad kod (t ex paket)
  • Googles kodstandard (helt eller delvis, men koden skall vara konsekvent)
  • Kommenterad kod - kodavsnitt som det inte är uppenbart vad de gör skall ha en förklarande kommentar på engelska
  • Interface för att specificera beteendet för lagring av medlemmar som hämtats från servern
  • Singleton för att endast presentera ett objekt som hanterar databaskopplingen

Icke obligatoriska (VG)

  • Factory för att returnera lämpligt objekt som implementerar lagrings-interface

Examination

Uppgiften examineras genom:

  • Bedömning av koden
  • Bedömning av funktionalitet (UX)
  • Muntlig presentation (med frågor från examinator till student) av uppgiften
  • Rapport (se Rapport)

Kom igång med laborationen

Välj vilken del ni vill börja med

Ni kan välja om ni vill börja med klient-delen (Android-appen) eller server-delen (Servlet-databas).

Börja med rätt ambitionsnivå

Generellt gäller följande råd: Börja med att uppfylla kraven för G! Spara sedan projektet när det fungera på G-nivå och skapa en kopia av det innan ni börjar med VG-kraven. Detta säkerställer att ni kan ge upp eller inte hinna klart med VG-delen och ändå ha kvar en G-version att skicka in.

Om ni inte hinner klart varje detalj eller krav

Om ni vid deadline inte är klar med varje krav eller delfunktion, kan detta ändå resultera i G om ni i rapporten och presentaionen kan redovisa för varför ni inte hann med, vad som gjorde att ni körde fast och hur ni tänkt att lösa implementationen om ni haft mer tid. Redovisa tydligt vilka delar som är färdiga och lägg in i presentationen en mock-up (det vill säga fejkad) av de delar som inte ännu fungerar. Dock kräver vi att övriga delar skall fungera tillsammans. Ni måste alltså ha en fungerande kommunikation mellan klient och server som faktiskt hämtar data men vissa features/krav kan vara ofärdiga.

Programmera mot en testmiljö

Om ni börjar med server-delen, så testa den med kommandoradsklienter! Ni ska inte vänta tills ni har en fungerande Android-app innan ni kan verifiera att servern fungerar! Specificera vilka anrop er server skall klara och anropa den på kommandoraden med exempelvis

$ lwp-request - m GET http://localhost/studentdata?student=all&format=xml

Verifiera att ni får giltig och välformerad XML tillbaka.

Om ni börjar med Android-klienten, så behöver ni inte ha en server som är klar för att testa! Ni kan börja med att ha en Json-fil lokalt i “telefonen” som ni läser in och låtsas att ni fått från servern (samma med XML). Sedan kan ni gå över till att appen hämtar Json eller XML från nätverket. Ni kan sätta upp en fejkad server på kommandoraden som ignorerar parametrar och endast leverar en statisk (på förväg kodad) Json eller XML. När detta fungera så vet ni att appen klarar av att göra ett request mot en server (bara inte just den ni kommer skriva själva ännu!). Vill ni ha en mer realistisk fejk-server, så jobba i grupp och kör mot varandras servrar/från varandras klienter. Ni kan också skriva en fejk-server som faktiskt läser GET-parameterar. Vi kommer gå igenom exempel på detta under utbildningens gång.

Lös inte allt på en gång!

Om ni ska arbeta med server-sidan, så bryt ned problemet i mindre delar och lös dessa delar en i taget. Ni ska skriva kod som hämtar studentdata från en databas. Skriv en fristående Java-applikation som kan köras på kommandoraden och hämta data från databasen. Ni ska göra om studentdata till en List<Student>. Skapa en klass som läser från databasen och skapar Student-objekt vars referenser ni lägger in i någon sorts List<Student>. Samma med Course-objekten. När ni har kod som kan hämta data och skapa rätt sorts element på kommandoraden så vet ni att den koden går att använda även i era servlet:ar.

Er servlet skall kunna leverera två datamängder - en med alla Student-objekt och en med alla Course-objekt (utifrån ett visst student-id). Lös en i taget! Låt servleten bara returnera ren text i första versionen - så att ni kan verifiera att den känner igen anropet (t ex student=all). Hoppa över parametern med XML respektive Json (format=xml t ex). När ni ser att servleten kan känna igen anropen för studenter och kurser, så kan ni börja med att koda listorna som XML eller Json.

Skriv ett stand-alone kommandoradsbaserat program som hämtar en List<Student> via de klasser ni skapade för databas-koden. Låt programmet använda en klass som kan ta en sådan lista och skapa t ex Json-kod från den. När denna applikation fungerar på kommandoraden, så vet ni att ni kan översätta från List<Student> till en Json-kodning av dessa studenter! Då kan ni använda koden i er servlet. Gör samma sak med List<Course>. Gå sedan över till XML.

När ni kan på kommandoraden via Java-program hämta data från databasen och skapa listor av objekt, samt översätta listorna till Json eller XML så har ni all kod som ni behöver anropa från servleten (eller servletarna om ni använder flera). Nu först kan ni fokusera på logiken i er servlet-front-end. Börja med att se till att servleten kan förstå alla GET-parametrar. Låt den producera text som svar som visar att den förstår parametrarna och kombination av paramtrarna. Nu kan ni ta ett av anropen och i stället för text leverera korrekt data i korrekt format.

Tänk på att ni inte behöver en android-app (eller ens en webbläsare) för att testa att anropa servleten med parametrar. Det går lika bra (och är faktiskt lättare) att göra med kommandoradsverktyg.

När ni verifierat att servleten (nu kan ni kalla det ert API!) reagera korrekt på de parametrar som är tillåtna, så kan ni gå över till att skriva klienten.

När ni har en koppling mellan Android-klienten och Servleten (API:et) som fungerar, så spara all kod och zippa ihop den innan ni fortsätter på VG-kraven (om ni siktar på det).

Skapa en kopia av bägge projekten och börja på ny kula för att förbättra systemet. Här kan ni t ex arbeta med felhantering och statuskoder. Ni kan förbättra arkitekturen och designen av era klasser för att göra koden lättare att underhålla och bygga ut. Ett bra test för om ni har en bra arkitektur på server-sidan är att fundera på hur mycket jobb det skulle vara att lägga till en parameter, eller lägga till en parameter för ett nytt format som t ex CSV. Om ni kan lägga till ett format som CSV utan att behöva ändra och kompilera om servleten, så har ni förmodligen en bra arkitektur. Om ni måste lägga till en IF-sats för varje adderad funktionalitet eller format, så har ni förmodligen en sämre arkitektur. Ni är här för att lärar er så det är inte meningen att ni ska skapa en perfekt arkitektur för att få godkänt! Men vi vill också få er att tänka på vad skillnaden är mellan en bra och en dålig arkitektur, t ex ur perspektiven flexibilitet och stabilitet.

Förslag på kom-igång-ordning, servlet-delen:

  • Skapa databasen från SQL-filen (kalla den t ex students.db)
  • Logga in i databasen och bekanta er med tabellerna (.schema och .tables)
  • I databasens interaktiva skal, testa att hämta alla studenter med ID typ: SELECT name, id FROM students;
  • Skapa en Hello-World-servlet t ex StudentAPI.java
    • I web.xml sätt klassen till er servlet som kan heta typ StudentAPI
    • I web.xml sätt url-mapping till exempelvis /studentapi
  • Skapa en klass Student i classes-katalogen
    • En Student kan ha id och name som sätts i konstruktorn och som har metoder som returnera värdena
    • En Student kan ha en toString() som gör @Override på toString() från Object och som returnerar t ex name
  • I servleten, skapa en List<Student> som en ArrayList<Student> och stoppa in massa nya Student-referenser i den
  • I doGet() så skriv ut Hello World som plain text (se övnignar)
  • I doGet() när ni verifierat att ni når servleten på http://127.0.0.1:8080/studentapi hämta eventuell id parameter
    • typ String ID = request.getParameter("id");
    • kolla om ID är "all" och i så fall skriv ut listan med Student-referenser
  • Också i classes (i ett paket eller bredvid servleten) skapa ett interface Storage med åtminstone en abstrakt metod
    • public List<Student> getAll();
    • Skapa en implementerande klass DBStorage implements Storage som verkligen har metoden getAll och som skapar en ArrayList med studenter - hårdkoda dem först!
    • Gör i stället så att metoden skapar en ArrayList<Student> med data från databasen
  • I doGet(), använd en Storage-referens till att anropa getAll() och få listan på studenter. Skriv ut dem via response.
    • När getAll() i ert Storage (som är en DBStorage) hämtar data från databasen och skapar studenter så är ni i princip klara med kopplingen servlet-databas
  • När kopplingen med databasen via Storage fungerar, ta fram en SQL-sats för att hämta kurser givet ett visst ID.
    • Lägg till en metod i interfacet och DBStorage som heter getCoursesByStudentID(int id) eller nåt annat namn som returnerar en List<String> alternativt en List<Course>.
  • I doGet, lägg till en koll om id inte är "all" så försök göra om id till en int.
    • Om parametern id finns och gick att göra om till en int, så anropa getCoursesByStudentID med id-värdet som parameter.
  • I DBStorage kan du först fuska och skriva en hårdkodad ArrayList<Course> eller <String> som returneras.
    • När det funkar att anropa servlet med t ex id=3 och få en massa kurser tillbaka, så byt från hårdkodad lista till en lista som kommer från databasen.
    • Hint: för att få fram rätt SQL-sats behöver du göra en JOIN mellan courses, students och registrations.
  • Skapa en klass som kan göra om en List<Student> till en Json-sträng och en List<Courses> till en json-sträng
    • Ändra så att servleten först hämtar listan med studenter eller kurser och sedan gör om den till Json med hjälp av klassen ni skapat
    • Sätt content-type på response till application/json;encoding=utf-8
  • Verifiera att ni får gilltig Json från servleten (det finns verktyg för detta)
  • Nu när ni har hela kedjan - anrop - databas - lista - json - svar till webbläsaren så kan ni börja med Android

Om ni börjar med Android-klienten, föreslår vi att ni bryter ned uppgiften enligt följande steg:

  • Skapa ett enkelt gui med en ListView
  • Skapa en klass Student med en toString() som endast returnerar name
  • Skapa en adapter som tar en List<Student> och visar den
  • Använd hårdkodade listor först
  • Skriv en klass som kan hämta text från servleten (det kommer ju vara Json nu)
  • Skriv en klass som kan göra om Json till en List<Student>
  • Använd listan för att populera er ListView
  • Lägg till att man kan klicka på en student i listan
    • Hämta ut hela student-objektet och fråga efter ID
    • Anropa klassen som kan prata med servleten och be den hämta /studentapi?id=3 (om ID för studenten var t ex 3)
    • Gör om Json-strängen till en List<Courses> (eller om ni vill använda String för att representera en kurs)
    • Visa listan på kurser för studenten som klickades på

Trouble-shooting servlet-delen

Av någon anledning så skickar Winstone data med encoding (egentligen charset) ISO-8859-1 medan XML-filen explicit säger att den skall vara i UTF-8.

Lösningen på detta "problem" är att i doGet() explicit anropa response.setCharacterEncoding("UTF-8"); och på så vis tvinga fram rätt kodning. Annars kommer XML-filer vara ogiltiga om de innehåller t ex svenska tecken (ÅÄÖåäö) eftersom de kommer kodas fel av Winstone. Det blir då en konflikt mellan vad XML-filen påstår (UTF-8) och verkligheten (ISO-8859-1).

Testa manuellt med en lwp-request -m HEAD http://er-url-till-servleten:8080 och verifiera att content-type är application/xml;charset=UTF-8 och inte Content-Type: application/xml

Appendix

Cache av data (i android-klienten) (för VG)

Studenter skall cache:as.

Ni behöver inte cache:a studenternas kurser (de kan cache:as varje gång ni hämtar från servern).

Förslag på strategi för cache av data

Om appen har tillgång till internet och behov av att uppdatera data:

  • Hämta data
  • Släng ned data i db
  • Läs upp data från db till List
  • Lägg in List i ListView (Adaptern)
  • Om appen inte har tillgång till internet eller inte har behov av uppdatering:
  • Läs upp data från db till List
  • Lägg in List i ListView (Adaptern)

Rapport

Write the report in Swedish or English. We will get you started in thinking about instructions often being in English by writing this section in English. You may choose Swedish for your report, though, if you feel more confident with that language.

The report should be about four pages long (circa 2000 words).

The report part of this assignment is included to make you reflect upon your own learning and problem solving. It also prepares you for the classroom presentation.

Your report should include the following sections (with reflections):

(Report section 1) Tools

Reflections on the tools used to develop your code (E.g what tool did you use?, what was good?, what was missing?, what can be improved?, experiences using “avd” and/or physical device)

(Report section 2) Developer API:s and frameworks

Reflections on the API:s you used (E.g Were there any problematic APIs? Why was it problematic?... Did you switch from using one API to another -if so explain why). By “API” we here mean the programming interface (documentation and Interfaces, Classes) for Android, Servlet, XML, Json, JDBC etc.

(Report section 3) Developer documentation

Reflections on the developer documentation you used (E.g the developer site, manuals, guides.... Were they good? What was missing?). We want you to think about what it is like to find help online in documentations, tutorials etc. If you find the documentation lacking, we want you to think about why and write better documentation yourself when you start working in a real project.

(Report section 4) Android platform

Reflections on Android as a platform (e.g what new experiences were there for you?). Reflections using Android's MVC. What was hard to understand about Android? What was easy? How much Java did you have to know, in order to start working on an Android project?

(Report section 5) Server-side

Reflections on what was difficult on the server-side of the assignment. How was it to work with Jenkins-Winstone, compared to Netbeans, IntelliJ or Eclipse? What did you think about separating the database storage module from the servlets? How much Java did you have to know in order to start working on a Servlet-based system with XML, Json and JDBC?

(Report section 6) Misc

Feel free to write about any other experiences in the project. Here you can bring up stuff you wished you knew from previous courses which would have helped you understanding this assignment. What lectures or topics do you think was missing from these courses or any previous courses you have taken? Do you think this assignment is useful for your understanding of web-based client-server applications? Did you learn anything new about Java from working with this assignment? Etc. Use your imagination.

Deadline XXXdag 2016-05-?? kl 23:59 TODO

  • Packa ihop server-koden i en zip-fil
  • Packa ihop klient-koden i en zip-fil

Vi samlar in de två zip-filerna samt rapporten på en USB-disk på lektion.

Eller skicka dem till oss (rikard@morus.se) på något annat sätt.

Om betygsättning

Labben omfattar de två kurserna Klientprogrammering och Systemintegration.

Klientprogrammering omfattar i synnerhet Android-delen men omfattar också tekniker för att testa API:et på servern från kommandoraden (och i viss mån vice versa - man kan sätta upp en fejk-server på kommandoraden och köra Android-appen mot denna).

Systemintegration omfattar den del som integrerar Android-appen och Server-api:et samt på serversidan hur servleten kommunicerar med databasen. Här ingår också att använda API:er i form av jar-filer (för jdbc, Json, XML osv).

På dessa kurser ges betygen IG, G och VG.

Denna laboration innehåller inslag från båda kurserna. Vi kommer bedöma helheten främst som grund för betygen. Om vi ser att någon del är svagare så kommer det påverka betyget i den kurs som bäst överensstämmer med den del i laborationen det handlar om. Vi kommer naturligtvis motivera betygen om det är så att ni får olika betyg i de två kurserna.

Kurserna går in i varandra en hel del så vi har därför valt att slå ihop examinationen av dem till en större laboration. Detta upplevdes som positivt av tidgare årskurs elever.

Enligt kursplanerna så handlar klientprogrammering om “klienter som konsumerar Webbtjänster” och systemintegration om “[H]ur kommunikation maskin till maskin går till och vilka format som krävs för att det skall fungera. Den dominerande databäraren för maskin till maskinintegration är för närvarande xml.”.

Det är svårt att kommunicera med en maskin utan att ha en klient. Och det är svårt att skriva en klient utan en maskin att kommunicera med. Därför har vi slagit ihop kurserna så att de kompletterar varandra samt för att ni ska få en kontinuitet mellan kurserna.