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 of 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 reading, writing, binding, property changes, 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 deeper 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 on 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 differently. 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 sounds 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 a 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 dark style!

My advice - talk to another developer. Perhaps she/he is not right or has a completely 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 months 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, which is capable of doing user registration, updates, online-store, and invoices. (bug tracker is coming) Two months. 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 than 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 a 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 an 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 price is 299,- € for the update.

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


Greetings

Monday, October 7, 2019

MVVM for legacy Apps?

The 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 an 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 your business logic's are in your forms and everything is using nearly every other unit? You have referenced 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 it 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 doing this kind of "easy" migration. But there are still some problems: No real RTTI and generics in D2007. If the framework can be 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 to $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 change 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.