It is very hard to offer a solution to such questions without access to the code. One should always be able to place breakpoints and ‘step through the code’ when debugging. I can only judge from your question, you’re still getting an understanding of Asynchronous Programming.

I will, however, offer some assistance.

Time is your enemy in this case. Time is needed by the Prefs library to ready itself, when initialized in the initState() function. However, you’ve code also in the initState() function asking of its services right away. Asynchronous programming is therefore required.

Below, you’ll notice I’ve labelled the initState() function with the keyword ‘async.’ It means some asynchronous programming is going to be involved since the Prefs library needs time to ready itself.

String savedCity;
String savedCityID;

class _DemoState extends State<Demo> {

@override
void initState() async {
super.initState();
Prefs.init();
savedCity = await Prefs.getStringF('savedCity');
savedCityID = await Prefs.getStringF('savedCityID');
api.bizListAPI(widget.subCatid, savedCityID, supSubFinal, areaFinal).then((response) {
setState(() {
bizListOBJ = response;
});
});
}

Dart code runs in a single “thread” of execution. Thus, with the encounter of first await command, the code literally ‘jumps out’ of the initState() and continues running the app only to return and continue to the next line when the first await command has finished and has returned with a String. The next line happens to have another await command. Thus, once again, setting aside ‘the rest of the code in the initState() function’ in its own little ‘isolate’ waiting now for the results of the second await command.

This “jumping out” of the initState() could cause other problems however. For example, having set aside the first await command to now continue execution of your app, that api of yours, api.bizListAPI, may happen to be then be called upon in your State object’s build() function right away. However, it’s not ready yet either.

Successfully coordinating such asynchronous operations comes only with experience and with the understanding of Asynchronous Programming.

Regardless, try this approach and see if it’s successful. In fact, I suspect possibly this second approach would also work. The one await command below allows the _prefsInstance in the Prefs library to instantiate (i.e. the Prefs library to ready itself), and then you need not use the ‘getStringF’ but the function, getString, instead.

String savedCity;
String savedCityID;

class _DemoState extends State<Demo> {

@override
void initState() async {
super.initState();
await Prefs.init();
savedCity = Prefs.getString('savedCity');
savedCityID = Prefs.getString('savedCityID');
api.bizListAPI(widget.subCatid, savedCityID, supSubFinal, areaFinal).then((response) {
setState(() {
bizListOBJ = response;
});
});
}

Personally, I would prefer such ‘asynchronous operations’ be delegated to their own function/method. Leaving the initState() function without having been labelled with the keyword, async.

Again, such approaches comes only with experience.

String savedCity;
String savedCityID;

class _DemoState extends State<Demo> {

@override
void initState() {
super.initState();
Prefs.init();
setCities();
}
void setCities() async { savedCity = await Prefs.getString('savedCity');
savedCityID = await Prefs.getString('savedCityID');
api.bizListAPI(widget.subCatid, savedCityID, supSubFinal, areaFinal).then((response) {
setState(() {
bizListOBJ = response;
});
});
}

Good luck in your efforts.

Greg

Freelance Developer

Freelance Developer