Software engineering and GUI design

(1)

Software engineering and GUI design

(NIX SG1 ^EBNE)

Semester expectations Mid-Semester Project

Graphical Interface API-s, WPF MVVM, Data Binding

1

http://users.nik.uni-obuda.hu/prog4/

(2)

Teaching aims

• Getting to know design patterns (lecture)

– Layered application development, MVVM vs MVC – OOP best practices (DRY, SOLID, DDD)

– „Gang Of Four” design patterns

– Martin Fowler’s Enterprise Patterns

• UML modelling (lecture, project) – Tools, diagrams

• GUI application development (practice)

– Getting to know the WPF and ASP.NET frameworks – (Smaller emphasis on framework-specific things) – Following the MVVM+MVC design patterns

– Using XAML and Razor UI technologies

– Create applications capable of data modifications (CRUD)

• Planning and developing a complex game (project)

2

(3)

Schedule (lecture)

3

1 Expectations, UI history, MVVM/WPF intro

2 Software Management: Waterfall / V / XP / Scrum / Kanban 3 Git development/branching models

4 UML 1 (uml tool + use case + wireframe)

5 UML 2 (package/component, state, activity, sequence, class) 6 GoF 1. Creational (+ IoC / DI methods, antipatterns)

7 GoF 2. Behavioral 8 MVC/ASP intro

9 GoF 3. Behavioral/Structural 10 GoF 4. Structural

11 Other patterns (Fowler/DDD + CQRS) 12 Microservices

13 Consultation

(4)

Schedule (practice)

1 MVVM: WPF basics

2 MVVM: Data binding basics

3 MVVM: Data binding with state notifications, ItemTemplate

4 MVVM: Data binding with Commands (separating business logic) 5 MVVM: Messenger/IoC, Layered WPF CRUD  HW1

6 Game: DispatcherTimer + Custom rendering (Pong) 7 Game: Practice exercise (Laby)

8 Game: Practice exercise (Flappy Bird) 9 MVC: Basic structure, Razor

10 MVC: Forms, Layered Web CRUD  HW2 11 MVC: WebAPI, API+WPF CRUD  HW3 12 Consultation, Project defense

13 Consultation, Project defense

(5)

Expectations

• For the signature: 3 x HomeWorks (HF), Project Work (FF)

• Prog4 HF1: Prog3 FF + WPF CRUD (Mar.15. 23:55) Prog4 HF2: Prog3 FF + MVC CRUD (May.03. 23:55)

Prog4 HF3: Prog3 FF + API + WPF CRUD (May.15. 23:55)

Prog4HF git repo (rename the current) + git diff + 2 minutes video

• 1x HF can be re-uploaded if all else is OK

• Signature retake: All HF+FF must be OK

WPF/ASP practice exercise for all participants

• Exam: oral exam from the lecture materials Final grade = exam + 1/3 FF

5

(6)

Project Work Expectations

• Milestone deadlines in prog4_game_requirements_en.pdf

„Last Commit” Deadline: May.08. 23:55

• Project work: usage and systemization of the programming

knowledge you have obtained so far, by developing a bigger task –  Simple 2D platform/action/puzzle game

–  UML modelling, testing, display, presentation (video!)

– YES, we know, WPF is not used for game development (typically due to performance issues: MVVM can be slow due to the event pipeline, and the WPF UI itself is not fast enough either)

– However, this is a nice-looking and (hopefully) interesting way to demonstrate the practical development knowledge you have

– Teams of two, but it is doable alone (ONLY in special cases!)

6

(7)

IGameModel, IGameLogic?

• Principle: the game state can be described using a GameModel instance, this instance will be modified by the GameLogic, and the same model instance is shown using a GameControl in WPF

– IGameModel: describes the properties of the model

– IGameLogic: describes the actions that will modify the model.

These actions can be automatically called (timed) calls and methods called after a user interaction (keyboard, mouse)

– Task of the WPF control: call the automatic actions, and based on user input, call the manual actions as well

– The action modifies the model, then the new model contents can be used to re-display the game

– Eg. Tetris: GameModel = the fixed game area (2D array), the currently falling shape, the next shape, speed, points…

GameLogic = MoveLeft(), MoveRight(), Rotate(), DropDown(), OneTick()

7

(8)

Project Work

• We expect games that is the level of 2D games from 10-20 years ago (tetris, breakout/arkanoid, card games, board games, atari games, mobile games, …)

– From every group, we will select the best 1 or 2, these will participate in a competition  instant/better final grade – Videos from previous competitions: at the prog4 website

• Project members

– Connecting points defined with interfaces: IGameLogic, IGameModel, IRepository + Dependency Injection

– Member#1: interfaces + GameLogic + LogicTests

– Member#2: GameModel + Repository below the logic (save, load, highscores: db or XML) + WPF GameControl

– Single-member project is only allowed in case of an odd group count OR the failure of a project member

– In this case, we don’t want LogicTests and Repository 8

(9)

FF Rules

• Same way, using GIT/Bitbucket – Gitstats = true needed

– 10 tests (with mocked repository)

– Two devs, multiple git branches (master+develop at least)!

• Minimum 5 minute-long gameplay video is expected – Game rules, gameplay

– What are we the proudest of (difficulty/code/functionality) – After the gameplay, you can include code screenshots

• 4x PDF

– Topic, Specification, Plan/Diagrams, Game PDF

• Revisit prog_tools_en.pdf + prog4_game_requirements_en.pdf – Dotnet5 (+ vs2019)

– NetAnalyzers instead of FxCop

• Display-framework: OK; Game framework: NOT OK!

9

(10)

Schedule (project work)

10

1 Manual Teams 2 Automatic Teams

3 Topic (Vague „concept art” + rules) 4

5 Specification (Roles + Game Design Document, EXACT rules) 6

7 Diagrams / Planning (Use Case, Activity, Component, Sequence Diagram + Interfaces (Model, Logic, Repository))

8

9 „Alfa”: Repository, GameModel + GameLogic/Tests 10

11 „Beta”: GameControl + GameLogic/Tests 12

13 Code Freeze + minimum 5 minute-long Video + Gitstats true

• The information required for the UML diagrams will be explained only on the lectures!

(11)

Examples

11

(12)

Examples

12

(13)

Ex.

13

(14)

Examples

14

(15)

Examples

15

(16)

Examples

16

(17)

Graphical Interface API-s

• We don’t create Graphical User Interfaces (GUIs) from zero – Button control, or self-made low-level button?

– Games are usually low-level, due to speed reasons – With an average UI, we don’t need 24 / 60 / 100 fps

• Lowest level: OS

– Main task of the OS layer: GENERIC display

– Should be good for game development, data input forms, or a data processing AI

– Typically an uncomfortable, fast, strongly typed/pointer-based, highly customizable (often not too comfortable) programmer toolkit written in C

• With Windows: User32.dll and Comctl32.dll

– Unmanaged, platform-dependent (UI was always like this) – Theoretically language-independent, but really C++ -only

17

(18)

WinAPI = HWND, Message pump …

18

(19)

Graphical Interface API-s

• Instead of this low-level access, we use externally provided API to access pre-created building blocks/tools

– API: Application Programming Interface

– The programmer accesses only the API, but the OS is always in the background – usually we don’t have to care about that

– However, UI frameworks tend to be highly platform-dependent (e.g. WPF ~ lots of Win+DirectX dependent code)

• They constantly change

– According to the current programming trends and UX

expectations, nowadays a combo of OOP logic + UI descriptor – The aim is the most comfortable, most flexible, fastest, native-

like application development

– HUGE class hierarchies that support all OS controls structured into a meaningful system

19

(20)

Graphical Interface API-s

• Old (not recommended)

– Carbon (Mac OS X, dead)

– Cocoa/ObjectiveC (Mac OS X, deprecated?) – Java AWT/Swing (Java, not developed) – MFC (Windows, C++, dead)

– Windows Forms (Windows XP, .NET, ??not developed??) – Metro (Windows RT) (Windows 8, C#, C++, dead)

– Universal apps (UWP) (Windows 10, C#, dead  WinUI)

• Newer (accessible and recommended) – Cocoa/Swift (Mac OS X)

– Java FX/TornadoFX (Java/Kotlin)

– Borland VCL (Windows/Pascal/C++, deprecated?) – WxWidgets/FLTK (Linux/Unix, C++)

– QT (Linux/Unix/Windows, C++)

– GTK/GTK+ (Linux/Unix/Windows, C++)

– WPF (Windows XP/7, C#, ??? dieing ???) ₂₀

(21)

Windows Forms

• From the first version of the .NET framework (2002) – Truly feature-ready since .NET2.0 (lots of controls,

threading, better VS support)

– Provides managed access to almost all native Windows API controls

– Basically the C# rewrite of the earlier MFC system

• Functionality: only GUI – Mature, VERY stable

– Simple, classic-looking UI interfaces – Creation and handling of windows

– Handling of components (buttons, textboxes, scrollbars… A LOT OF controls)

– Dialog windows (print, open, save)

– Mouse and keyboard input, user events

21

(22)

After Windows Forms…

• Windows Forms is stable, but lots of compromises/problems – Only direct events (few exceptions...)

– Supports only name-based access (few exceptions...) – Only C# code for all: logic, layout, look

– Lack of re-usable styles

– Complex (complicated/composite) controls are overcomplicated and limited

– Problems with list controls (storage and look of list elements) – Lack of resolution-dependent layout

 WPF (Windows Presentation Foundation)

Hard start, but nowadays it is a mature, industrially accepted technology

 Windows Metro, Universal Windows Platform Dead end, bad strategy… UWP  WinUI

22

(23)

23

Windows Forms WPF

Still good (and will always be

good!) for simple UI apps „Rich desktop apps”

Relatively restricted, one-way

solutions Customizable, almost everywhere

External libraries are needed for almost all non-basic UI

functionality

Lots of various devices/approaches have built-in, unified access and unified logical approach

Very mature, old, well-known

(even bugs have workarounds) Used to be under development, bugs/features are sometimes hard to find

Platform-independent (Mono) Platform dependent (Windows) Easy to learn Harder to learn ( rules, tricks)

(24)

GUI API-s: platform-independent

• XAML, C#

– Telerik UI – Avalonia UI

– Xamarin.Forms (2016: Microsoft, 2020: renamed to MAUI) – ETO.Forms

– Uno.Platform

• Mobile cross-platform (Web/JS-centered???) – Flutter (DEC/2018)

– Cordova, Phonegap – Ionic (Angular)

– ElectronUI – React Native

• Web-based

– WebAssembly – C# Blazor ( !!! )

24

(25)

.NET CORE and UI?

• .NET CORE: platform-independent, standardized; after the base classes/EF/ASP we all waited for a platform-independent UI

framework usable EVERYWHERE (desktop, mobile, web)

• WPF is not the answer: MS build/connect, may/dec 2018

– „NET Core 3.0 Preview 1 adds support for building client apps using Windows Presentation Foundation (WPF), Windows Forms, and XAML Islands.”

– „WPF, Windows Forms, and Windows UI XAML Library (WinUI) are now open source”

– UI designers in VS: 16.5 Preview 1 - .NET CORE 3.1: nov/dec 2019

• Platform-independent WPF  probably never?

– https://github.com/dotnet/wpf/issues/48 – „It's definitely not in the current plan”

– „We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF”

– „richlander closed this on Dec 4, 2018”

– „Its closed because its not important to MS. WinUI 3.0 if anything will be more natively portable”

• Platform-independent UI: BLAZOR and MAUI

(26)

Blazor – Now

26

(27)

Blazor – The Future: razor everywhere!

27

(28)

GUI API-s

• Why WPF/MVVM  most of the framework is surely re-useable – The user interface is described using XAML, and not C#

– XAML-based styles and templates ( WinUI XAML, good) – XAML-independent Business Logic ( MVVM+data binding,

very good)

– WPF turned out to be a mature and useable UI technology

– Problem: NOT platform-independent (mobile phones? Web?)

• Why ASP/MVC  guaranteed to be a useful skill

– Fully widespread, mature technology and approach – And it will not change in the future (WebAPI / REST)

– With the blazor / pwa line, its importance will only grow

28

(29)

Typical (classic) layers

29

(30)

Architectural patterns

We talk only about these

• Model-View-Controller: Classic Web layers

• Model-View-ViewModel: „Classic” UI layers

• MVVMC v1/v2 (combinations of the above) There are MANY alternatives

• MVVMC v3 (with Coordinator: Swift/iOS)

• Model-View-Presenter: Silverlight, Android (Activity/Fragment)

• Model-View-Intent / Redux: React UI

• Model-View-Update: similar to Redux „next-gen” UI (Flutter, MAUI)

https://github.com/dotnet/maui/issues/118

https://dev.to/adammc331/mvwtf-demystifying-architecture-patterns-ap1 https://thomasbandt.com/model-view-update

https://steemit.com/utopian-io/@tensor/using-the-elm-architecture-or-the-mvu-pattern-with-dartea-inside-of-dart-s-flutter-framework

30

(31)

UI layers  **MV* layering**

(32)

MVVM

• Typically used in modern GUI frameworks (WPF, UWP)

– User input reaches the VM via

events/commands from the view’s controls, then it’s relayed to the Model – Data binding between the view and the

viewmodel

– The model updates the vm via events.

Viewmodel updates the view via events – Direct data manipulation is not

suggested

(bi-directional dependency is BAD)

• Business Logic = Model

(Model = Business Logic Model)

(33)

MVC

• Typically used in: Web frameworks (ASP.NET MVC (C#),

Spring (Java), Symfony (PHP))

– The user sends requests to the controller (via browser requests)

– The controller selects a view, fills the

model with data (similar to VM, validation instead of events)

– The view uses the model’s data – The controller returns the view

(or combination of views) to the browser

• Business Logic in the / behind the Controller

• Model = Data bag (filled with data required for the view)

• Extra layers behind the controller!

• Same with a REST call, the reply is a JSON instead of a view (HTML)

(34)

MVVMC v1

• Serverside MVC, where we split the View layer into a proper MVVM

OR

Clientside MVVM, where the

Model (logic) layer is the serverside DataModel-Controller pair

• Used in: modern (Angular/Vue.js) web apps (React: not MVVM…

MVC+Flux pattern = Redux)

• Uses data binding and events just like with pure MVVM

(35)

WPF Hello World

35

• Designer + XAML + XAML.CS

(36)

Accessing controls

• In XAML, you can specify names for the controls (in VS2015, this is automatic)

– x:Name=”” or Name=””

– Same, except AutomationProperties.Name VS x:Name

– We will use x:Name, this allows us to access the control via a data field of the window class

– IN THE FIRST WEEK, THEN VIEWMODEL IS OBLIGATORY!

• Name-based access is not the best

– Used to be everyday scenario in Windows Forms

– The logic should not know where the input is coming from (TextBox.Text on the right side, or Slider.Value on the bottom?) – The logic should not know where the output is going

(Label.Content on the left, or a diagram, or a dialog?) – Solution: let’s use the MVVM design pattern

36

(37)

MVVM philosophy

• ViewModel class: we map the data that can be displayed and the data that can be entered into class properties

• Start as:

– 1 public property in the VM class  1 public property in some control

– 1 displayed data = 1 public property in the VM class – 1 requested data = 1 public property in the VM class – The View/VM properties usually have the same types

• We can use 1:N mapping and different types by adding converter classes

• The VM can be extended with „Command” typed properties to handle the user interactions as well

• AIM: The logic should know NOTHING about the controls we use!

(38)

MVVM – Connection

Connect the control’s property with a property of the VM:

<TextBox Text=“{Binding Path=Income}” ... />

1. Source object  DataContext  One specific VM instance (unique source is possible: other control, template, …)

2. Source property  Income  VM.Income (public property) 3. Dest. object  TextBox (Dependency object)

4. Dest. property  TextBox.Text (Dependency property) 5. Mode (OneWay, TwoWay, OneWayToSource, OneTime) 6. Update source (Explicit, PropertyChanged, LostFocus)

7. Converter (If we the source/dest property have different types)

View (XAML)

View- Model

Model (BL)

DATA BINDING

38

(39)

MVVM – Automatic synchronization

• We query the VM once when first displaying the window. And later? The window will not know when the VM changes…

• The VM must implement the INotifyPropertyChanged interface, that requires a PropertyChanged event

• The View (the framework!) will subscribe to this event

• We will raise this event when a property changes inside the VM

• Via the data binding, the framework knows where the modified property is bound to  automatic getter call  the connected UI properties will refresh

View (XAML)

View- Model 0. GET

2. EVENT 3. GET

1. Modification (from anywhere)

39

(40)

MVVM – Create VM

• In XAML we connect the control’s properties with VM properties, the VM’s getter/setter calls are automatic

• VM can be created from C# or XAML code, we will prefer the latter

• Important philosophy: 1 XAML node = create instance / set property

<Window.DataContext>

<local:ViewModel />

</Window.DataContext>

View (XAML)

View- Model

Model (BL)

DATA BINDING

40

(41)

MVVM – Create VM

• Create the VM as resource

<Window.Resources>

<local:ViewModel x:Key="VM" />

</Window.Resources>

...

<Grid DataContext="{StaticResource VM}">

View (XAML)

View- Model

Model (BL)

DATA BINDING

41

(42)

MVVM – Create VM

• Create the VM from xaml.cs (not preferred, loses autocomplete and XAML VM support)

ViewModel VM = new ViewModel();

this.DataContext = VM;

View (XAML)

View- Model

Model (BL)

DATA BINDING

42

(43)

„False” MVVM: logic in the xaml.cs

View (XAML)

View- Model

xaml.cs (BL?)

• Access VM created in XAML

ViewModel VM = FindResource("VM") as ViewModel;

ViewModel VM = this.DataContext as ViewModel;

• Then perform operation in the event handler (xaml.cs)

VM.Result = VM.Income * VM.TaxPct / 100 - VM.Prepaid;

NO NAMES – THE LOGIC KNOWS NOTHING ABOUT THE UI!

READ VM WRITE VM

DATA BINDING

UI EVENT

43

(44)

MVVM usage

View (XAML +

xaml.cs)

View- Model

Model (BL) COMMAND +

PARAMS EVENT/

MSG/RESULT

• Aim: the logic knows nothing about the controls, but the layering should be appropriate too (every layer must only communicate with the layer below, and use events to send messages upwards)

• In the prev. slide, this is not true: UI EVENT, READ VM, WRITE VM

• Also, the same logic can be used across multiple Uis, so the logic should NOT know anything about the VM

• The VM also forwards parameterizable interactions (Commands) towards the logic, the logic uses result/event/message to signal the completion of the operation

DATA BINDING

44

(45)

Full MVVM

• The view only knows about the VM: UI properties are connected with the VM, and they are refreshed according to the settings

• The view events are also connected using data binding to the VM properties with the type ICommand. (The xaml.cs is almost

empty, it can only handle strictly view-only events)

• The VM knows which Command should execute which logic

methods, and using what parameters. One VM can use multiple business logic components, in a single/multithreaded way

• The logic knows nothing about the VM: the same logic (and other layers) can be used for GUI and non-GUI applications!

Software engineering and GUI design