Absent any general announcement, we posted 2.0.0 about one week ago. On revolutionary re-designs, we like to have just a few users testing at first -- so, if there are any major bugs, they can be discovered before tons of people are affected. During the week since, we have indeed discovered and corrected a few bugs, which is why we are now up to Ver. 2.0.7.
One bug in particular was nasty (resulted in PartsPick-usage data not going correctly back into SD). It is corrected with this particular release (curiously, no one seemed to have noticed this bug until just yesterday). Other bugs have been comparatively minor.
So, what's so revolutionary about our 2.0.x series?
In a nutshell, we expect it to fully eliminate "in-operation" UI (user-interface) freezes (some folks have called this "hour-glassing"). You'll notice, the UI itself (and interaction with it) is virtually unchanged. What's been radically re-done is behind-the-scenes information-management and communication-movement. In short, we adopted an entirely new strategy for these processes. Our express purpose was to eliminate those freezes that would formerly sometimes plague you.
Why did you formerly get freezes?
To keep information flowing both ways, SDM must somewhat frequently communicate with the online server. When it makes a communication request to Windows, Windows immediately goes to work, seeking to fulfill that request. In the meantime, Windows keeps the application itself in limbo (i.e., while its working to fulfill the request). This in-limbo state (pending Windows fulfillment of a communication request) is what was occurring each time you encountered freezes. Over time, we tried a variety of methods -- seeking to eliminate (or at least reduce) this symptom. None were fully successful.
Our new architecture avoids the problem by "off-loading" the communication task from SDM itself to a little companion/servant app (it's called SDM-DataMover). That little app runs in the background, without you even being aware of it. The genius is, if there is any delay when it requests communication from Windows, it's only it that freezes, and not your SDM interface. Since it's not even visible to you, there's virtually no reason for you to even care.
A secondary (and huge) benefit to this new structure stems from how communication occurs between the unseen companion app and SDM itself. It's simply done via files, stored on your local hard drive. When SDM-DataMover has new data for SDM, it writes to these files (from which SDM then reads), and vice versa.
Since we're now storing all this operating data directly on hard-drive-based files (formerly much was being done via a more intimate connection between SDM and the online data source), it makes possible a new capability that formerly did not exist. Specifically, once you've done your initial login for the day (and corresponding initial download of dispatch data), you can close and re-start SDM with no internet connection whatsoever. Your jobs will be there, just as you left them, and you can proceed with your work, sans any internet connection at all.
Another benefit is these subsequent starts are all-but instant. No delays. SDM just starts, with all your data right there.
You might notice that, several paragraphs back, we placed quotes around the expression "in-operation" to describe the context in which UI freezes are expected to be entirely eliminated. We used those quotes to call attention to a distinction. We are referring specifically to the "in-operation" background operations that used to formerly cause unexpected freezes. All of those kinds of processes have been fully "off-loaded" from SDM, per the above description.
By contrast, there are a few communicative operations that SDM still performs directly, and in connection with which you might still encounter communicative delays. Specifically, these are as follows:
- User-authentication, basic user-files and dispatch-download on first-login of the day;
- User-initiated stock-inquiry;
- Call-ahead requests or call-ahead status-checking (i.e., robo-call work);
- Virtual Terminal transactions;
- ServiceBench Entitlement inquiries; and
- QuickPic requests.
You'll notice, each of these are of a nature that require immediate/direct online communication, and also immediately follow an explicit user request for same. In such context, we think -- for any such delay as you might encounter in their connection -- it will seem normal and proper to the circumstance (in particular, as robustly contrasting against the "hour-glassing" which may have formerly frustrated you).