Geeks With Blogs

News
Neat Stuff Read all my hurricane entries While you are here, visit the Geeks With Blogs main feed
Advertising
Links Status of the Navy
Channel 9

.NET Hobbyist Programmer Staying Confused in a Busy World

Since I am building a reference application, I need to set a few design criteria to start off the process.  I expect these will evolve somewhat over time, but time is what I have.  Therefore I will build a large, detailed list with the hope that I will eventually get to everything.

 

I am trying to design a robust application without mentioning anything that it does.   Just what is a robust application?  In a perfect world, it would solve the user's problem immediately, completely, and without error.  The first two are a reflection of the application's design.   Does it solve the problem it was created for?  Is the user happy?  The last item is under the control of the programmer.  Does the application have errors?  If it does, can they be identified, corrected and the application updated?  Can this process happen quickly?  This latter ground is fruitful for exploration.

 

Also, is the design of the application flexible enough for the developer to easily and rapidly add and modify its capabilities?  This is related to the ability to rapidly correct faults and respond to customers' desires.

 

Here is my initial list of elements that will contribute to this robust application.  Comments are welcome.  Sorry for the length, but as I said above, it turned out to be a long list.

 

General

  • There will be a two-part executable. The first part (“AppStart”) will incorporate all the one-time use code required for the startup logic.  Single use code goes here. The second part (“AppRun”) will have all the run-time logic and user forms. This method will minimize the memory footprint of the main program.
  • Written using Microsoft Visual Studio .NET with Visual Basic and Visual C#
  • Document/project focus
  • The program will not include third-party controls or libraries. All code will be held as source rather than binaries.
  • Unit testing fixtures will be used throughout.

AppStart Program

  • Implements single instance application model
  • Displays a threaded application splash screen
  • Conducts user registration process (if required)
  • Program Update Manager
    • If the user has specified that automatic checks for program updates be performed, it is done here
    • Uses a modified Microsoft Updater Application Block
  • Verifies level of registration permission
    • Evaluation (no file saving, printing, or copying)
    • Standard (or Basic or Silver) - this adds back the file saving, printing, or copying
    • Premium (or Advanced or Gold) - based on Standard, this adds specialized features on a per feature basis
    • Universal (this includes everything on a subscription basis)
    • Developer (allows access to embedded diagnostic code)
  • Verifies available functionality and compares it with what is authorized by the level of registration
  • Specialized plug-in manager
    • Allows specialized startup plug-ins to be run as appropriate
  • On first run or when the installation has changed, offers to search for and copy data files from the previous installation
    • Optionally, this may also convert old files to a new format
  • Processes the command line arguments into a collection (switches and file names) for action
  • Starts AppRun Core program

AppRun Core Program

  • Cannot be run independently; must be executed from the Start program
  • A standard class to inherit all forms from with the following features
    • Forms collection support
    • Response via program events to system garbage collection via compacting memory messages
    • Response via program events to system settings changes
    • Automatic layout support
  • Unit testing framework
  • Document/view model
  • Either SDI or MDI with the ability to switch between the two at run time
  • Fully extensible with multiple generic managers
  • Almost everything is implemented as a plug-in to provide the easiest updateability
The following is implemented in the Core program
  • Exception Manager
    • Manage exceptions in an efficient and consistent way
    • Isolate exception management code from business logic code
    • Handle and log exceptions with a minimal amount of custom code
    • Custom application exception class
    • Handlers for unhandled exceptions
    • Enhanced assertion handling and display
    • Enhanced Message Box that is tied into the logging framework
  • Logging Manager
    • Input to central destination
    • Output to multiple destinations
    • Output via custom trace listeners to
      • File on disk
      • Windows event log
      • TCP socket
      • Memory
      • Email
      • Console
      • Debug
      • Trace
      • Null
  • Plug-in Manager
    • Manages the plug-ins (dynamically loaded system components), dependencies, and initializes, starts and stops them
    • Insertion point for pluggable components
    • Programming interface through which the application and the plug-in will interact
    • Module loading and unloading
    • First plug-in to be loaded will always be the Plug-in Load Sequence Manager to load hard-coded menu and layouts
    • Command Manager interactions
    • User interface interaction (menu and toolbar items)
    • There will be both an internal (for developers) and (eventually) external plug-in interface (for third-party developers)
    • The Plug-in Manager will track the full details of the specified load sequence, the plug-ins that actually loaded, loaded plug-in version numbers, and plug-ins that reported errors or failed to load.  This will be recorded as a CSV file as well as in a collection object.
  • Global Properties Manager
    • The Properties Manager implements a way of storing all forms of configuration variables
    • Provides an application-wide property class which persists custom properties in a file in the personal folder of the current user
    • These properties are the values or states of the application's options and must be available to all program elements
    • This is complicated by a plug-in architecture.  Plug-ins need a way to save their state as well.
    • Implementing an individual property handler for each property is not viable
    • Also, the properties must work in a multi user environment
    • When the user starts the program for the first time, default values need to be loaded.  The program may then be configured according to the user's needs.
  • Resource Manager
    • The application needs the capability of using localized resources
    • The Core program defines a class which allows localized strings and images for the whole application
    • Generally, the default resources would be loaded, then any localized resources
  • Global utilities
    • This is intended to be the small functions that will be needed throughout the program.  The intent is to encapsulate them in a single location.
The following is the standard plug-in load sequence
  • Plug-in Load Sequence Controller
  • Thread Manager
    • Simplifies the process of writing multithreaded worker code and a UI to control it
    • Structured framework to mediate between worker threads and the UI thread
  • User Interface Library
    •  Menu/Toolbar Interface Library
    • Menus with Office or standard look, dockable anywhere
    • Docking windows
    • Tab control
    • Tabbed groups
    • Wizard control/dialog
  • Command Manager
    • Manages concurrency and the command state, checks authorization rules, monitors progress, maintains a command log, and provides the API to monitor all commands
    • Centralized control for user input and program event response
    • Future interface to tie in macro functionality
    • Command management allows a single handler that can react to similar menu and toolbar events
    • Business logic for handling the command can be centralized in one location, rather than spread out in a variety of functions
    • The command manager's job is to provide a mechanism for an application to maintain a list of commands, perform operations on the commands, and respond to command events
    • The application can dynamically add or remove commands, as well as iterate through the set of available commands
    • The ability to iterate through the commands provides the infrastructure for an application to implement dynamic menu or toolbar configuration
    • Features
      • Executing a task in response to a UI event
      • Enable/disable, check/uncheck, or show/hide the controls related to the task according to some conditions
      • UI update during idle processing
      • Set the text of the caption, tooltip, help text, description, command source (DLL or program), tag
      • Set the icons associated with the controls
      • Set the keyboard shortcut associated to the task
      • Debug option to list all currently loaded commands with all available details to an HTML file
  • Messaging Manager
    • Lightweight messaging framework to isolate functional components
    •  This may be overkill for a non-distributed program, but may permit future expansion
  • Print Manager
    • Format control groups
      • Page headers/footers
      • Report headers/footers
      • Group headers/footers
      • Detail rows
      • Multi-page print jobs with page numbers
      • Tabular reports with column headers
      • Centralizes the mechanics and allows the different program areas to concentrate on content
      • Adds print commands to the Command Manager
  • GUI Manager
    • XML-based GUI language parser for .NET
    • Lets you code resources, menus, toolbars, and status bars in XML instead of with procedural code
    • A user interface based on XML can easily be localized using standard .NET techniques
    • Loading this plug-in will create the program's menu structure, toolbars, and status bar
    • This too may be overkill.  There are XAML look-a-likes being developed.
  • Document/View Manager
    • Provides document registration functions, and utilities for loading and saving documents
    • Document: Data associated with a file or stream. The document should support change notifications, file associations, and persistence.
    • View: A class that is bound to a document. Typically these are used to provide visualization for a document. Views always implement IView.
    • Frame: A class that contains a view. The requirements for a frame are determined by the exact implementation of a view.
    • For Windows Forms, views will typically be controls, and frames will typically be forms.
    • Adds New, Open, Close, Save, and Save As commands to the File menu
  • String Manager
    • Central string text provider
    • This will allow easy substitution of changed or translated strings
  • Data Manager
    • Central location for all program data that controls program operation
    • Persists data to disk
    • Loads data automatically on creation
    • Interacts with the Document/View Manager
  • Form/Dialog Layout Manager
    • Automatically formats control layout per program standards
    • Centralizes much repetitive code
  • Feedback/Debug Manager
    • Central location to handle user feedback
    • Interacts with Logging Manager to send error notifications if enabled
    • Adds feedback options to the Help menu
  • Program Update Manager
    • Periodic polling
    • User-initiated update check
  • Unit Testing Framework
    • NUnit is a unit-testing framework for all .NET languages.
    • It is designed to conduct recorded, repeatable testing of individual code classes.
  • Macro Script Manager
    • To make the application extensible, the model should be simple but flexible. It should use familiar programming techniques, languages, and libraries. It should integrate closely into the application. And finally, it should have a minimum of overhead and a maximum of efficiency.
    • The Microsoft .NET platform has a set of classes that offers the benefits of Active Scripting without the drawbacks. This set of classes, named Visual Studio for Applications (VSA), provides a pluggable IDE and debugger for Visual Basic.
    • This is an eventual feature.

AppRun program-wide plug-ins to the Core

  • Modular menu and toolbar structure
    • Owner-drawn menus and toolbars
  • Program options
    • Includes the data class, dialog for user control, and serialization to disk
    • Reflect changes of system user preferences while running
    • XML-based program data
  • Automatic form control layout engine
    • Layout resizes to fit the content
    • Allows easy adaptation for globalization or textual changes
  • Most recently used document/file collections
  • Standard icons in an Image Control
  • Automatic management of temporary data files to ensure we clean up after ourselves
  • Custom controls as required
    • No third-party components
    • Hold source code for all custom controls
    • Distribute with a run-time license so someone else cannot use our code
Posted on Monday, March 22, 2004 5:44 PM Programming | Back to top


Comments on this post: Robustness

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Mark Treadwell | Powered by: GeeksWithBlogs.net