Göm menyn

TDP028 Projekt: Entreprenöriell programmering

Projektkrav


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

Bjud in din handledare som 'Reporter' till ditt repo, och maila din handledare, samt kursansvarig, en länk till ditt repo, så att du kan få feedback på det du har gjort under projektets gång.

Slutinlämning

Veckan före jul är det slutinlämning, dvs.

Krav för projektstyrning

En viktig aspekt av entreprenöriell app-utveckling är effektiv projektsstyrning. En del av grundkraven i kursen är därför att genomföra ett antal obligatoriska milstolpar.

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 du vill implementera, och vilka API:er du vill jobba med. 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 visas som första sida i gitlab), 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

  • Halvtids-screencast inlämnad i tid, och godkänd. länkad från Readme.md i repot
  • Ytterligare minst 3 milstolpar taggade, inlämnade i tid, och godkända
  • Eventuellt försenade milstolpar taggade och inlämnade i repot
  • Förberedelse och aktivt deltagande i freemium-seminariet
  • Appen inlämnad i Gitlab-repo enligt deadline i schemat
    • I readme-fil i repot: Kortversion av app-beskrivning, och din betygsambition. Ange en punktlista av de milstolpar och projektkrav du anser dig ha uppfyllt.
    • Appen har minst 4 skärmar (förutom eventuell logn-skärm) med navigering emellan. Appen ska även i övrigt uppfylla milstolpe-kraven.
    • Städad och välkommenterad kod
    • Utförlig app-beskrivning i docs-mapp eller liknande i repot
    • Konkurrensanalys i repot
    • Tekniskt PM i repot
    • Obligatorisk slut-demo av appen, samt Slut-screencast, länkad från Readme.md i repot

För betyg 3:

  • Baskrav uppfyllda
  • 7 projektpoäng, varav minst:

För betyg 4:

  • Baskrav uppfyllda
  • 12 projektpoäng, varav minst:

För betyg 5:

  • Baskrav uppfyllda
  • 17 projektpoäng, 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 vars rekommendation du har valt att följa. Kika t.ex på designmönstret Model View ViewModel (MVVM) som numera förordas av Google för app-utveckling. Exempelvis, kan man använda Repository designmönstret för att hantera data och nätverksanrop. (2 p)
  • Hantering av stora och små skärmar, eller skärmrotation, genom att använda olika layouter. Användaren ska kunna byta från mobil till tablet utan att tappa i upplevelse. Bl.a. är det viktigt att information användaren hunnit skriva in bevaras, så att skärmen förblir detsamma. Det är också viktigt 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. (2 p)
  • Alla sidor (widgets) är självtillräckliga, dvs. det finns inga sidvisa länkar i widget trädet, från en gren till en annan. Varje widget hanterar (lagrar och uppdaterar) sitt eget innehåll och sitt eget tillstånd, istället för att detta hanteras i appens globala tillstånd (app state) -- så långt detta är möjligt. (1 p)
  • Använder Provider för att hantera appens tillstånd. (1 p)
  • Använder någon sensor, t.ex. kamera eller GPS (1p per sensor)
  • Använder forms och validerar användarinput, så att input är av rätt typ, och är korrekt. T.ex. att lösenord är tillräcklig starka. (2 p)
  • Använder routes (go-routes biblioteket) för navigering i stället för Navigator.push. (1 p)
  • Kan hantera deep links, så att om man klickar på länken man fått via sms, eller dylikt, kommer man in på rätt skärm i appen. (1 p)
  • Enkel inloggning av användare mot Firebase (1 p)
  • Kontohantering, t.ex. lagra poäng, vänlista, eller dylikt som ska sparas över tid för olika användare. (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)
  • Visar realtidsuppdatering av skärminnehåll från Firestore eller motsvarande backend, så att t.ex. en användare kan se i realtid vad en annan användare har skrivit eller gjort. (1 p)
  • Använder widget testing av minst två skärmar, med 50% line coverage (1 p)
  • Använder unit testing för att testa minst två funktioner i appen, med 50% line coverage. (1 p)
  • Eget förslag på någon teknisk finess, en tekniskt snygg lösning, särskilt elegant kod, etc. (Tag kontakt med din handledare samt kursansvarig 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. (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)
  • Använder någon form av AI via publikt interface (API) (2 p)
  • Multispråk-stöd. Använd Flutters metod 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)
  • Sökfunktion i appen, dvs. att användaren kan skriva in ett sökord och få upp relevant information. Oftast krävs att sökningen genomförs på backend-sidan, för att säkerställa att all relevant information kan visas, inte bara det som råkade finnas på skrämen. (2 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. (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. (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. (2 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: 2024-11-11