Step 4 — Starting to Customize the Boilerplate
In the previous episode I narrowed the starter boilerplate template code I would use as my starting point down to the venerable
This starter code is an extremely basic time tracker app with an email-based sign-in system. I thought it would be nice to not have to work all that out from scratch and then realized when starting up on the app today that this kind of app really doesn’t need a sign-in system. I don’t want to have our guests go through a registration process to RSVP or participate in the photo-sharing bit. That would be silly.
Instead, for the very few pages that I need an idea of who is using the app, I’ll just have a shared super secret password that everyone uses that we will distribute to our special guests ahead of time. Considering these are people that we will be inviting to our wedding I think we can trust them.
Which means…
First up, rip out the user system.
In the main.dart a MaterialApp is used with a bit of logic wrapped in a custom AuthWidget that looks at the logged-in state to determine what page to start with. Instead of using the AuthWidget, I’ll just have the home property point to the HomePage.
Now when the app starts up it goes straight to the home page and displays a nice error message because it’s trying to grab some data attached to the logged-in user. We have no logged-in user, so boom.
What’s in a home page?
That then leads to the question, what will be the Home Page actually be? What will be on it? Where will this what that is on it come from?
Well, I do know that most of the app will consist of pretty basic static pages with bits of information on them. Do I want to embed that info directly into the app? Absolutely not. That would require a new app download every time I fixde a typo. Not to mention this wouldn’t actually end up being a generic project that anyone could start with.
Ah, ok, I’m building a CMS system.
It has just occurred to me that this app will essentially be a very basic CMS system with a few extra goodies tacked on.
Side note: My fiancé is now more or less on board with this idea, now that I have told her about it.
Decision Time: How will this CMS be managed.
I’m just going off the cuff here, but I think I will have a second super secret password for admins (me) to use within the app to edit the pages directly!
These datas will be stored on the backend on Firebase?
Let’s set up a Firebase Database and Collection
I’ll hop on over to the Firebase console now and see if we can’t get something set up in the Cloud Firestore for this scenario.
I started by following the wizard to create a new database. I set it to be provisioned for production because that seems to make sense and have it living in one of their ease coast servers since that’s where we’ll be.
Next up is the Start a Collection wizard. I named this first collection “pages”.
When creating a collection you must also create the first document in the collection for some silly reason, so I started the document to represent the home page. I forwent the AutoID and very rebelliously gave the document an id of HomePage. Is this a good idea? I have no idea. Seems like a pretty innocuous decision at this point.
For the first stab, I think I’ll have a page document contain an array of sections that each have a few values like section_type, section_text, etc.
What now?
Maybe we should load up this list of pages in the database at startup and use that to build out our UI pages? Makes sense to me.
Time to do some research into how to accomplish this and return back with my results.
Stay tuned and stay chuegy friends.
