Calling a Function When Loading a Stateful Widget in Flutter

My capstone group is building a mobile app using the Flutter SDK, and it requires for a user to be logged in to reach any page other than a login page, a sign up page, and a forgotten password page. We are using Google’s FirebaseAuthentication package to handle securely logging in and out, but we also have our own Cloud Firestore database that stores additional user and account information beyond the basic login information that Firebase stores. So after a new user creates an account, we needed a way to gather the additional information we need and store that in the database.

After a user logs in or sign ups, our app routes them to the app’s homepage, so we figured that when the home widget is loaded, we could just call a function that would determine if the user’s FirbaseAuth user ID corresponded with a document in our Firestore database, but figuring out how to effectively call this function when loading the stateful class that builds the widget that is the foundation of our homepage proved trickier than I anticipated.

I first tried to just call a function in the widget’s build method but quickly ran into an issue: database calls need to be made asynchronously to prevent blocking, and the build method is not asynchronous. So I did some googling and cam across initState().

initState() is a function that is called a single time when a widget is inserted into the app’s widget tree and the widget’s state is initialized. Because other screens are just loaded in the body of our homepage widget, meaning the homepage should only be inserted into the tree a single time when a user is already in the database, this is a great solution that will not make a bunch of unnecessary database calls. I used the following code within the widget generated by the StatefulWidget’s createState() method to check if the user already existed in the database and if not, route them to a set up page.

class NavBarPage extends StatefulWidget

const NavBarPage({    Key? key,  }) : super(key: key);
  @override  State<NavBarPage> createState() => _NavBarPageState();

}

class _NavBarPageState extends State<NavBarPage> {

  @override 

// Check if firebase_auth uid corresponds to document in db.  void initState() {    asyncUidCheck().then((value) {    });    super.initState(); 

}

}

My First Two Weeks on the Job

I started last Monday at my first full-time software developer job. So far I haven’t even written a single line of code. I primarily spent the first week setting up my dev environment and getting familiar with the processes and systems my team handles. Just getting my env set up was a way bigger task than I anticipated. I had already been working at my company (PacificSource Health Plans) in a mostly non-technical role, but I had done a bit of coding in my previous position, so I already had a lot of the developer software installed- Visual Studio, Visual Studio Code, Microsoft SQL Server Management studio-but I still had to install some ancillary software and get access permissions to all the servers, directories, databases and source control I will need for my job. This involved submitting many, many help desk tickets requesting access.

In addition to get my environment set up, I’ve also been learning about the codebase and the business it is supporting. This has involved many hours of meetings and watching more senior developers walk me through code and explain different systems. I’ve already learned a ton, but it has been mentally exhausting too. I’m really looking forward to being able to contribute more and start writing some code.

The best part of the new job so far was when I actually got to solve a problem myself (well sorta, I answered an important person’s question, at least). The most senior developer on my team left for a different company last Friday, but for the week our tenures overlapped, he tried to pass on as much information to me as he could. One of the things we discussed was a process that automatically assigns primary care providers to our Medicaid members. The primary logic for this process is handled in a SQL stored procedure that is nearly one thousand lines long (yeah, it’s a little scary) which he briefly went over with me.

On Tuesday, the VP of my old department called me to ask a question about the assignment logic (he never called me directly when I was actually in his department, funnily enough. I guess I’m moving up in the world). It took over an hour of reading through the SQL and, with the help of another developer, running snippets of it in SQL Server Management Server and analyzing the results, but I was finally able to understand how everything worked to answer his question.

The best part about that process was that I was totally engaged the whole time. I had a question at hand, and I was determined to understand the code well enough to answer it, and I genuinely didn’t want to stop until I did. Being a new developer can be kind of overwhelming at times, but I think I’m really going to enjoy this career once I get my feet under me.