Thinking & coding: Changing my achitectural structure with "KISS".

During the last programming session I started thinking about the architecture of the app. And I have to say that there is something to say about it.

In the previous post, I talked about separating the UI and the logic from each other. And make the connection through state management. Now I fear that architecture goes against my first rule of principle, KISS. "Keep It Simple and Stupid" or in other words, "you shouldn't make things hard when its easy". And this not out of laziness but out of conviction of the power of this statement. It is even a way of life.

Following the architecture of the previous post, the EventData will be handled by 3 different libraries. I can easily reduce this. Which also results in fewer lines of code, fewer libraries, fewer dependencies and therefore less chance of errors. Which will increase the performance of the app. And yet the intent of separating the UI from the logic will be preserved. Because all the logic will be in the FirestoreEventService library.

Why can I apply KISS in my app.

It's because I don't need all CRUD functions. I just need to read the data from the backend. And also important, the reading only happens once and is not repeated.

So in my app, the link between UI and Logic will be made by the FirestoreEventService Library. The event data will be read and forwarded through this service and not through an additional state management system such as Provider.

Later in the app I will have to isolate one from the list of documents to display in an Event Detail Page. But that's where Life Wisdom 2 comes in. Only solve problems when they present themselves! So I will take care of it later.

The weird thing is that I came up with the idea of ​​turning off state management when I started studying Riverpod. Not because it was too difficult, but unnecessary in my app for the time being. And later if I need state management, I will create providers through Flutter Riverpod Hooks. Simply because it is so easy to add to the code afterwards.

So the code that can be found below is completely different from the previous post. Actually, the code comes directly from the Firebase Firestore documentation pages.

De Code.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

import 'package:cloud_firestore/cloud_firestore.dart'; import 'package:flutter/material.dart'; //final eventProvider = StateNotifierProvider((ref) { // return FirestoreEventService; //}); //TODO map the data to the eventmodel. //TODO extract the UI element listview and listtile class FirestoreEventService extends StatelessWidget { @override Widget build(BuildContext context) { CollectionReference events = FirebaseFirestore.instance.collection('Events'); return StreamBuilder<QuerySnapshot>( stream: events.snapshots(), builder: (BuildContext context, AsyncSnapshot<QuerySnapshot> snapshot) { if (snapshot.hasError) { return Text('Something went wrong'); } if (snapshot.connectionState == ConnectionState.waiting) { return Text("Loading"); } return Expanded( child: ListView( children: snapshot.data.docs.map( (DocumentSnapshot document) { return Padding( padding: const EdgeInsets.all(8.0), child: ListTile( title: Text(document.data()['eventTitle']), subtitle: Text(document.data()['eventDate']), ), ); }, ).toList(), ), ); }, ); } }

In the following code sessions, I'm going to create an eventCard instead of ListTile. And when the entire list of events is displayed as in the prototype, I will isolate the necessary widgets from the above code and put them in separate libraries. Because I will reuse these widgets in the project later.

So, I hope you can follow my decision, if I make a reasoning error somewhere, I would like to read it in the comments.

Until the next,

Do, believe and be happy

Stefaan