Joe Freeman

Sometimes you just want to create Model objects around some type of JSON payload of schema definition.  It seems like you either end up building your own tool, doing the conversion manually, or hunting around to find some schema generator.  Sometimes there just isn't a tool that you want to use and sometimes there is. I'm working Dart where we want to create immutable objects from deserialized JSON schema for AdaptiveCards.  I ran across an open-source tool, quicktype.io, that can generate JSON serializable model classes for over 20 different languages. There are several different settings that let do some customization.  You can then consume those classes/functions as is  or tune them to your needs. It is a great learning aid even if you don't use it for your models.  I really like how it lets me compare how different languages handle models and JSON. Disclaimer:  I have no idea who created https://quicktype.io or how it is run.  Pull down their GitHub repo and scan it

Flutter is opinionated about using a functional programming model that includes immutable data objects.  I've found that we tend to ignore that whole immutable thing when dealing with JSON data.   Projects can be loose when handling incoming JSON data and how it is accessed, sprinkling string-style map keys across the codebase.  We can reduce that tendency by providing models to eliminate the string keys and mutable models to stop people from directly manipulating maps of strings. Some languages are functional only.  Other languages have no way of generating immutable objects. In those cases, we just end up with objects that can be easily converted into and out of JSON structures and strings. I'm working in Dart right now so the rest of this will be Dart samples Modeling Longitude and Latitude Using the JSON Schema Let's pick something simple as an example.  We're going to use this Latitude and Longitude  JSON Schema  that follows the schema definition style from  http:

Creating tests for various size viewports can help us look for wrapping and sizing regressions.  Our goal is to run the same test across several different-sized displays looking for regressions in the individual display sizes. We can do that by sizing the canvas just before loading the widget tree and running the golden test comparison.  We need either the viewport size for the device or the raw size of the device in pixels and its DPR. So currently this test code accepts the raw size and the DPR.  The alternative is to just run the MediaQuery against the device and accept its width and height with a DPR of 1.0.  The test code below supports both. Test Code There are two tests, one for the Pixel 3a and the other for the Pixel 4XL.  Both tests pass in the raw pixel size and the Flutter DPR. The test  Sizes the canvas to the device geometry. Brings up the demo app Creates/validates a golden image snapshot of the viewport The test app is the MediaQuery code listed in a previous blog artic

We wanted to verify our layout behavior across various screen widths, especially across layout change boundaries. Ex: Change field sizes, expose menus, or make other items at higher widths.  Mobile devices have high-resolution screens that are logically down-scaled for sizing display widgets essentially using a logical resolution. I ended up writing this simple MediaQuery program that tells me the  effective  size of the screen of a device. This lets us build a library of test device resolutions and aspect ratios. We can run the same test across as many devices as we wish because computing is cheaper than manual testers. Flutter golden image tests are a simple way to watch for layout regression.  They compare a stored image against a new image captured during test execution.  The base behavior is that they open an 800x600 canvas and use that.   We can change the size of the test canvas where the golden test images are rendered. What if we want to work in the opposite direction starting

Pictures make it easier to understand how an application is wired together.  This is especially true if your application is reactive with different modules listening for changes and making data changes.  Riverpod has a graph generator that can show you how its providers are wired together. Opt 1: Use a checked-out copy of the Riverpod GitHub repo I generated the following diagram for the example todos application using these riverpod_graph  commands. They assume that I have the Riverpod git repository checked out and that I am in a terminal sitting in the root of the repository.  The riverpod_graph command accepts the analysis target root as a parameter. I explicitly specified the lib directory here to make sure we didn't pick up any dependencies on utilities or tests. This approach makes sense if you think you want to work on the riverpod_graph project or that you always want the latest from git and don't want to remember to activate later versions. mermaid.js format .../ rive