Göm menyn

TDP028 Projekt: Entreprenöriell programmering

Projektkrav


Registrera dig på webreg, på projekt-fliken.

Stöd för projektstyrning

Ett grundkrav i projektet är att du arbetar i en jämn takt. Som ett stöd med projektstyrningen finns nedan rekommenderade milstolpar, där du förväntas vara klar med en del av projektarbetet. Maila kursassistent med länk till ditt repo om du vill ha feedback eller bedömning på det du har gjort hittills.

Vecka Milstolpar (milstolpe-poäng kan fås utöver tekniska och entreprenöriella poäng)
v35

Appbeskrivning (tänkt funktionalitet och wireframe-navigationsdiagram), samt konkurrensanalys inlämnade i repo. Commit:en taggad med Milstolpe-1 (0.5 p)

Lägg en kortversion av app-beskrivningen i readme.md i repot. (Readme är en slags introduktion till repot, det som besökaren ser allra först.)
v36

En enkel app (antingen Hello world, eller början på egen app) med textruta, och en knapp inlämnad i repo. Commit:en taggad med Milstolpe-2. (Syftet är att komma igång med Android Studio). Lägg gärna den här typen av små-kod i en särskild mapp i repot, som t.ex. kan heta Snippets, så att den inte stör din apps mappstruktur i repot. (0.5 p)
v37

Två skärmar, med navigering emellan, inlämnad i repo. Commit:en taggad med Milstolpe-3

Öva gärna på klick-hantering mellan två fragment, genom att lägga till två fragment till din aktivitet, och hantera klick på en knapp i ena fragmentet, för att ta användaren till andra fragmentet. (Vi kommer att gå igenom i kursen hur klickar kan hanteras på ett *snyggt* sätt, och det är tänkt att du ska öva dig i detta under denna vecka.). (0.5 p)

v38

Visa faktiskt innehåll på skärmarna, dvs. enkel backend (T.ex. Firestore) inkopplad. Kod inlämnad i repo. Commit:en taggad med Milstolpe-4. (0.5 p)
v39

Veckoplanering av resterande projektarbetet, med kravlista (funktionella krav) på vad som kommer att implementeras, och vad som ska uppnås varje vecka, är inlämnade i repo. Commit:en taggad med Milstolpe-5 (0.5 p)
v47

Halvtids-screencast på ca. 2 minuter, där du demar en tidig version av din app (ungefär motsvarande en Minimal Viable Product), inlämnat i repo. Commit:en taggad med Milstolpe-6 (0.5 p)

Betyg

Du kan själv bestämma vilket betyg du vill satsa på, genom att välja vilka av projektkraven nedan du vill jobba med. Förutom bas-kraven (se nedan), kommer du att kunna välja vilka tekniska aspekter och vilka API:er som du vill implementera. Varje implementerat krav ger poäng, och genom att samla poäng kan du uppnå olika betygsnivåer. Betyget är alltså direkt beroende av hur mycket arbete du har satsat på projektet, och vilka konkreta färdigheter du uppvisar i din implementation.

Normalfallet är att du får det betyg som du själv har valt att jobba mot. Var tydlig med att ange din betygsambition i readme.md-filen i ditt gitlab repo. Dokumentera dessutom noga alla poänggivande krav som du har uppfyllt, dels genom att lista och beskriva dem i readme.md-filen som ska ligga överst i repot, samt genom att visa upp dem i dina två screencasts, och gärna lyfta fram dem i koden genom välskrivna kommentarer.

Baskrav för alla betyg

För betyg 3:

  • Baskrav uppfyllda
  • 7 projektpoäng (inkl. eventuella milstolpar), varav minst:

För betyg 4:

  • Baskrav uppfyllda
  • 12 projektpoäng (inkl. eventuella milstolpar), varav minst:

För betyg 5:

  • Baskrav uppfyllda
  • 17 projektpoäng (inkl. eventuella milstolpar), varav minst:

Tekniska krav att välja från

  • Modulär kod, enligt någon vald princip. Referera till best practices, t.ex. ange i kommentarer eller i Readme-filen länk till websida eller annan källa du har valt att följa. Kika t.ex på designmönstret Model View ViewModel (MVVM) som numera förordas av Google för Android-utveckling. (OBS! 2 p)
  • Bra avvägning mellan användning av Activity och Fragments. Best practices säger att man gärna ska använda Fragments där det går, då dessa är mer lättviktiga än Activities. Activities bör användas när det gäller byten mellan olika användaraktiviteter, t.ex. lista inkorg byts mot skriva mail. (1 p)
  • Hantering av stora och små skärmar med olika layouter. Användaren ska kunna byta från mobil till tablet utan att tappa i upplevelse. Bl.a. är det viktigt att information på skärmen förblir detsamma, samt att layout:en ser bra ut i båda lägen. Användarupplevelsen kan enkelt testas genom att rotera mobilen eller emulatorn före uppstart. (1 p)
  • Hantering av skärmrotation. om enheten roteras ska skärminnehållet förbli stabilt. Samma innehåll visas som före rotationen, men nu med annan layout. Användarupplevelsen ska alltså bevaras, även om mobilen eller tablet:en roteras under körning. (OBS! 2 p)
  • Hantering av användar-input (klickar) på rätt nivå. Oftast innebär detta att klickar hanteras av förälder-Activity:n, även om klicken först uppfångas av ett Fragment (knappen, eller dylikt sitter ju oftast i Fragmentet). Notera att det kan finnas fall där det är snyggare att hantera klickar på en lägre nivå, t.ex. om data ska hämtas och Fragment-innehållet ska uppdateras från en remote databas. (1 p)
  • Snygg användning av callbacks (t.ex. onClick), genom att använda anonyma lyssnar-klasser, där man samtidigt även underlättar för testning genom att definiera namngivna metoder... (se vidare föreläsningsslides:en). (1 p)
  • Portabla Fragment som kan kopplas in mot vilken Activity som halest (även framtida, ännu ej skriven kod). Detta kräver användning av interfaces vid inkoppling av Fragment till Activity (Se föreläsningsanteckningar), eller att man använder Navigation component i JetPack. (1 p)
  • Hantering av bakåtknapp, så att man aldrig hamnar konstigt vid tryck på bakåtknappen. Detta sköts oftast automatisk av Android, men kan i vissa fall kräva hantering av vad som läggs på backstack. (1 p)
  • Användande av egenskriven Adapter, eller motsvarande klass, t.ex. ViewModel, som ser till att matning av data till GUI:t sköts när användaren scrollar, etc., och att data-element formateras på ett snyggt sätt. I fallet av egen adapter, kan man t.ex. ärva från en ArrayAdapter och göra sin egen list-element formattering (dvs. override på superklassens metod för att ta fram en ny View att visa). (1 p)
  • Sökningsfunktion i appen, dvs. att användaren kan skriva in ett sökord och få upp relavant information. Oftast krävs att sökningen genomförs på backend-sidan, för att säkerställa att all relevant information kan visas. (2 p)
  • Hantera, dvs. hålla koll på inloggningsstatus hos olika användare, så att bara inloggade användare kommer åt att använda vissa features, eller att inloggning krävs för att få se viss information i appen. (1 p)
  • Eget förslag på någon teknisk finess, en tekniskt snygg lösning, särskilt elegant kod, etc. (Tag kontakt med kurspersonalen innan du sätter igång och genomför din idé för att säkerställa att förslaget faktiskt är värt poäng.)

Entreprenöriella krav att välja från

  • Firestore. Använder Cloud Firestore eller Realtime Database som databas. Båda lösningarna är Googles lagringstjänst för mobile- och webb-appar som erbjuder bl.a. databas och autentisering. Dessutom finns en mer generell databas-lösning som heter Firebase Cloud Storage. Cloud Storage accepterar både ljud, bild, och text så i princip alla appar kan utnyttja Cloud Storage på ett eller annat sätt. (OBS! 2 p)
  • Notifications. Kan skicka notifications till användaren. Notifications möjliggör för appar att visa att något relevant finns. Implementera notifications för din app och testa att visa information även när appen inte är igång. (1 p)
  • Multispråk-stöd. Använd Androids system för att göra så att Appen identiferar minst 2 språk och använder t.ex. Engelska som default och Svenska för användare med Svenska språkinställningar. (1 p)
  • Någon typ av UX inställning, t.ex. möjlighet att ändra till dark mode (1 p)
  • Någon form av accessibility stöd, t.ex. öka font-storlek. (1 p)
  • Använder Google maps på meningsfullt sätt i appen. Man behöver registrera ett konto med ett bankkort för att kunna använda Google maps i sin applikation, men maps i sig ska fortfarande vara helt gratis (åtminstone så länge det inte är flera hundra tusen anrop per månad). Google har en mer detaljerad pristabell. Om man, av förståeliga skäl, är obekväm med att ge Google sitt kortnummer så accepterar vi också lösningar baserade på OpenStreetMap. Ni har mycket frihet i hur ni använder maps-funktionen, så länge det har någon anknytning till appens funktion. Att t.ex. bara ha en knapp som öppnar en karta ger inte poäng. (OBS! 2 p)
  • Geofencing. Använd Googles stöd för location för att på något sätt införa Geofencing i appen. Geofencing innebär att regioner skapas som påverkar en app, t.ex. om man är inom Campusområdet eller utanför. Det som kan ändras kan vara nåt så enkelt som appens färgschema, men mer spännande är det förstås om appens UI eller funktionalitet ändras beroende på område. (OBS! 2 p)
  • Analytics för att logga användar-events. Logga minst 5 stycken "custom events" på ställen i koden som är relevanta. När appen är klar, testa din app med minst 3 användare och se vilken data som dyker upp i Firebase-consolen. Med fler användare kommer du se mer mönster, som skulle kunna användas för att förbättra appen, men vårt fokus är mer tekniskt, så tre användare räcker. (OBS! 2 p)
  • Kontohantering, t.ex. lagra poäng, vänlista, eller dylikt som ska sparas över tid för olika användare (1 p)
  • Enkel inloggning av användare mot Firebase (1 p)
  • Tredjepartsinloggning med Google eller Facebook. Notera att man också kan använda Firebase för att implementera dessa autentiseringsmetoder, men ni får bara poäng för en implementation av varje typ (d.v.s det ger inte två poäng att implementera Facebook-autentisering på två olika sätt) (1 p)
  • Performance monitoring. Det går t.ex. att använda Firebase Performance Monitoring för att mäta saker som start-up tid. Gör det åtminstone på er slutgiltiga app, men det spännande är ju egentligen att se hur en sådan mätning under projektets gång kan hjälpa till att optimera start-up och dylikt. (1 p)
  • Eget förslag på någon entreprenöriell aspekt som kan införlivas naturligt i din app. Tag kontakt med kurspersonalen för att säkerställa att ditt förslag faktiskt kommer att kunna ge poäng.

Sidansvarig: Rita Kovordanyi
Senast uppdaterad: 2022-08-22