It is time to get down to the details of what the Presentation Application – let’s call it Presenter for now – will do. This is a first look at the required functionality
- Show list of all songs and other types of items. I will call everything a song for the moment.
- Allow editing of songs, adding, deleting and modifying.
- Show the songs on a separate screen, usually through a projector.
That’s a reasonable start. But even this short list has a number of ramifications.
- Obviously we need a UI of some sort, with a menu, and, I think, associated keyboard commands.
- Where do we store the data, and in what format?
- How will I program the application?
- There is also the more fundamental question. We need to determine where the application will run.
I will deal with the last point first.
I am writing this primarily for myself. I program in Windows, and I use Windows. So it is going to run on Windows. However, if it works OK it would be nice if others could use it. That being said it makes sense to ensure that the app will run on XP and Vista. Anything earlier than XP is not worth worrying about. I know some people are still using Windows 98, but there are not too many of them left. I have had no experience with Windows 2000, and I am not sure of the differences and I am not going to bother finding out.
My current programming environment of choice is .NET. I use 3.0 or 3.5, but I can target the 2.0 framework, although that is not a primary concern. If anyone wants to use this there is a fair chance that they will have to download the framework, or get it somewhere so it doesn’t matter much which one they get. My preferred language is C# so we are set. Almost.
The most important decision concerning the environment is this $#8211; do I write a standards winforms application or a Windows Presentation Foundation (WPF) application? There are arguments on both sides. I have been writing winforms for years and am pretty comfortable with it. WPF, on the other hand has a lot going for it. It is likely to be the standard for Windows client applications in the future. There is a lot you can do with it. And, while I have been playing around with it, it is still fairly new to me. Part of the problem is that much of the design is done in xaml (Extensible Application Markup Language) which is xml with the appropriate namespaces, more or less. But it does follow the rules of xml. I am more comfortable with c# code than xaml. You can, of course, write all the WPF stuff in c#, but some of it would be a nightmare to do. It is a lot easier in xaml. So which to choose?
The answer really comes down to what I want the application to look like. There will be a few screens for editing songs and sorting out which song to display, but essentially the application is a presenter on a separate screen. How am I going to show the songs on a screen? There are probably two ways to do this – there may be more but I can’t think of them off the top of my head. I could use HTML and show the songs in a browser. Or I could put the songs in a Rich Textbox. HTML has its appeal, but this is still a client application. I don’t, at this stage, want to go down the web route. A Rich Textbox will show all the formatting and it will also allow the editing to be done in a similar control. I am leaning towards the Rich Textbox.
Winforms and WPF both have Rich Textbox controls. But they work differently. In Winforms the content is held in RTF (Rich Text Format). To save it to a database I think I would need to store the data in a binary field and I think it would be pretty big. There is a lot of formatting to be saved along with the text. I could also save it as an rtf file, but these are also pretty big. But this is an option.
WPF, on the other hand, stores its Rich Textbox content in a new format call a Flowdocument. This has a number of advantages. First, it means that we don’t, in fact, need a Rich Textbox to display the data. The song can be edited in a textbox but then displayed using a Flowdocument reader. Alternatively, the document can be transformed into a Fixeddocument and displayed using a document reader. I’m not sure if this is a help or not, but it may be. Secondly, the flowdocument is just xaml, and so it can be stored as a xaml file or stored in a database. I’ll get to the database shortly.
So, with either winforms or WPF I can store the songs as either files, or as fields within a database. With WPF, however, regardless of how they are stored, the songs will be smaller, and I think that will be a benefit for load times. So which one. WPF gives me more options at how I display. It gives me more eye candy on the UI. And it is an environment that I really need to come to grips with. So WPF it is. I may regret this decision and change my mind later. Against this, I do have some nice UI stuff for Winforms. I use the DevelopExpress suite of tools for UI in winforms and they are pretty good. If I decide that WPF was a mistake I can go back and build the UI in winforms. The logic will be the same regardless.
The final question is where to store the songs. I much prefer the idea of storing them in a database than in files. If it was a matter of just storing text then I don’t think there is any question. But this is formatted text. So text files may be a better option. If we go the database route there is then the question of what type of data field do we store them in. SQLServer, and some other databases, I believe, have an xml datatype. Xaml is xml, so I could use the xml data type. But the xaml is also just a string. In order to get it into and out of a Rich Textbox or a FlowDocument, I think I would need a stream. That may give rise to the question of encoding. .NET uses UTF16 for characters. Does that mean that if I would need to store as nvarchar rather than varchar? At this stage I have no idea – this is all new to me, I have rarely worked with streams, except for opening and closing files, and updating them etc. But it isn’t a big problem, it is just a matter of performing a few experiments.
But, in any case, it doesn’t matter now. I know that I can store the data in either a database, in some form, or else in files. So I will proceed on the basis that I will be reading and writing flowdocuments, where I will read them from or write them to is an implementation issue that can be put off until we need to address it.
The next step will be some early design work on a basic UI. It will not have to do everything yet, but I want to get a feel for what the application will look like so that I can assure myself that it will work, from a users point of view. That will be the subject of the next post.