I just discovered an unlisted YouTube video Ray Konopka did in 2018 for Embarcadero's CodeRage called "Mobile View Management with Ray Konopka from RodeRage 2018.
Although the demo and source code for this presentation is based on a mobile app, the concept Konopka presents is not just for mobile apps. It's actually a blueprint for creating any type of FMX app using Delphi.
Blueprint for Creating Delphi FMX Apps
I was compelled to write this blog for two reasons. The first stems from the fact that this is not just for mobile app development, it's for any FMX app development. And number two, the concept is simple, powerful, and elegant.
The source code Konopka used is available for download using this link https://delphibydesign.com/downloads/
From the Mind of Konopka
It doesn't matter whether you are brand new to Delphi or a seasoned Delphi veteran, if you get the opportunity to download and study an application built by Konopka, TAKE IT. You will learn so much. It's an opportunity to explore the mind of Konopka.
Konopka embodies the meaning of my favorite quote from Albert Einstein. "Make everything as simple as possible but not simpler."
Enjoy!
Semper Fi
Gunny Mike
https://zilchworks.com
I remember that CodeRage 2018 videos were only available through Embarcadero Academy, but they now have a playlist on their YouTube channel.
ReplyDeletehttps://www.youtube.com/watch?v=Ye6geL721yw&list=PLwUPJvR9mZHjaALr9xbcwVNZRjFaL8QeQ
Thank you for the playlist link.
DeleteThank you for sharing. Reminds me a bit of the Wizard Framework that I developed back in 2008 (http://delphiaddict.blogspot.com/2008/12/delphi-wizard-framework-design.html), however using strong types rather than class names as strings. That pattern works very well for wizards or other applications where you have a path of views you navigate through. The one think I dislike in Konopka's approach is the requirement that the main application form handles the decision logic for navigation. While this may work for simple applications, if you get to ones where you have multiple forks that go in to different forks, the state is difficult to manage...expecially if you are in a team of developers all working on different "modules". In my world, each form (or its controller) would determine what the next form needs to be displayed, forms would be added via a stack, and the back button would just pop the last form from the stack. If you use the class registry (or any other factory pattern) you can perform lazy construction and only create the forms on demand, likely saving resources which could also be an issue in larger applications with lots of data.
ReplyDeleteSKamradt, I'd love to see an example of how you would employ the "factory" pattern you talk about. Would you put together a video that show how to do this and include a link to the source code?
DeleteIts really not complex. Just have a central global repository (look at RegisterClass / GetClass in System.Classes for example) and then have a global function that given a class name, returns a new instance of the required class. If you want to roll your own you can use a TDictionary and have some common method of adding to the dictionary. If you want to make sure that your registry only contains forms, you can use TDictionary. You can also look at the spring4d library which also has additional methods of dependency injection that are useful.
DeleteA good video on dependency injection would be https://www.youtube.com/watch?v=j9qvJiDz7ME by Nick Hodges using the Spring4d library.
Delete