do you have anything in place for handling mobile web-based transactions that might be left half completed if the user loses wireless or, in our case, internet connection? for example, if the user is creating a customer bill, and, halfway through, the iphone loses internet connection for say 1 minute, is there any mechanism that will temporarily hold that data so that the user may continue when the connection is retrieved?
we are currently designing a mobile app, and that's one of our concerns.
mobile profoundui apps
-
- Profound User
- Posts: 88
- Joined: Tue Jun 01, 2010 11:31 am
- First Name: christopher
- Last Name: williams
- Company Name: banks dih limited
- Phone: 592-226-9584
- Address 1: thirst park
- Address 2: ruimveldt
- City: gerogetown
- State / Province: Outside Canada/USA
- Zip / Postal Code: 0000
- Country: Guyana
- Contact:
- David
- Profound Logic Staff Member
- Posts: 690
- Joined: Fri Jan 04, 2008 12:11 pm
- First Name: David
- Last Name: Russo
- Company Name: Profound Logic Software
- Contact:
Re: mobile profoundui apps
There is nothing like that built-in, however such functionality could be coded into the application.
For example, the application could store the in-progress transaction data in permanent files (i.e. not in QTEMP). When the user enters the application, it could check to see if there are any in-progress transactions on file. If so, it could allow the user to select one and resume where it left off. The application could delete the in-progress transaction records (or maybe it just updates a status flag) when the transaction is finalized normally.
Also, since HTTP communication is stateless, connection loss does not always result in a problem. For example, if the browser is "sitting" on a screen and connection is lost, absolutely nothing will happen. The browser doesn't care at this point whether it's got a network connection or not. After the connection is re-established, the user can still submit the screen normally.
If connection is lost when the user is trying to submit, it's a different story. This is where those application-specific recovery procedures could come into play.
For example, the application could store the in-progress transaction data in permanent files (i.e. not in QTEMP). When the user enters the application, it could check to see if there are any in-progress transactions on file. If so, it could allow the user to select one and resume where it left off. The application could delete the in-progress transaction records (or maybe it just updates a status flag) when the transaction is finalized normally.
Also, since HTTP communication is stateless, connection loss does not always result in a problem. For example, if the browser is "sitting" on a screen and connection is lost, absolutely nothing will happen. The browser doesn't care at this point whether it's got a network connection or not. After the connection is re-established, the user can still submit the screen normally.
If connection is lost when the user is trying to submit, it's a different story. This is where those application-specific recovery procedures could come into play.
Who is online
Users browsing this forum: No registered users and 0 guests