For the curious or those considering their own development effort or aiding me in mine, here’s some thoughts on JwContacts’ (JwC’s) technical (i.e., programming / software) basis.
About the time I retired in 2016 Microsoft purchased a software vendor known as Xamarin and has since made everything gained available to all free, via all versions, free or not, of Microsoft’s programming environment Visual Studio. JwC is written almost entirely with the use of Xamarin Forms, which allows code to be written in a common language (C#, pronounced see-sharp) then automatically translated into the native code used by several operating systems. Currently Xamarin Forms (XF) supports four well-known systems (Android, Apple iOS, Apple Macintosh, and Windows Universal) as well as a few lesser-known, such as Tizen.
XF is constantly being improved, with updates every few weeks. There have been four major releases (as of June, 2019) and countless minor ones. As Apple iPadOS has just been announced, doubtless XF may well soon have specific support for it as well.
XF version 3 made a significant change in how the C# code is contained (going from the now obsolete PCL (Portable Class Library) to use of Microsoft .Net Standard Libraries), requiring rewrite of all my Version 2 code. .Net Standard is actually just that, a “standard” specification of those abilities every .Net Standard- compliant system MUST provide. Late versions of Android, Apple iOS, and Apple iMac are all compliant, as are all versions of Windows 10 released from September, 2017 onward. JwC ONLY works with such versions.
A .Net Standard common Library does not contain the .Net Standard-compliant code, only a reference to each function. Therefore, the Library is considered a “reference project” and does not itself get included in the released software for each system. Rather XF notes the references used and automatically inserts the actual system-specific code-calling into each XF system rendering.
XF Version 4, just released, has added an entirely new, but optional way (the new XF “shell”), to present visual pages far more easily and, so far, has not required another JwC rewrite. If I were to start over, I’d probably use it.
A single programmer or team could write every bit of required XF code from scratch, but would then be “re-inventing the wheel” for much of it. XF natively provides many of the visual items a user sees, as well as much of the behind-the-scenes functionality, but there remains significant room for optimization for a specific application.
The XF community is broad, including tens or hundreds of thousands of programmers or more. Many have provided additional free tools and visual items (“controls”) after spending numerous hours to derive reliable, trustworthy XF enhancements. Microsoft itself provides scores of these free, and there are hundreds more from others. Many come with sample programs and / or usage documentation, increasing user productivity.
A few commercial companies have developed amazing controls and backbone services that go well beyond the simpler in XF, if they are there at all. The cost to a single developer covers the gamut, from free to individuals to many thousands of dollars for anyone. Obviously, the latter are beyond my consideration.
So, before any XF code was written, I spent half a year learning XF and investigating these separate offerings. After 2+ years more actual development, here is the current (June, 2019) situation:
JwC begins as a XF Prism framework. Prism is free software that provides an initial app skeleton consisting of a common .Net Standard C# code Library and one to three hardware-oriented modules (for Android, Apple iOS, and Windows 10 Universal (UWP, or UAP)).
Note: Windows UWP (Universal Windows Platform) or UAP (Universal Application Program) is Microsoft’s newest way of implementing programs on Windows 10-based devices (PC, Xbox, etc.). In Windows, JW Library is provided ONLY in UWP. The older methods used previously by Windows’ PCs are still mostly available to programmers and some may ultimately be included in XF. The two likely to be around for some time more are Windows Forms (or WinForms, the oldest) and WPF (Windows Presentation Foundation), but neither is yet available via Prism.
Perhaps in time Prism will support more platforms, but it is mostly just a scaffold for getting started. The programmer is free to add others as he wishes and I have long had an Apple Mac module as well. I would like to someday see inclusion of a WinForms or WPF, as these could be downloaded directly from my web site and would run on older Windows platforms. For now, that is not yet possible inside XF and Prism.
Prism provides several other highly-valuable services, especially easy ways of switching among visual pages, of linking visual elements to separate non-visual coding “View Model”s (A highly desirable separation of responsibilities allowing easy change of one (visual or data) without affecting the other. This scheme conforms to the well-known MVC or MVVM, etc. programming patterns), and notifications between code classes when one has an event the other should be aware of. These are all things taken care of for me by Prism and require a minimum of effort on my part.
Prism comes in a few flavors that implement the just-mentioned patterns slightly differently. JwC uses the Unity flavor, not to be confused with the similarly-named Xbox Unity game development software, also from Microsoft. These flavors were just different ways early XF programmers provided for these patterns; Prism has been shrinking the number it still supports to those which remain popular, including Unity. Other than knowing that, I’ve had no reason to think about Unity, just about Prism.
Prism, too, gets regularly updated and I’m “holding my breath” to see what changes the upcoming Prism 7 will require. In the past continued use has forced a few limited rewrites.
When I began Prism did NOT include one very desirable feature which is defined in XF, page “regions”, a visual portion (a “view”) of a page which can entirely be replaced with another view. View is a term applicable to anything which is or holds something you can see on a page, including the page itself. A Button is a view, a piece of text may be a view known as a Label, etc. Every page is allowed one, and only one, child view, its “view content”, which must contain all other views in some way. So, a page consists of a hierarchy of views of various types. This hierarchy can be very simple or extremely complex.
In XF it is completely defined in a special auxiliary language known as XAML, eXtensible Application Markup Language. XAML defines the look of a page as well as the functions coded elsewhere to be called whenever a control (often a view that responds to interactions with the user or outside world) is notified an event has occurred to which it should respond. The coded response may be in one of two other places: XF XAML always has a “code-behind” attached file for this and, in the Prism pattern, there is also a related View Model file. Either can respond or even work together to form a response.
Therefore, all JwC pages involve at least three related files: A XAML file (i.e., home.xaml containing the visual hierarchy), a code-behind C# file (i.e., home.xaml.cs) and a C# View Model (i.e., homeviewmodel.cs). The first two are considered inseparable parts of a single “class” whose duty is to present current data, the last is a sort of overseer responsible for fetching and sending updated data to that class and responding to any interactions that require new fetching, updating, or editing of the data. The View Model also does all work preliminary to implementing the XAML and its code-behind and is responsible for closing the page and initiating a switch to another (i.e. Navigation).
JwC’s home page, the one you reach after fully signing-in, is composed of three elements, the largest being a Region or View consisting of a data grid and several controls especially for the type of data being presented. (The other two elements are the Home page header, with a few common controls, such as “Start Over”, and the slide-in drawer that allows you to select the desired Region.)
Thusly arose my first need to write my own backbone code: Implementing a JwC Region Manager, which allows a single Home View Model to work with over 20 replaceable Home Grid Regions. JW Library no doubt includes something similar in places, although it more often switches out (“navigates” among) entire pages.
C#, like all object-oriented software languages, includes class inheritance. (Example: a car class can be inherited by a Ford class, a BMW class, etc.) Inheritance chains can be of any length, stopping only when a class is designated “Sealed”, or non-inheritable. Much detail can be included in a higher-level class; the lower level needing only to provide the specific functionality for its unique type. Some higher-level items can be designated as “protected virtual”, meaning the higher-level definition can be over-ridden by a lower-level. (Example: a car class might have a virtual function assuming all cars have four wheels; a lower level could perhaps replace it with a function of the same name that makes different assumptions.) In fact, in C#, every class is descended from the very top class “object”, which can be inherited as anything but which inheritance will ALWAYS have available the few protected functions found in “object” such as “.tostring”, which yields the name of the descendant object, unless overridden to yield something else. Even the C# object known as a “string” still has an (unnecessary) “.tostring” function.
JwC makes heavy use of inheritance, as do most modern programs. Although there may be 20+ Data Regions JwC Home page can display, one at a time, all are inheritances of a JwC “RefreshableDataGrid” (RDG) which itself inherits from “View” and implements a third-party commercial XF Data Grid control, adding special protected functions. Providing one specific region actually often takes just a couple lines of code. Some regions, however, also override some of the RDG protected functions.
Prism Navigation did not originally support the use of “modal” pages, often-called pop-ups, which completely or partially cover another page which remains “alive” but with which the user cannot interact until the modal is closed. Current Prism has greatly improved use of pop-ups as have some of the commercial XF vendors, but I have already written code based on earlier free implementations and am not likely soon to rewrite just to use these newer.
Such Popups are of several sorts, especially (1) Dialogs which cover only a fraction of the page to inform or to allow user interaction that will affect the underlying page and its View Model and (2) Summary, Edit, or Details pages, used extensively throughout JWC and completely obscure any pages below, such as the Home page. The latter are a special view known as a “PopUpPage” (PuP), as defined in certain free software.
For both Dialogs and PuPs I’ve adapted existing free software, often because the older was based on PCLs or early versions of the .Net Standard. Their use would require my XF installables to include both old and new versions of the same thing, bloating them and increasing download and install times and wasting user storage. In fact, I’ve striven to keep any use of third-party software free of such encumbrances; JwC now uses only two which I’ve yet to find a way to replace.
And JwC does use a lot (at last count hundreds) of third-party software packages, either free or commercial, including other software THOSE packages themselves use in their operations. So JwC is not small and some devices with very limited storage will unfortunately not be able to use it.
This dependence on third-party software does limit just how many platforms JwC can support. I would very much like to support Apple Mac machines and nearly all my own code is suitable. However even the commercial software I use has limited Mac support; the same is true of the free as well. Unless some expert Mac Witness is interested in helping me address the need and has the required time available, a JwC Mac version may never appear. There is, though, the recent announcement the next version of MacOS (#13) will have a way of running some iOS programs; it may be in time JwC can run on a Mac in such a way.
Was the above useful to in any way, if no more than to just satisfy curiosity? I’d love to hear from you.
David Pressman
