Image Reports

INTRODUCTION
Image reports on Java Phones is one of the most requested feature. This is where the users could: view, download, and share image reports for the colleagues. Unfortunately Java Phones have: Small Memory Footprint, and Intermittent Internet Connection. That's why this is not an easy task. I have divided this blueprints to "FEATURES." Each of them has it's own Priority, Difficulty, and a *VERY* rough estimate. This is for the management to organize and prioritize which features are viable to be implemented. Also the estimates are done in a "Most Likely" setting (not in a "Pessimistic" and "Optimistic" setting) and also without the TDD (Test-Driven Development) applied. Also all of the estimates are NEGOTIABLE. This blueprint would be constantly be updated as knowledges/researches come.

Please note the most of the other requirements are found in a separate blueprint called "Enchanced Network Module" due to this nature of downloading images from the server.

https://blueprints.launchpad.net/dhis-mobile/+spec/network-module

Quick Definitions:
* Client - It is our J2ME Software.
* Device - It is the mobile phone.
* Customer/User - The users of the J2ME Software. The end-users particularly, not the developers.

==================================================
#1 MAIN FEATURE: Ability to download and view images
Priority: TOP PRIORITY
Difficulty: Moderate
Estimate: (Rough-Most Likely) 3-4 Days

Use Case: On the Main Menu, there would be a new list called "Chart List". Upon clicking the "Chart List", it would show all the available charts for the user. Upon selecting a specific chart, the client would go to a new form showing the image in portrait mode. If the image is too big to be loaded on the device, there should be an Error Alert, and the user would be returned to the Chart List. If the image is loaded, the users could press the Soft Keys, then press "Back" to go back to the "Chart List".

Technical Implementation: We would be importing a 3rd APi called JSON.me (https://github.com/upictec/org.json.me/) for it to communicate with the Web API. I will use JSON rather than XML, because JSON is much more lightweight on network transfer than XML. Upon selecting a specific image. The client would then download the image in a "per-byte" basis and not as a whole. The Per-Byte Basis is "InputStream.read()" while the Per-File Basis is "InputStream.read(buffer, offset, length)". We would be using the Per-Byte Basis as it is much more stable in an "Always On-Off" Internet connection. The only caveat for this is that the Per-Byte method is slower than the Per-File method, but it is compensated with its dependability. The download mechanism SHOULD be integrated with the existing network module (See Network Refactoring) to avoid duplication of code and provide a much more leaner source code. The image format to be downloaded SHOULD be in a PNG format, as this is mostly supported by J2ME Devices, and also it provides a cleaner image. For now, the image could PROBABLY be loaded on the J2ME Device as it is only around 21KB (and as most devices has 2MB of RAM or expandable types like S60 Devices).

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

#2 FEATURE: Pagination Capability
Priority: High Priority
Difficulty: Moderate
Estimate: (Rough-Most Likely) 1-2 Days

Use Case: When loading a large list of Chart List, it is better to implement pagination at the first place. On the top part of the form (usually the title bar) there would be "Chart List (1/2)" to indicate what page are we in. And when the user pressed the Soft Key, there would be options like "Next Page" and/or "Previous Page". This options would disappear (not disable, as there is no "disable menu" feature on High Level UI), if the user is on the first or the last page.

Technical Implementation: There would be an internal paging mechanism on the J2ME Client itself. Where it would record: What current page are we in? What is the last page? This could be done in a single form (just being renewed), or new forms.

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

#3 FEATURE: Ability to have a "scaled down version" of the image
Priority: Moderate-Low Priority
Difficulty: Moderate-Hard
Estimate: (Rough-Most Likely) 2-3 Days

Use Case: Some users just want to see the "overview" like the graphs and not the small details about it. Or they have a very slow Internet connection.

Technical Implementation: This is somewhat hard as it needs to do something on the Web Source Code. The default image that is fed by the server is 800x500. There is none yet (I think) settings or query-strings to request a scaled down version of an image.

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

#4 FEATURE: Zooming Capability
Priority: Moderate Priority
Difficulty: Moderate
Estimate: (Rough-Most Likely) 2-3 Days

Use Case: Just like Smartphones, we "pinch-to-zoom" to see the image better. As J2ME phones: (1) Doesn't always have touch-screens (2) And it doesn't support multi-touch. We would make it as a menu. Where on the "Scaled Down" picture, the user has an option on the menu to "Zoom". After selecting zoom, the client would then download a high resolution of the image. And show it to the users. If the image is too large, it would show an error message and go back to the "Scaled Down" image screen. On the zoomed-screen, the user has the ability to move around using the arrow keys, (or 2 (up), 8 (down), 4 (left), 6 (right)) to see the image better (like the texts parts). Much better if there would be visual cues about the keys to be pressed like Arrow Images. If the user wants to get out from the "zoomed-screen", the user would just press the Fire Key (or 5) to go back to the "Scaled Down" picture.

Technical Implementation: The "zoomed-screen" is actually an image pasted in a Canvas. Where if the user pressed an arrow key, the position of the image would just be adjusted. The speed of the movement of the image would be then calibrated by both of the developers and the users.

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

#5 FEATURE: Auto Image Orientation Feature
Priority: Low Priority
Difficulty: Moderate
Estimate: (Rough-Most Likely) 1-2 Days

Use Case: Some images could be better viewed in landscape position. Where the image would automatically orient if the phone is tilted (opened the slider).

Technical Implementation: Some phones support this dual-orientation (some doesn't). This is usually done on the JAD Configuration.

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

#6 FEATURE: Save-to-File Feature
Priority: High Priority
Difficulty: Moderate-Hard
Estimate: (Rough-Most Likely) 3-4 Days

Use Case: On the image screen, the user has the option to "Save". Upon pressing "Save". It should then show a File Browser (still made in J2ME). Where the users could navigate through the file system, and save. If there are any errors, it would be shown to the users like "Access Denied", "I/O Error", etc.

Technical Implementation: Most of the work would be done on the "File Browser". And this is somewhat hard, as different phones have different file structure. The goal is to have a "unified" way of navigating and saving to these file structures. Lots of testing/research is needed to provide a seamless usage across wide-range of phones.

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

#7 FEATURE: Send as MMS
Priority: High Priority
Difficulty: Moderate-Hard
Estimate: (Rough-Most Likely) 3-4 Days

Use Case: On the image screen, the user has the option to send as MMS. Upon pressing the option, it would go to a new form, where they would input the number of their friend. And then upon pressing send, it would send as MMS.

Technical Implementation: I've set this to hard yet, as I don't have a full grasp on MMS and what is the correct format.

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

#8 FEATURE: In-App Bluetooth Sharing Feature
Priority: Low Priority
Difficulty: Hard
Estimate: (Rough-Most Likely) 4-5 Days

Use Case: As sharing is one of the key features of DHIS, the users should be able to share those images to their colleagues. This could be done where they could send or bluetooth the images to other devices or computers. Rather than going outside the client, the users could send images via Bluetooth. On the image screen, there would be an option "Send From Current". Upon selecting "Send From Current", it would go to an interface similar to the built in app on the phone. Also if the image is already saved on the phone the user could select the "Send from File" then a "File Browser" would show to select an image to be sent.

Technical Implementation: I have no knowledge yet on Bluetooth, so researching may take time.

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

MORE TASKS:
* J2ME Source Code Familiarization (3-5d). Well, we could code like cowboys, and implement on our own ways (and yes it might work). But this would produce: (1) Lots of code duplications (2) Client slowdowns (3) Out-Of-Memory errors (4) More (and much more weirder) bugs (5) and Slower Development Time (6) And much more development horrors. That's why we need to understand the code fully to provide a lean and reliable code.

* Code Refactoring (3-5d). To avoid code duplication and to provide a leaner code: Like in the Network Module, new abilities like Downloading, Retry Mechanism, Resume Mechanism should be included in this module. Like in the Data Module, we would be soon handling larger data, and we need to have a much more robust data management.