Projecte
- Podeu fer el projecte en grups de 1-3 persones
- El projecte és obert, tot i que hi ha uns requisits mínims i unes idees.
Requisits mínims
- Ha de llegir i guardar dades en fitxers json
- Ha de llegir dades d'una API
- L'aplicació ha d'estar programada modularment
- Has de tenir tests unitaris de totes les funcionalitats excepte accés a API i interfície
- Interessant però no requerit: fer un bot de Telegram
Funcionalitats de l'aplicació
La funcionalitat és lliure sempre que es complexin els requisits anteriors i que el professor l'hagi validada. Tot i això a continuació tens algunes propostes:
Proper Bus
Fes un bot de telegram per l'avís de següent autobús. Usant l'api de TMB (https://developer.tmb.cat/) fes un bot per a que un usuari pugui obtenir el següent bus a les parades previament registrades.
Idees:
- Cada usuari podrà indicar un nom d'algunes parades per després preguntar a quina hora pasaran els següents autobusos.
- Cada usuari podrà indicar el nom de trajectes i li dirà a quina hora surten els següents atobusos
- …
Quan fer rentadora
Fer un bot de telegram que ens indiqui, segons el preu de la llum (API) i la meteo (API) si avui és un bon dia per posar la rentadora i a quina hora és la millor.
Entrega
- Comparteix el teu git amb el professor i posa la url al google forms de l'entrega
- Exporta el projecte en un zip i entrega'l al classroom
- Per exportar el projecte ves a File->Export->Project To Zip File
Revisió
Un cop entregat el projecte, el professor passarà per cada grup per revisar-lo i farà preguntes als diferents membres del grup per veure que tot els membres han participat al projecte. La nota del projecte pot no ser igual per als diferents membres del grup.
Arquitectura
En aquest apartat veurem com ha d'estar organitzada l'aplicació.
Per fer-ho suposarem que volem fer una aplicació que ens indiqui les bicis que hi ha a una estació del bicing. L'usuari podrà posar noms a les estacions de bicis.
- Quan l'usuari executi la comanda /add nom id, es registrarà l'estació amb un nom
- Quan l'usuari executi la comanda /info nom, ens mostrarà el nombre de bicicletes que hi ha.
Repositoris
Haureu de crear una classe per a cada tipus d'accés a dades (Api o fitxers).
Per exemple, si d'una API en volem obtenir el llistat de estacions
class BicingRepository(){
fun listStations():List<Station>{
TODO()
}
fun stationInfo(stationId: Int):List<StationInfo>{
TODO()
}
}
I si hem de poder enmagatzemar el nom d'una estació i obtenir el id segons el nom farem:
class BusStopsRepository(){
fun addAlias(name: String, stationId: Int){
TODO()
}
fun getStationId(name: String){
TODO()
}
}
Business logic
Farem una classe on tindrem la lògica de negoci de la nostre aplicació. Si la classe es fa massa gran l'haurem de dividir. Aquesta classe tindrà una funció per cada una de les funcionalitats.
Aquesta classe utitlizarà les dues anteriors.
class BicingUseCases(
val bicingRepository : BicingRepository,
val busStopsRepository : BusStopsRepository){
fun add(name: String, stationId: Int){
TODO()
}
fun info(name: String) : List<StationInfo> {
TODO()
}
}
UI
Les classes de UI (telegram) faran crides a la de business logic. És molt important que aquesta tingui el minim de lògica possible. De fet, només heu de fer crides a funcions que faran la lògica - un text/command només fa una crida a una funció de la lògica-.
(...)
command("/add"){
// TODO()
bicingUseCases.add(name, stationId)
}
(...)