Exrin: What to know when upgrading form 1.X to 2.0?

62 views Asked by At

I'm thinking about upgrading from Exirn 1.x to 2.0.0. I read the Exrin 2.0.0 quick start, but it doesn't mention the changes. From what I can tell from the quick start project, there was a movement away from the grouping of projects based on Framework/Views/Logic/Bootstrapper/OS Level Impletementation.

What other changes occurred that I may need to know moving forward while upgrading?

And is it worth changing over to the new project layout implementation? It does appear to be easier to create and manage, but I'm worried about the lack of project separation leading to poor design. Will this be a personal preference or is there a benefit to switching that manifests itself in the update?

1

There are 1 answers

2
Adam On BEST ANSWER

Exrin 2.0.0, was designed to enable a quicker project setup, but certainly not to remove any of its advantages. Exrin 2.0.0 is fully backward compatible, meaning you can upgrade your existing project, and it will still run.

I still recommend the project separation approach for larger projects. I really just wanted to create a quick start, so people can see Exrin in action, before moving it to a slightly more complicated architecture.

The changes in this version are as follows:

  1. Added support for the Exrin Inspector
  2. Enabled in class operations. This still allows the benefits of Operation Separation, but you don't need to create a new class each time to do it. e.g.

    public IRelayCommand AboutCommand 
    { 
        get 
        { 
            return GetCommand(() => 
            { 
                return Execution.ViewModelExecute((parameter, token) => 
                { 
                    return new NavigationResult(AppViews.About); 
                }); 
            }); 
        } 
    }
    

    But you can still do it the other way if you need to.

  3. Removed the requirements to pass through VisualState and IExrinContainer, via the ViewModel. I would still actually recommend creating VisualState, Exrin Inspector won't work without it. But it's now optional, though highly recommended. IExrinContainer is now added via Composition, and you don't need to pollute your own ViewModels, just to pass this back to the base anymore. This is just to support any scenario, where a VisualState isn't required, even though they are rare.

  4. Removed requirement for defining an ISingleContainer, if you just have a simple stack. Exrin now just creates it automatically for you. However you can still use an ISingleContainer if you want. Again, this was just about Exrin doing things for you, if possible, and overriding if you want to.

  5. Coming in beta-2 is, a bug fix for the IsBusy flag. It's recommended that you use the IsBusy flag to show/hide loading or waiting indicators. Every time an operation is run, it sets the VisualState.IsBusy flag to true, then false when finished. There is a 400ms delay (configurable) before it switches it on, just to avoid flicking it on and off every time a small operation runs.

  6. Also in beta-2, there is the ability to add a PreCheck operation, to your ViewModel's Execution object. This means you can set a piece of code to run, on every operation (that returns a bool) and if it returns false it stops the operation. E.g. you could add a check for internet connectivity, and if there is none, show an error message, but not perform the operation. Would stop the repeating of code for each operation.