Tuesday, May 14, 2019

MVVM and Flutter

I've been working a bit with Flutter lately and when I start with a new platform I look for some of the normal enterprise patterns that I implement in my projects: unit testing, mocking, dependency injection an enterprise qualify framework, build services, etc. For all of these I found a reasonable solution except for an enterprise quality framework. There were a few out there that I found, but I didn't feel they fit my needs. Because of this I made my own that did fit my requirements based off the MVVM pattern.

As a reminder MVVM stands for Model-View-ViewModel and is a pattern that is found in many client side applications which makes Flutter an ideal platform. For any of you who are unfamiliar with the pattern you can find information about it here: MVVM Pattern.

To create the framework I wanted to achieve the following design goals to make an enterprise ready framework:
  • The only logic in a view (widget) should be presentation logic, viewmodels represent the app structure and Models are business entities. These concepts should be kept separate and represent the app layers.
  • Views can know about viewmodels or models. Viewmodels can know about models but nothing about what views may be used to display them. Models similarly will know nothing about the viewmodels or views that may use them.
  • Viewmodels and models will not know about anything on a 'higher' layer, but instead raise events when pertinent information changes to anything that may be interested.
  • Views can use a concept of data binding to bind to viewmodels and views and have automatic and potentially bidirectional updates. That is to say, a binding between a view and a viewmodel's property will update the UI when the viewmodel's property changes and the view model's property will be updated when the value in the view changes.
  • There needs to be a way to reformat information in a viewmodel or model in a way that that is needed by the view (value conversion).
  • The framework should have a concept of inversion of control / dependency injection.
  • Navigation is an app structure concept and should be controlled by the viewmodel. Since viewmodels shouldn't know about the Views that use them, navigation moves from viewmodel to viewmodel. It is the job of the framework to decide what view to used for a viewmodel.
  • Much of the default functionality of the framework should be overridable.
The result of this is a framework I call fmvvm (Flutter MVVM). I tried to make it pretty easy to implement. Here are some quick examples on using it:


Once the fmvvm package is added to your app, bootstrapping is just as easy as extending from FmvvmApp and overriding a few methods:

1:  void main() {  
2:   runApp(MyApp());  
3:  }  
4:  class MyApp extends FmvvmApp {  
5:   @override   
6:   void registerComponents(ComponentResolver componentResolver) {  
7:    super.registerComponents(componentResolver);  
8:    // Add component registrations (Inversion of control)   
9:   }  
10:   @override  
11:   String getInitialRoute() {  
12:    // return initial route name  
13:   }  
14:   @override  
15:   Route getRoutes(RouteSettings settings) {  
16:    // return a route object that handles the requested route.  
17:   }  
18:   @override  
19:   String getTitle() {  
20:    // return the app title.  
21:   }  
22:   @override  
23:   ThemeData getTheme() {  
24:    // optionally override to return a theme for your app.
25:   }  
26:  }  

To start fmvvm we've extended from the FmvvmApp object and a few overrides later, we are ready to go.

Creating a model

Models can really inherit from anything, but they should inherit from BindableBase if you want them to take advantage of data binding. For example:

1:  import 'package:fmvvm/fmvvm.dart';  
2:  class Event extends BindableBase {  
3:   static PropertyInfo descriptionProperty = PropertyInfo('description', String, '');  
4:   String get description => getValue(descriptionProperty);  
5:   set description(String value) => setValue(descriptionProperty, value);  
6:  }  

The static PropertyInfo class combined with a getter and setter is what makes two way data binding possible. If the description property changes, an event will be raised so a view that is bound to this object can be updated automatically.

Creating a viewmodel

Creating a viewmodel is similar. ViewModels are items that can be navigated to and are what normally backs a view. Models can also back widgets that are part of a larger view backed by a viewmodel.

1:  class EventsViewModel extends ViewModel {  
2:   final IGalaEventService _galaEventService;  
3:   EventsViewModel(this._galaEventService)   
4:    events = _galaEventService.getEvents();  
5:   }  
6:   @override  
7:   void init(Object parameter) {  
8:    events = _galaEventService.getEvents();  
9:   }  
10:   static PropertyInfo eventsProperty = PropertyInfo('events', NotificationList);  
11:   NotificationList<Event> get events => getValue(eventsProperty);  
12:   set events(NotificationList<Event> value) => setValue(eventsProperty, value);  
13:  }  

There are a couple of things to notice here:

* We have constructor injection! An instance of the GalaEventService is being injected into the constructor of the viewmodel.
* We have a lifecycle event, init(). This allows parameters to be passed between view models. It is called after the viewmodel is created but before it is displayed. This is intended to do any fetching of data.
* We have something called the NotificationList. This class derives from the normal List but raises events when items are added or removed from the list, this can be used for data binding.

This is a small taste of what is in the fmvvm box. It is intended to create an enterprise app structure that can be used in your applications.

For more information on how to use the framework, including setting up databinding, inversion of control and navigation see the package site: fmvvm.

If you have ideas on ways to improve fmvvm I'd love to hear them. Of course, push requests are always welcomed.

Wednesday, March 6, 2019

Machine Learning and the Expectation of Mistakes

Traditionally in software development we've considered anytime an application creates an incorrect result to a bug. A bug is considered an error in a system; not that the application simply made a mistake, but that there is a fundamental flaw in the system itself. Why is this important? Because mistakes are something that can be learned from and can be self corrected while bugs are fundamental flaws in the system where the only way they can be corrected is by outside intervention to change the operation of the system itself.

Last year Elaine Herzberg was struck and killed by an Uber self driving car. Was this a bug in Uber's software or was it a mistake that the software made? This is an important distinction and one for us to recognize is a real question. Traditionally most applications do exactly what the code tells them to do, no less, no more. But machine learning changes that. We have to ask ourselves if the software in that car took the wrong action based on the data that had been used to create the model to date; if the results of this action were fed back in would the updated model in same situation make decisions that lead to a positive outcome (no crash). If the answer to that is no, the base software needs to change, then we have a bug. But if the answer is yes, we have a self driving car that made a mistake based on a new situation that past experience didn't prepare it for and it may not happen given the same situation a second time.

To do complex automation tasks like autonomous vehicles, where the application will encounter unexpected situations, requires machine learning and the concept of mistakes to be successful. To treat all unexpected outcomes as bugs is not sustainable, there is no way that developers will be able to code in every situation into an application a self driving car may encounter or keep updating it as new situations are discovered. But if we are willing to treat them as mistakes that can be learned from with the model updated based on new situations then we have something that is within the realm of reality.

Software that doesn't just have bugs but also can make mistakes leads to some interesting mental shifts that we need to make as an industry and in society at large. Any application that uses machine learning internally should take a look at any unexpected outcomes and ask themselves the fundamental question, "Is there a mechanism to feed back results into the system whereas the model can be updated and lead to a better (or at least different) result next time?" If the answer is yes then no other action may be required other than monitoring or recreating the situation to see if better results are created. This is a big shift in our thinking.

It is also a big shift for society. Families of people killed by self driving cars may not want to hear that the software made a mistake. They likely want 100% accuracy in correct decision making. A standard that we don't apply to people and self driving cars won't be able to meet it either. There are some other and obvious legal and liability questions that will come to play as well.

I can also see that organizations that don't do well with their people making mistakes, likely are going to have a hard time accepting software that can make mistakes as well. They will categorize them as bugs, just like they do when their people make mistakes. This will be another area where organizations who are more accepting of mistakes will likely have a competitive advantage as their culture will be more accepting of the fundamental learning process that machine learning requires.  Requiring the model to be perfect out of the gate is just not a realistic situation in a complex world with nearly infinite possibilities and situations.

So what should organizations keep in mind when starting with machine learning:

- Understand there is a difference between a bug and a mistake.
- Software that has no way to feed back in the accuracy of the model results can only have bugs. Mistakes require the capacity to learn, to improve.
- Mistakes require different remediation action than bugs. Checking to see if a model learned from the incorrect outcome may become a QA question. If it is found that the model can't learn from the situation, then that would become a bug; a flaw in the ability of the system to learn.
- Machine learning models deal in probabilities. The model may return that it is 95% sure a picture has my face in it. Is 95% good enough? Probably, the threshold of acceptability will need to be defined somewhere. But that should not be the end of the discussion. The best applications will have a way to feed back into the model if the results are correct or not so next time the same picture is guessed more accurately.
- Mistakes need to be tolerated, not just by the development team but the management team, the users of the applications and anyone in society at large that interacts with them. Mistakes may feel like the personification of software systems, but the mental shift is recognizing that a system that can learn from bad outcomes has the capacity to make mistakes and requires no self awareness.
- Many models, particularly ones created with deep learning, are black boxes. They cannot be fixed the same way application code can.
- Without allowing for the concept of mistakes, our current software development capabilities will not be able to create systems that can effectively work in complex environments with uncounted and unknown situations they may experience.

The rise in use of machine learning has the capacity to automate things that we have never been able to automate before. One of the likely victims of that upheaval is the understanding that all problems are flaws or bugs. We will have to be more accepting of mistakes, just as we are of our fellow humans.