Category: software_design

— WIP — but publishing forces me to come back and continue!

If you can nail a good architecture it makes all sorts of things possible, whereas a bad architecture can weigh like an anchor on your development.

In the last post on software architecture, I showed a solution that I would only describe as lack of architecture. In this post I plan on laying the groundwork for a solid architecture to the WeatherSdbx app. Architecture can also be referred to as software design and describes the inner workings of the app. I’ve found that users/shareholders are usually more concerned about the UI design of an app, which is certainly important, but a well thought out architecture can help the development, testing and deployment move much more smoothly.

The sketch above captures a couple ideas (along with a doodle or three) for the WeatherSdbx architecture and a general one I use for most of my Flutter apps. The central component is the AppMgr which connects the UI to the app components and contains the business logic to run the application.

The components of ver0.1.0 are as follows:

• main app to configure setup
• home screen
• current observation widget
• app mgr

The goal of V0.1.0 is to setup a structure which can be expanded on in future versions with more functionality such as storage, http communication and so forth. One of the goals is to have a structure that functional components can be added to separately, maybe even just stubbed out, to make the entire app easier to build and test.

Beginning a new project as a test bed to discuss some of my ideas for software development/design and specifically Flutter/Dart.  WeatherSdbx is a simple weather app pulling data from the U.S. National Weather Service weather API.  The code for the project is available at the following GitHub repository.

This app includes a layered software architecture to facilitate stepwise development and testing.  By stepwise development I mean the ability to develop features in small steps without relying on the completeness of other components or systems.  An example of this is fetching and displaying current weather observations. 

Without any forethought to architecture, a call to the NWS API could be made directly from the UI to fetch the current temperature for a location.

import 'dart:convert';
import 'package:flutter/material.dart';
import 'package:http/http.dart' as http;

class CurrentObsV1 extends StatefulWidget {
  const CurrentObsV1({Key? key}) : super(key: key);

  @override
  State<CurrentObsV1> createState() => _CurrentObsV1State();
}

class _CurrentObsV1State extends State<CurrentObsV1> {
  late http.Client _httpClient;
  String? _temp;

  @override
  void initState() {
    _httpClient = http.Client();
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    _fetchData() async {
      String stationLatest =
          "https://api.weather.gov/stations/KTIW/observations/latest";
      String uri = stationLatest;
      final headers = {"User-Agent": "(questinginc.com, [email protected])"};
      http.Response response =
          await _httpClient.get(Uri.parse(uri), headers: headers);

      if (response.statusCode == 200) {
        Map<String, dynamic> data = jsonDecode(response.body);
        setState(() {
          _temp = data['properties']['temperature']['value'].toString();
        });
      } else {
        setState(() {
          _temp = "Error";
        });
      }
    }

    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: <Widget>[
        const Text("AnyTown"),
        Container(height: 8,),
        Text("Temp (C): ${_temp ?? ''}", style: const TextStyle(fontSize: 18),),
        Container(height: 8,),
        OutlinedButton(onPressed: _fetchData, child: const Text("Refresh"))
      ],
    );
  }
}

There are a number of reasons why arranging the code in this manner is a bad idea. I quickly came up with the list below and I’m sure without much thought more could be added.

1. Can’t reuse http code in other UI widgets
2. Quickly modifying UI is inhibited because calls to the backend are always made.
3. If backend goes down or dev machine is offline UI will stop working.
4. If backend calls cost money, changes to UI are expensive.
5. If backend changes or another service is used, every http call in widgets need to be changed.
6. Testing is very hard if not impossible.
7. Data parsing isn’t shared.
8. If data format changes, it’ll have to be changed in multiple widgets.
9. Error handling is hard and not shared.
10. Location is hard coded and not shared with other widgets.
11. No data caching or logic to determine if new data should be fetched on request.

I didn’t want to spend too much time on what not to do, but did want to put something down as a foil to a better solution which will be the focus of my next architecture post.