JwContactsUD became available in the Microsoft Store two weeks ago. A new Android version (1.12) of JwContacts, offering most of the same functionality of JwContactsUD, became live in Play Store’s Beta channel yesterday. Good progress!
I had not done an Android update in awhile and had to re-familiarize myself with the process. After submission I realized there was one improvement I could have done and will the next time. But the new version does work, albeit with one flaw:
Third-party software, including Microsoft’s Xamarin, keeps updating and sometimes there are breaking changes. The latest in Xamarin’s “Material” customization led to an odd effect on three screens: Entry boxes that should be white with green borders and prompt text became filled with light green and, during text entry, turned dark green so the text being entered is totally obscured. In my debug version I reverted to the previous “Material” version but forgot to do so in Release. So the current Play Store version has some undesirable coloring on those 3 screens (Sign In, Sign Up, and portions of Settings). But the boxes still work. This, of course, will get remedied next time I post a version.
The iOS version is actually ready for Apple submission, but I’m holding off slightly longer for 3 reasons:
- It is now theoretically possible to have iOS apps run on a Mac. In fact Apple’s own XCode, which Microsoft Visual Studio silently utilizes as it compiles Xamarin code to native iOS code, actually has a single checkbox to do that when used directly. The Apple technology is termed Catalyst but its operation is repeatable for Xamarin. A project by an expert to do that is underway and I am awaiting receiving its code, as promised. So I may be able to release both iOS and Mac versions simultaneously, maybe!
- A recent Apple policy change might cause my submission to be rejected, but the cure is in the offing. Jwc does open an internal browser for a few operations, but Apple has now begun rejecting new apps that use an old, now unsupported, means of getting the device to display a browser window within. Currently Xamarin still has embedded code that does just that and which has to be stripped out before compilation ends. A hassle! The new Xamarin 5 now promised by the end of the year has removed all such code.
- Xamarin 5 will be the final major release; only bug fixes are supposed to follow. So getting my apps to run with 5 should ensure many months avoiding constant retesting as Xamarin Forms gets updated, which had been averaging every 6 weeks. Since 5 is a major release I would rather not put anything else new out until it is known to be compliant.
Replacing Xamarin Forms (XF) by end of 2021 will be MAUI, dependent on .Net 6 due to arrive November, 2021. MAUI will support the former XF, but app productivity improvements will require some rewrite. As it is now, there is a strong one-to-one relationship between a “control” (some portion of a visible element) in the common Forms code and a “renderer” specific to the type of actual device.
In MAUI there will instead be a sort of contract (an “interface”, which simply lists what a kind of control MUST do at a minimum). Each device type will need to have its own handlers for the MAUI interfaces and any common code will simply request the device perform an appropriate operation listed by the interface. Neither the handler nor the caller need know of the other’s existence. Thus calling code could be generated many different ways, nor just in the Xamarin style. And the device could belong to a type not yet supported by XF; all it has to possess are the requisite handlers.
How quickly could Jwc take advantage of this new technology and thereby run (and run faster) on even more types of devices? In part, that will depend on the gradual introduction of the handlers by all third-party suppliers. And my willingness in at least one case to spend hundreds of dollars to upgrade any whose supplier for whom I had stopped maintaining a subscription. Sometime in 2022, perhaps, maybe.
A word on the Android release: Prior to publishing an app Google does an automated test on a few very different real devices. I had seen steady failure reports throughout my Play Store postings, but only yesterday got to view a video of such a test. Turns out the automated test is not smart enough to do anything more (apparently) than to “press” several of the buttons on the opening screen, ignoring the control that really counts: The Acceptance area on the right of the top line. So it never tries to “use “ Jwc. Thus the reported failures have to do only with the functions on the two lower lines, three of which do various connections to this web site.
I will beef up those areas so any issues there never result in app crashes. That should end the bad reports. But I may also look into making real use of the testing framework Microsoft itself provides; unfortunately it is neither free nor cheap. As a sole developer it would take a lot of time just trying to figure out how to make effective use even if I could afford it. But having worked with Jwc now for years I feel confident most dedicated users will not see issues and, if they do report some, those can be quickly addressed.
Thus I find myself in a bit of holding pattern waiting on XF 5 and on the help in making Jwc’s iOS version run on a Mac. Meanwhile I am devoting myself to learning Apple’s Swift and SwiftUI languages since the Branch has indicated a need in those areas.
