Tuesday, November 12, 2019

#CodeRage2019 - Fluent Creation of controls at runtime!

The Embarcadero CodeRage2019 (worldwide)!



Of course I had to provide a session to this event with one of my beloved topics:

My FluentCreator!

(Part of my FDK - The Firemonkey Development Kit)

The #CodeRage2019 event should only contains tutorials of 5 to 10 minutes of playtime. So I will provide a more detailed session in the next days on my YouTube-Channel 



(Btw. This is my first tutorial in englisch language - I will provide German subtitles on my channel in the next days and if I find the time I will upload my older sessions with englisch subtitles as well)

Yes, this channel has not seen any new content for a long time, but I will provide more stuff in 2020.

The short Version you can find here

If you want to submit a question to the Firemonkey Multi-Device Design Q&A session at 14.Nov.2019, please click here.

Here is the full list for the FMX-week

Please leave a comment or send me an email if you like to see another topic of the Firemonkey development.

Thursday, October 31, 2019

How long does it take to develop a "complete" MVVM framework for Delphi?

This is a really good question. (Btw. what is complete? We all know a framework is never complete)

Maybe you have a different question in mind... Is it worth to spend x man days trying to develop it? 

Spoiler - Yes!

If I had not believed that it was possible, I would never have started another attempt. 

If you have not read my other posts about MVVM - yes I've been trying this since 2015. (Of course not all the time).

Is this my last attempt? - I hope so - or better, I hope that this is the final version that fulfills all my wishes - as well as yours  (one of which is to prove: Yes, with delphi it is possible to develop a framework with the idea behind MVVM)  

Most the time I had to spend on a better binding structure, studying the source of this unit... Oh boy, I have to refactor this code for better readability.

We all know the MVVM images with the three colored boxes and  the fancy arrows labeled with read, write, binding, propertychange, event or whatever. Everybody starts with this.

Then you google for tutorials or search at youtube. Yes, you will find some stuff, but if you dig deeper and depper into MVVM you have to rethink about these videos. So many mistakes. (of course from my point of view).

On the surface, the MVVM-Pattern is just a guide how to separate the visual parts from logic and put everything in a state to be able to perform unit tests. Is this so? 

Yes, but the devil is in the detail.

And everybody is doing it a little bit different. Then you learn from this tutorials how to do "a" and by reading more and more "a" is suddenly an antipattern and everybody is blogging about "a" is bad you have to do it like "b". Sometimes it sound like the discussions about using FreeAndNIL. (Please no comments on this topic) ;-)

Who holds the instance of a, who can create b and how to perform c? Using the approach from a tutorial or is there better way? - is the better way still the "right" way? - and who decides this? Some experts or MS? What is an expert in MVVM? 

If you are in front of your screen staring at an empty unit in the IDE - I call this 

"The loneliness of development" 

you easily get overwhelmed from all the decisions you have to make. #AloneInTheDark Only if you are using the darkstyle!

My advice - talk to an other developer. Perhaps she/he is not right or has a complete different idea or opinion - that does not matter. Take the feedback and do it your way, perhaps you can adjust your first idea with the feedback.  

And here I am - 3 month into the final version. (only in my spare time I do the MVVM development). It's working - and it is fast - and it is easy to use - and there is (nearly) no code in the View/Form - and most of the necessary (stock) visual controls are already working (no imposer necessary) - and you have to write less code you would expect - and I love the implementation. 

More than half the time is debugging time (so far). I did not use TDD this time, because I had no idea where to start with the tests. 

Good news:
- The implementation is working with FMX ( this was no question, wasn't it ) but also with VCL.
- I have a small team of developers for beta-testing.
- There will be two different versions. Of course as a Plugin to my FDK, but also a stand-alone Version.

The FMX Version is more advanced at this state and the VCL version will see "the light of release" a little bit later. The documentation is not existing at the moment and to show the benefits of the framework I have to do some youtube-videos - this is for sure. But not this year - perhaps you will see "something" at CodeRage 2019. (Nov 11. 2019). But this is not decided today.

To answer the question of the blogpost: 6 Month or 4 to get a beta and perhaps one more month for documentation and another one for videos. I will use the FDK installer, that is capable of doing the user registration, updates, online-store and invoices. (bug tracker is coming) Two month. So overall until everything is out including VCL - The final answer is one year.

I assume, that with the final framework, I will be able to create MVVM based Apps at least in half the time then before, just a little bit more than doing good old RAD-stuff, but everything testable. By combining this framework with my FDK you can build a multi-platform-app in weeks instead of month. 

The future of App-development will be great.

PS.: The new Version of the installer is using gnostice document studio for FMX. At forentage I told everybody that I not using this component by myself - this has changed. Thanx to my friend Girish Patil for the support.


Tuesday, October 15, 2019

FDK Version 2.0 Beta online!

Hello FDK fans!


Finally the new Version 2.0 is online. As always, you are able to order and download it with the setup application.

As we haven't done any updates is the last year, there will be a special offer:

If you're already a FDK-customer you can order an update of you Version 1.0 only for 29,95€. If you like to update to Version 2.0 (beta) there is a discount until 15.12.2019, so you get the update for only 199,- €. The normal prize is 299,- € for the update.

If you are new to my FDK the prize for new customer is 399,- €. If you like to order the FDK with a online lesson, just send me an EMail.


Greetings

Monday, October 7, 2019

MVVM for legacy Apps?

Most developer would not do this step. But what kind of refactoring you want to do?


Well, if your app is still pre-Unicode, you probably have more to think about than implementing a MVVM Pattern, isn't it? Let me take a look into my crystal ball:

One problem of your migration is: If you change one thing at one end, you break something at the other end. I assume you have no or only a few unit-tests. Your app is not testable, because all of you business logic's are in your forms and everything is using nearly every other unit? You have references all over the place and have not used one interface?

Welcome to the club.

Perhaps it is even worse and you're using (typed) Short-Strings as Var-Parameters everywhere?

So your migration is not a "one shot changes everything for good". It's more like change a little bit here and there and hope for the best. I hate to say it, but I'm doing the same for many years. Starting with old components!

I have the source, but it is really to complicate to migrate every old stuff. (And why it is working) so the best way is to do an interface wrapper and if everything is still working, I can put this in a DLL compiled with the old delphi and uses this DLL from Rio. Perhaps some time replace this with a new implementation.

So far so good. One problem is still in place, I'm not sure if really everything is still working, because I can only do some "human application tests". Wouldn't is be great if I had at least 10% unit-tests coverage of the main core stuff? How to accomplish that?

Here is the deal: Convert your app step by step to MVVM. Normally it's not so complicated, because in 99,9% every Form is one View, every Frame is one View and normally you would end up only with a 1:1 relation. Do you need a Model? In a best case scenario, yes!

A part of my #DMVVM framework would be related to do this kind of "easy" migration. But there are still some problems: No real RTTI and generics in D2007. If the framework can compiled with D2007 - possible not, but perhaps the D2007 stuff could be in a DLL.

Stay tuned...

Tuesday, October 1, 2019

FMX-Styles Update

Prior posts about FMX Styles!

Here a little update:

I changed all the SysColors zu $FF000001 and all Colors to $FF000100 then exported a list to see if these color values are used elsewhere. And yes they are...
Not the colors from the Colors tree, but from the SysColors-Tree. So I changes all "not found" colors to 000101,000102,000103,000104... and so on.

Then I compared the to exports:



So here is an update of the used SysColors:


EditStyle Selection-BrushColor and other selections using the clHighlight Color and for Focus. Like in Grids.


Funny the Grid-Lines are using clBtnFace.

The ListView is perhaps (not in the Styleviewer) using the clWindow Color for Background and ItemBackground (not confirmed). And the TEllipse is using clBtnText for Fill-Color - strange - also not confirmed.

That's it.

Monday, September 30, 2019

Did you try to design an FMX-Style?

Do you like the styles that are included or downloadable from getit?

Perhaps you have tried to design your own style with the Bitmap-Style-Designer. 

Did it work for you?

Perhaps the problem is, that the Style-Designer is more on the VCL side... Lets take a look. First create a new "Modern Windows Style". There are two color entries (Colors and SysColors) Let's set all Colors to green (Except three that are really needed) and all SysColors to Cyan except the only two that are used from here. Then ist looks like this:


If you change a color like "Window" (I did orange) the color value is not indexed to to all components, the color is copied to the components. Like:



Perhaps its a feature to be able to change this color...

Hmm and where did I already set the font- /back-colors to white / black? 



OK, some colors are not set over a color values, because the color is rendered from the bitmap.

Take a look at the edits.


Wow the Edit background is lighter, but how to set background color? It's set by this bitmap. The background of this image-part has just a  not 100% transparent Alphacolor. 



The Run-Test-Button is helpful, because you can change something and check the results... Like this:

That is colorful - but where are all there colors from? Not from the color settings - to bad! This colors are set under Listbox (but not all).

Listbox Header - two different colors - but not set with header:


If you think this is perhaps set with PlainHeader, no PlainHeader is the Teal-Group Header and of course always the Font-Color not the Color entry. It would be to easy just set PlainHeader.Text.Color := clBlack. and this property will also set the Fontcolor. The blue GroupHeader is set by GroupHeader.Text.Font.Color and BottomDetail.Text is also set with BottomDetail.Text- thats fine. DetailText is correct. PlainItem is not PlainItem. DetailText2 is not Detail it is the ItemText5 and Detail from this is set with BasicText2. Get confused?
Scroll down there is a single entry for ListBoxHeaderLabel - this is the other ListBoxHeader. The other (Black ListBoxHeader) is not set under Listbox, because this is a ToolLabel and set under ToolLabel. This is the same for the ListItemButton.Text.


And this colors?
Purple backgrounds are set with - roll drum - clBtnFace under Syscolors. This is also the color for the Splitter.


The yellow border is set under Colors - Border.
But where to set the Arc and the CornerButton? This is not set by the Bitmap...


Here comes the best part. The CornerButton is set with a gradient and the gradient has two colors.
And no - the color is not set over Color and of course not set over Font.Color the Color value hast Du be set over PARAMS! But don't forget to switch From ARGB to ABGR (Blue and Red color switch places)

This is not a complete list of problems with the colors and I did not test this colors with a real world app so far. I did not test this on all platforms. I will try to implement some kind of color - converter - post-setup for the styles... 

So stay tuned.

PS.: Here is a litte update!

Wednesday, September 18, 2019

MVVM PropertyChanged is not Component related!

What? I use many components!

ok - lets assume you have a Button on the Form and the button is labeled "Save". How do you want to handle this button? 

1.) You can use this button like a web designer and after the button is pressed you can show up some hints : "Password missing", "Email missing" or whatever. So the user can press <Save> and directly see what is missing.
2.) You can disable then Button and enable it, if every fields are filled as you expect.  This is kind of a guessing game or you must have some remarks like "*" for fields that has to be filled. The drawback is, sometimes you have to search the view for the little missing "I agree" checkbox.

In a few situations I like (1), but in most cases I use (2).

So how to handle this in the ViewModel?  PropertyChange('DisableButton')?

No, this is wrong.

You have a property at the ViewModel like:
Property CanSave : boolean read fCanSave write SetCanSave;
In the setter you can fire PropertyChange('CanSave') and every component that has to change something could be informed by this event. When a component got his PropertyChanged call it can ask the ViewModel.

SaveBTN.Enabled := fViewModel.CanSave;

ok. 

This is the same stupid thing, already mentioned in my last post. I know "you" can bind a button to an ICommand, but that is not my idea. My PropertyChange would also include the boolean so the component or better the binder can set the value directly. Of course any boolean field could be bound directly, but what if I must do a little bit more? 

One of many ways to handle this, is a simple procedure:

Binding.Bind('CanSave',Procedure(aEvent:TPropertyChangedEvent )
  begin
    if aEvent.ParamCount = 1 then
      begin
        if aEvent.Args[0].AsBoolean
          then StateImage.Bitmap.Assign(YesIMG)
          else StateImage.Bitmap.Assign(NoIMG);
      end; 
  end);

I use this approach for everything that is not working out of the box. (Implementation is currently still under consideration in some parts)

And this is the main thing. The ViewModel knows the Model (in most cases) and the View know the ViewModel. But the Model does not know the ViewModel and the ViewModel does not know then View. Perhaps the designer of the View is a different developer than the ViewModel.

Perhaps the Model has already two new fields and the ViewModel has only implemented one of these fields, but the View isn't changed at all. Everything should work fine, because there is not 1:1 relation. What should the binder do? In debug-mode it would be nice if the binder throws an exception "Property not found" and in release mode? It depends on the settings. I like the idea that every Visual Component is set to Visible := false; if the necessary property is still missing in the ViewModel, but this is up to you. How do you handle incompatibilities between the View and the ViewModel? Feel free to leave a comment!

Now, how about the Unittests?

Model is simple, just write your tests. Test for the View? Perhaps. But beside your most important Model-Tests you also want to test your ViewModel. 

Testing your ViewModel without a View must be possible, so your Testclass slips into the role of the View. By subscribing to the 'CanSave' propertychange - for example - and filling all the fields (or not for the negative test), the testclass can check if everything works as expected.

How can you test complicated behavior like the user interaction with a Grid?

Well, this may be the topic of one of my next blog posts about my #DMVVM framework.

So stay tuned.