Enchanced Network Module

UPDATE: 4/4/14

Progress Bar: I was not able to get the total size to be downloaded. Both the Content-Length and the HTTP HEAD Method are giving different numbers from the actual size. Also, I've removed the realtime updating of bytes as it is slowing the client down both in process and in the network

Retry Mechanism: I've down prioritize this as it is very much the same with the existing setup. (It would show and error, and the users have the option to do other time, or retry doing a network operation)

Resume Download Capability: Down prioritized as it is too complicated to implement

Timeout Mechanism: I resorted to the native timeout handler of the phone. As first lack of time, and second is that we don't have an idea how poor the network there.

==================================================

We need a much more robust and centralized network module. This is to cater intermittent and slow Internet connection.

 ==================================================

#1 ABILITY: Progress Bar

Use Case: First, it would get the total bytes, and would show an alert something like: "Estimating time remaining..." The method of getting the total bytes is through the HTTP Method called HEAD. The getting of total bytes is optional depending on the scenario as this would produce another network request. Then, it would show a progress bar / alert showing:

(1) Total Bytes needed to be read
(2) Current Bytes read
(3) Percentage of read
(4) Estimated time to be finished
(5) A Bar

If the total bytes is not read, then it would show an infinite progress bar. It also have the ability to "Cancel" the on-going network transaction. This is for the users to know if the J2ME Client is actually doing something (rather than saying that the client "hanged"). Also to know that their network performance if it actually downloading, or it is just slow, or it just stopped completely, or when the download should be finished.

Technical Implementation: The Progress Bar would be a Alert in a Gauge in a separate thread, where it would have a reference with the actual network module to be updated or controlled.

 ==================================================

#2 ABILITY: Timeout Counter
Use Case: Maybe the reason of "Please wait..." is that the network is that really slow or stalled. We need to have a timeout mechanism so the "Please wait..." wouldn't go on forever. After around 5 mins, the request would time-out and show to the users an error message something like, "Request Timed-Out" or "The server didn't respond in a timely manner."
Technical Implementation: There would be a "network transaction" thread and a "timer thread". Where after the timer thread has elapsed, it would forcefully close the network thread.

 ==================================================

#3 ABILITY: Retry Mechanism

Use Case: In areas where Internet is very intermittent, it is better to have a retry mechanism. This is when making a network transaction and the Internet connection was cut, it would show a Alert asking to retry downloading or stop the transaction.

Technical Implementation: It would be a simple try-catch on network exceptions.

==================================================

#4 ABILITY: Resume Download Capability (Down Prioritize)

Use Case: When downloading a very large images, and/or the Internet is very intermittent, it is good for the client to resume download from the last point it failed. This would save some time from re-downloading the whole image again.
Technical Implementation: I've set this to HARD, as I don't know yet how to implement it. But I've seen articles how to do the resume download mechanism. I don't know yet if this could be applied on J2ME.