Autopostbacks are a great idea for ensuring information saves in real time until you get poor Internet connectivity. How, why and where should they be used?
The Internet is a blessing and a curse for programmers. Autopostbacks address an operational challenge faced by web developers.
However the reality of poor global connectivity and mobile connectivity introduces further challenges.
This article in business English introduces the challenge faced by web programmers as they try to keep up with native app developers.
- Setting the stage
- The options
- Choosing the option best for you
[read more=”Read more” less=”Read less”]
Setting the stage
Getting used to a helpful computer
Before we look at autopostbacks, let’s look at where people spend lots of time working.
Most people will have used Microsoft Word for writing documents.
Its possible to spend hours and days working in Microsoft Word.
From time to time a little feature called “autosave” kicks in.
As a computer programmer you are taught from an early stage, there are three laws of programming. Save, save, save.
This feature has saved more thesis, papers, homework and presentation documents that the world will ever know.
The power of saving as you go along in your work has significant benefits. It means that if the computer fails or you make a mistake, like closing the wrong window, all your work is not lost.
As a hint which has saved me much grief over the years, if you touch type, Ctrl and S at regular intervals as a habit will make you life livable.
So, autosave is an amazing feature which is born of a lot of frustration by users.
It’s always useful and when you work on material for a protracted period to save regularly. This means you don’t lose all your work in something that can result in rage.
Web based applications
Are autopostbacks used everywhere? No.
So with the advent of the Internet using HTML, CSS and JavaScript and a host of powerful capabilities, you can actually do most things you do in Word in a web page.
The challenge is the autosave.
Web pages weren’t designed to have an autosave of your work. Programmers set about trying to come up with work arounds, solutions that mimic autosave. They faced a difficult challenge in a different environment with different rules.
What’s so different… they’re computers?!
The difference is distance.
When you use Microsoft Word, you install it locally on your computer.
When you hit save, or autosave kicks in, the saving happens on the same pc and is nigh on instantaneous.
If it’s a big document with lots of images then even that can take a few seconds.
When you use a web based application and a save happens, the entire document travels from your computer, across the Internet, like sending an email with an attachment.
Then you need to get the email back from the Internet to confirm everything saved ok.
The time difference is enormous!
This web sending of the document in web page terms is called a “post“. You post your data to your online service. You request a web page to start with and then you post the data back to the page, a postback.
This is part of where autopostbacks get their name.
Managing posts
So given that there can be huge delays, broken connections in Internet coverage, not to mention complexity of saving while in transit, can result in a lot of broken Internet connections.
If the connection breaks while “saving”, the save fails! You lose everything up to your last successful save!
Very very unhappy users.
Whether its a post or postbacks, a break in connectivity at the wrong moment with Internet based applications can be insanely frustrating.
So this leads to the approach of “one and done”! When you hit save in your application you prepare for the worst and hope for the best.
Cross your fingers and hope hope hope that the connection doesn’t fail.
With fast Internet and high availability this isn’t an issue.
In the field however… oh boy!
Put images into the mix or videos… the data size balloons… now there is a serious risk of data loss.
So this is the end of all Internet applications! Actually it’s the opposite. Hosted, software as a service is on the rise, not decline.
How you might ask?
Because the pros outweigh the cons and programmers can get smart and help.
The solution… is save it before you send it
So before you do your “post” your device saves the information temporarily locally.
Browsers do not let this happen unfortunately. Why?
Because some very bad people find ways of abusing this ability.
Internet browsers have very limited “save” capabilities. In fact they only have one mechanism which can help called cookies.
If you’ve ever read a security notice you’ll see how nervous people are about using cookies and rightly so.
A mobile device, like a laptop in the field or just a smart phone are incredibly prone to losing data connectivity.
The act of moving between one mobile phone tower and another is mathematically and physically complex.
Suppliers develop “apps” for mobile phones to overcome connectivity challenges.
The primary role of the app is to handle the issue of “save info” before sending, so if the connection fails, it can handle that and try again later.
This is the concept of working “offline” where the connection has failed or is non existent and has to operate in a limited way until the Internet returns.
So where do autopostbacks feature?
An autopostback solution is (in my opinion) an extreme approach to the solution.
Every time you type a letter into your app it saves.
By saving after every letter typed, if connectivity fails, you’ll know instantly.
If the browser window closes, the computer blows up, not an issue, you only lose up to the last letter typed.
However, this approach working effectively is predicated on two facts:
- you have a reliable internet connection and
- an always available service.
This makes autopostbacks limited to specific operational scenarios.
The options
Turning autopostbacks off
Let’s start with some assumptions
- Firstly if your web based application only works on your company network,
- Secondly your network and service is guaranteed to always be available (high availability)
- You understand the risks of delays
Then yes, autopostbacks can make a web solution mimic a locally installed solution by saving with every letter press.
This is not the common scenario, so most solutions turn off autopostbacks as the first thing they do when they install their web server.
Though they’ve been around since 2010, back in 2013 when I was introduced to autopostbacks as part of Web Systems Development I was fascinated by this capability.
When I brought it to live production, especially with “across the Internet” challenges I realised the scope was predominantly local for the approach.
Ok, so we’re not going to use AutoPostBacks due to time issues, but we still need an autosave. What can we do?
AJAX and it’s not for cleaning up
Ajax is a cleaning product owned by Ajax Laundry & Bleach owned by U.S. Nonwovens Corp under the Colgate-Palmolive corporation.
In computing terms AJAX (Active JavaScript And XML) is a programming language and data format that works inside the browser.
Using JavaScript before you send anything over the internet the JavaScript can do a few things.
Check 1, is the server at the far end there? This first simple check means “is the Internet working before I attempted to send this”.
If we have a connection, then the JavaScript does the send, not the browser.
This is an important difference.
If the send FAILs, you have not left your webpage, you have not lost any data and the JavaScript can try again.
If it SUCCEEDS, yay it saved, on we go.
AJAX and Cookies, not tasty to eat but very useful for web programming
AJAX detects something changes on the page. It gathers up all the data on the page and saves it into a cookie.
This process is ongoing saving data locally on every click and key press.
Subsequently AJAX at intervals can send the information in the background, silently like an autosave, to the web application.
When you get to your final “save” click, the previous save process kicks in. With success the cookie wipes.
So nothing remains locally and all the web information saves.
Leaving a page
Even writing a blog such as this, there is a risk my computer turns off due to power failure. So autosaves are useful.
WordPress has an autosave engine. It goes by the name of “draft” saving engine and you have options to control it.
There is a also the risk that I go to another web page or close the browser.
JavaScript can do another smart thing and warn me about unsaved information with a simple message “are you sure you want to leave this page?”
Now this message can prevent slips, trips and accidents. However you explicitly add it to pages where the risk of accidents happen.
The solution is a JavaScript function called window.onbeforeunload and is detailed on W3Schools.
Choosing the option best for you
Autopostbacks are an option for your design if you have great connectivity and are guaranteed a connection but that isn’t for every software as a service solution.
For the rest of the solutions using JavaScript to deliver an AJAX solution will probably be the way to go.
Features such as the onbeforeunload are very handy to have in your backpocket to sense check users with simple checks if something on the page has changed.
So although by virtue of the nature of web technologies you can’t have an autosave that works like a locally installed application, you can get very close to it.
[/read]
