The MIT App Inventor is a free development environment, and there are over 20 other alternatives, all free. But these are tools for developing software for Android. The market for software is huge, and Android is only one of the target platforms. For general software development, the Windows platform is the largest market.
Browser-based applications are stateless, which means that every page that displays tables of data has to reload the data every time the page loads. Executables, on the other hand, hold their data in memory, so that going from page to page doesn't require reloading the underlying data. For most business applications, executables are preferable, and even essential. So we need a development environment that allows us to develop both web and executable apps. Visual Studio 2017 does exactly that. And although the professional editions go for around a thousand dollars, there's a Community Edition that's free. That's what we'll use for the CODE Pathway seminars.
Before starting your software development work, you should download and install it. This page explains how to do it.
The place to start is the Microsoft Software Download page (https://www.visualstudio.com/downloads/)
The Community Edition is the free version. Click on it to launch the installer options page.
The installer options page asks which workloads you want to install. Choices include:
For the purposes of our seminars, the checked selections should be installed. You can add more any time you want. The Install button is at the bottom right of the page. This will take a while, perhaps half an hour, so it's a good time to go walk the dog. I'll wait right here.
Oh, good, you're back. Open Visual Studio to see what you've got.
The first time you run Visual Studio, it will ask you to select a theme (you can change it later). Dark looks like a good choice:
You're up and running! If you choose to be a developer, the Visual Studio Integrated Development Environment (IDE) is where you'll spend most of your time for the next decade or so. Let's take the Grand Tour.
The Tools, Options dialog gives you the chance to change any of literally thousands of settings within the IDE that control how Visual Studio looks and works. I've been using it for about 20 years, and I still learn new options frequently. I'll just touch on a few settings.
Unless you turn off the Show Start Page option (Tools, Options, Environment, Startup), you'll see it at startup:
I like to make code larger and easier to read, since I'm often displaying a code window to a roomfull of people, so I use 14-point Courier New for Text Editor Plain Text:
I like to see line numbers and the wrapped text of each line:
Tabs two characters wide seem to work well, especially if you publish your code. I just hate code that's too wide to see at a glance. It's probably an editor's bias, but old habits die hard:
Finally, those little notations about how many references there are to each method is called CodeLens.
I have no use for knowing how many references there are to each method...
The Visual Studio menu contains ten main tabs:
Other tabs may appear if (1) products like Progress/Telerik, DevExpress and others are installed, (2) what type of solution1/project is currently open and selected (e.g. WebSite appears if you're working with a website), and (3) certain option settings.
You should memorize the hot keys that you frequently use - F5 to run your app in debug mode, Ctrl+Shift+S to save all unsaved changes, Alt+F4 to close Visual Studio. Also, within certain editors there are editor-specific hot keys. Memorizing them will save you a lot of time.
The container for your work in Visual Studio is called a Solution, which contains one or more Projects. This seems a little Orwellian (or Trumpian) to me; it's not a solution until it solves your problem, is it? Solutions contain one or more Projects, which are compiled together into an executable or simply contained within a web folder.
When you create your first Project, Visual Studio will create a Solution. Its skeleton will appear in the Solution Explorer, usually pinned at the right of the IDE:
When you select File, Projects, New, you're presented with an impressive array of choices. These are called item templates. You can actually author item templates and add them to your IDE. I've never felt the need to do so, but it's there if you need it. 1
Initially, you'll probably be writing mainly HTML, styles, C# code and XAML screen code for WPF screens used by executables. Each of them has its own editor window, so we'll look at them one at a time.
Within a website, web servers assume that a file named "index.html" or "default.html" is the starting place for the website. In Visual Studio Websites, you have to right-click on one of your files and select "Set as Start Page".
Although styles can be embedded within each tag or specified in the <head> block of the <head> section, best practice is to link to an external .css file in your solution folder. The Style Sheet editor has excellent IntelliSense support.
Most of what your programs do will probably come from the .NET framework, which will be revealed to you magically thanks to IntelliSense. When you instantiate (create) an object, it comes with a collection of properties, events and methods that are automatically displayed as a list as soon as you type the name of the object and press the period:
Highlight your selection (in this case, I want an ObservableCollection of type Obits), and IntelliSense completes the expression. It means never misspelling your excessively long property and method names.
Right-clicking on the code produces a context menu of available actions.
The standard item template for a WPF window's code-behind adds a dozen usings that I don't need. Right-click on the code window, select Remove and Sort Usings, and all but three disappear. I like spare code.
The sooner you create a Windows Presentation Foundation (WPF) project, the sooner you're going to get hooked on XAML. Extended Application Markup Language is how you design forms. You can either use the WPF form designer, edit the XAML text directly (often my personal favorite, because I'm such a geek), or open the window up in Blend, the standalone WPF designer.
By the way, the app.xaml file contains a line that says "StartupUri="MainWindow.xaml". Change "MainWindow.xaml" to the name of your startup window.
The original idea of WPF was that a developer could build the data model (the code representation of the (usually SQL) data tables, build rough mockups of the screens and include the names of table columns as databindings, and then hand off the windows to someone with artistic sensibilities. As long as the designer doesn't change the names of the bindings, the form will still work when they send it back. That's the holy grail of "separating the implementation from the interface" that was bandied about for years. I didn't know what the hell they were talking about until I saw WPF. So much for inventing new terms to describe something that everyone already understands...
So now you're a developer. Your job will consist of the same cycle repeated hundreds of time per day:
You set a breakpoint by double-clicking in the margin to the left of the line of code where you want execution to pause. Use Debug, Windows, Debug Window to open up a Watch Window and type in the name of the property whose value you want to see.
Your job for the foreseeable future will be to write code, usually containing bugs, and then to track them down and fix them. That's what breakpoints and stepping through your code are for.
Why not just write code that doesn't have any bugs to begin with? I don't know how to do that...