Xojo

Freezing Xojo Web Apps

As reported by Ralph Alvy and several others on the forums (https://forum.xojo.com/51170-2018r3-web-app-appears-stuck-when-it-quits/0#p414878) and in Feedback (53291) Xojo web applications built in Xojo 2018r1+ can lock up with no visual indication or recovery.

This is most prevalent on mobile devices when the user is interacting with your Xojo Web app and then moves on to something else. Behind the scenes the iOS or Android operating system suspends the javascript execution of the browser tab. This severs the link between the user application and the Xojo Web server.

In Xojo 2017 and before this was not a problem because the entire communication stack between the browser and server was built on XMLHttpRequest. This is the browser provided class that enables all AJAX interactivity on the web. Since the inception of AJAX however many new technologies like WebSocket’s and Server-sent Events (SSE) have been released.

They provide a persistent connection between the browser and server in either bidirectional or unidirectional capacities. This helps web applications respond faster to changes as building up a request is very expensive in regards to latency and when generating tons of events can really impair web application performance.

In Xojo 2018r1+ the web framework now defaults to SSE as opposed to XMLHttpRequest for all devices (except Firefox). This is great but unfortunately there is a bug. When a users session times out the users browser needs to be reloaded so a new session can be created and use continued. In the old XMLHttpRequest handlers this was recognized and if a session is no longer available on the server then the browser reloads itself.

Sadly, with Xojo’s SSE implementation there is no recognition that the connection to the server has been closed. A generic error has fired but because Xojo Web was working fine prior to the users tab being suspended it is not aware of connectivity issues. The app essentially locks up from the users perspective as the web framework is no longer listening for server side events and client generated events are no longer capable of firing as the session is invalid. Technically the client generated events do fire but the server rejects them.

Fortunately, there is an easy fix! When the SSE connection is closed the ‘readyState’ property of EventSource (https://developer.mozilla.org/en-US/docs/Web/API/EventSource) changes to the integer 2. I have verified a fix for this behavior by dynamically changing the error handler of Xojo’s SSE implementation to recognize a ‘readyState’ of 2. When it sees that it recognizes there is no recovery possible and it then starts pinging the server to see if it is still available. If it is then it reloads the browser and starts a new session exactly as the XMLHttpRequest implementation does.

To apply the fix is very simple. You want to execute some Javascript after the framework has fully loaded. Preferably you do this when your first window ‘Shown’ event fires. So do the following:

  1. Add an event handler for the ‘Shown’ event for the first WebPage in your Xojo Web project if it does not already exist.

  2. Add the following code:

    me.ExecuteJavaScript("if (Xojo.eventsource !== undefined){Xojo.eventsource.onerror = function (event) {Xojo.eventsource.msgcount--;if (Xojo.eventsource.msgcount < 1 || Xojo.eventsource.readyState === 2) {Xojo.view.preventInteraction();}};};")

  3. That’s it! You can now deploy your app and verify the fix works on ALL devices.

Feedback for Xojo

  1. There is a lot of parsing in the framework going on for WebSockets, Server-sent events, and conventional AJAX to identify when connections have broken, server unavailable, etc. In most cases you capture these events just fine and do the appropriate thing. However, at times when you miss one the web applications appears “locked up” with no obvious way to resume. You don’t know if it is lagging out, frozen, or what.

    I recommend when the server sees data being sent to a session that is no longer valid that instead of returning a generic 404 you send back a “session invalid error” that can be handled. You can then force the browser to reload regardless of the failures that led to the error in the first place. If the session is invalid there is no point in letting the client linger any longer than necessary as no recovery is possible.

  2. There is a lot of EventSource handling code in Xojo.comm.ajax that relies on message counting to determine if there was connectivity failure. However, if connections break down or fail there is no graceful cutover back to XMLHttpRequest as a fail safe. The current implementation just reloads the browser and then attempts to use SSE again despite a failure in the previous attempt. Instead gracefully switch to XMLHttpRequest and only then if failures persist continue with a reload.

  3. You should revisit the absence of using SSE in Firefox. Mozilla is very standards based and I’m sure appropriate workarounds could be implemented to support this methodology.

  4. This is the second Javascript framework issue I have fixed (45691). My previous fix I submitted to Feedback on June 3, 2017 and all you have to do is implement it! Why the delay? I will submit this resolution to Feedback as well but I hope it can be rolled into R4.

  5. One of the great things about Xojo Web is I can investigate and fix the client-side issues. I hope this provides some evidence that an open source standard library would be a good thing! The bits that make Xojo the most valuable (The IDE, the compiler, etc.) can and should remain closed source. The non-proprietary implementations of standard protocols (SSE) could benefit from more eyes on them in my opinion. See part 2 of my 2017 review series on where I talked about opening up more of Xojo’s standard libraries for cases just like these: http://www.dev.1701software.com/blog/xojo-in-2017-part2

Introducing Really Nice Controls for Xojo Web

The Really Nice Controls (RNC) project consists of fourteen high quality, highly optimized controls for your Xojo Web projects. The controls are $100 per-developer in encrypted form and include one year of free updates. Over 20+ more controls are planned to be released in coming weeks.

You can view an online demonstration of these controls by clicking here.

Download a free demonstration project with the controls optimized for Xojo Web 2018r2 by clicking here.

The following controls are currently available:

  • Alert (MessageBox replacement)

  • Button (WebButton replacement)

  • Callout

  • Checkbox (WebCheckbox replacement)

  • DateInput

  • EditableLabel

  • Icon

  • ProgressBar (WebProgressBar replacement)

  • Slider (WebSlider replacement)

  • NumericInput

  • Spinner (WebProgressWheel replacement)

  • Switch (WebCheckbox alternative)

  • TextField (WebTextField replacement)

  • Toaster (MessageBox alternative)

Each control provides five color variations. Many include the ability to incorporate one or more icons. 451 high quality SVG icons are included in the package which can be scaled to any size. Some controls can be used in large or small modes to optimize your user interface design.

The control set is powered by a handful of external CSS and Javascript files which are delivered to your client browsers via a FREE CDN network. CDN access is free for the life of your license. All controls have been compiled down to a single Javascript library to maximize speed and efficiency of delivery to your clients browsers. These controls load extremely fast and provide easy events similar to the controls you are used too. They use a Virtual DOM technology which minimizes Javascript execution time and minimizes back and forth data with your Xojo Web server.

License keys are delivered within 24 hours of payment.

All sales during 2018 will include free updates through the end 2019!

You can purchase a license for Really Nice Controls for Xojo Web by clicking here.

Screenshots of the various controls are available by clicking here.

For support, licensing questions, control requests, or otherwise please email phillip@1701software.com.

My Xojo Wish List for 2018

A new year and another XDC coming up which gives us opportunity to reflect on where we are and where we are going with Xojo. If you are like me Xojo is your favorite programming tool to use and I rely on it daily to build great experiences for customers. However, that is not to say that it is not without fault or room for improvement.

I wanted to take some time to discuss my top wishes for 2018 from Xojo, Inc:

#1 “New” Framework Progress

First and foremost, I want to see the inevitable conclusion of the “New” framework on all operating systems and targets. I want to see a plan for enhanced language features and classes and capabilities that Xojo will offer us. I want to see all UI widgets and controls support the new native types introduced with Apple iOS in 2014!

Since that time, we have seen very little improvements to either the new framework, the iOS platform, or otherwise. In November of last year, I asserted that the “New” framework was a dud. There had been no meaningful improvement or announcements about potential improvements in recent history. The post created a bit of controversy but alas my call for someone at Xojo to step up and be the “language czar” and talk about all the cool things Xojo will enable in the future has gone unanswered.

If Xojo is to compete in the future as a rapid application development platform and language then it is vital they learn from their competition. An example of such is concurrency which I have highlighted in the past.

#2 Console Helper Apps

Xojo threads are a misnomer and do not help you in any meaningful way speed up the performance of your application or operate concurrently in the background. They were at best an abstraction model for separating sophisticated methods from the user interface. However, since the change of no longer allowing threads to access the user interface, you end up having to use timers which are more work to setup and more difficult to manage.

Never mind that in Xojo your application is only able to utilize a single core at a time so now the tricky mess of thread and timer management is hardly worth the effort. For anything sophisticated that you may want to do without locking up the user interface you are advised to build console helper applications. The idea is that the operating system will distribute your workload across all the available CPU cores as needed and saving you the mental effort of true threading model.

Unfortunately, building console helper apps is much more difficult than it needs to be. I first wrote about the need for the IDE to abstract away a huge portion of this effort in the first part of my 2017 review series in March of last year. I have not received any feedback from Xojo or heard anything in this area to facilitate this need. It is getting harder to sell Xojo as a rapid application development tool when your projects become significantly more complex when the IDE could so clearly help you. I hope to see some announcements in this area at XDC.

#3 Interops

I believe Interops were first announced at XDC 2016 and slated for a 2017 Q4 release. I understand that last year had some priority adjustments and so I am not unhappy with the timeliness on this one. However, as declares are essentially critical to producing any meaningful iOS results I am very keen to get more information about this feature. There is a session on it at XDC 2018 so I am very excited to see what they have cooking.

#4 Android

It would not be a complete list unless it mentioned Android as it rounds out the platform and makes Xojo consultants more marketable. I will however caveat that with saying if it is released in such a minimal manner as iOS and maintained as poorly then it will simply be marketing fluff. Xojo really needs to commit to mobile and bring their best creative minds to the table to innovate in this area.

Tools like Creo from CreoLabs demonstrate a whole new paradigm of thinking about this problem and Xojo stands to learn a thing or two from similar products. There are countless developers who do not want to deal with Java, Objective-C or Swift and there is a real opportunity here for Xojo to succeed. Combined with a fully functional new framework that is actually cross-target and usable across all user interfaces without numerous data type conversions; Xojo would nearly double my productivity.

Conclusion

I could write an exhaustive list of things I want to see improved upon in Xojo in 2018 but each year brings us only a handful of new capabilities so one must be realistic. In 2017 Xojo kept up an aggressive pace of bug fixes and quality of life improvements in the IDE and standard libraries (old and new).

The much-rumored Windows flicker problem should be resolved or greatly improved soon and that will be a substantial release in its own right. We must also take the time to appreciate the first ever 64-bit release of the IDE and the realization that Xojo has come full circle as a modern software development platform. This should also give us pause however that the fundamental technical hurdles have been overcome and we are staring at the platform as it will be for the near future.

More optimizations will be found and talks of possible IDE tweaks or improvements were discussed at the last XDC demonstrating continued improvement. That aside the 64-bit future is here, the mobile platforms are realized or past conceptual stage, we can build for all three major platforms and operate on the Raspberry Pi. It is time for Xojo to double down on the rapid application development platform that it promises to be.

Lastly, I would be remiss if I did not mention my greatest wish at Xojo, Inc: The opening of the beta tester program and more transparency into the development lifecycle of the product.

The need for absolute secrecy hurts the product in my opinion. The desire to not have to apologize when milestones are not met is purely selfish and does not take into consideration the ideas and passions of the larger community. I am also disappointed when thoughtful ideas and tough love criticisms can so easily be discarded, or discussion topics censored and deleted for fear of acknowledging that the product is not perfect.

Most acknowledge that no software development environment can ever be perfect. I resent the desire that some have to refrain from mentioning areas where it is not meeting its maximum potential. I feel dishonest if I do not share with customers the pitfalls of using it and I am delighted when I can say “Xojo is a perfect fit for this.” I look forward to being able to say that more often in the future.

Best wishes to you all in 2018.