Add Search Ability to List GUI in J2ME

Our J2ME client presents a list of names and phone numbers (2 lines per entry, name on top) with the ability to select one or more using check boxes and select/unselect action (and a "select all" menu). Because some users have many, many entries in the list we need to add a search or filter option to help them quickly access the later elements in the list without having to hit down-down-down over and over. We will add a text box to the top of the screen. Any key clicks on number keys will type text into that box (using standard multi-click typing). Whenever the contents of that box change, the list will either filter out entries whose names do not start with the text in the box, or it will jump the selection to the first entry following the text in alphabetical order. The text box must support text entry in the phone's language, not just English. We can point to source code examples on the web, but none solve all the issues (like handling the non-English characters) and require integration even then. ## Deliverables Our program has implemented a custom list control to provide selection of multiple entries, each of which contains two pieces of text (a name, and a phone number). We need an implementation of this dialog that includes the ability to search/filter the list so users can more easily find entries in a large list. Requirements: * Ability to make multiple selections (checkboxes) and select all. Checked and Unchecked checkbox images are included for use in implementing the selection feature; we paint the appropriate checked or unchecked image next to each entry in the list based on its current selection status. See the attached suggested screenshot for a proposed appearance. * The list must be scrollable with the up and down keys. The list wraps around, so that hitting down at the bottom of the list returns to the top, and vice versa. * Keypresses enter text in a “search field?? and the current text in that field is set to do one of two things: A) jump the current selection in the list to the next entry after the text-value in alphabetical order, the number of items displayed doesn’t change --- Example: User enters word 'Doe' and top entry in the list is now 'Doe, Jane', next entry in list is 'Doe, John', etc. The user is able to scroll up and down the list as normal. The search essentially simulates the user's pressing downward from the top of the list all the way to the name 'Doe, Jane'. B) filter the selection list to contain only entries that start with the text-value, the number of items displayed changes, and the selection always moves to the first displayed item whenever a previously selected item is no longer available. ---- Example: User enters word 'Doe'and top entry in the list is now 'Doe, Jane', next entry in list is 'Doe, John' and all other entries starting with the word 'Doe'. The user is only able to scroll up and down the list of names beginning with the word 'Doe'; all other entries do not appear to the user * For handsets with only numeric keys, we must support multi-click text entry: --- Only need to repaint after the finalization interval has elapsed and a letter is considered finished --- Must support the current character set needed for the active language on the phone (not just English by default) --- Must support the standard key mapping algorithm for that language Example: User in English mode presses the '5' button on a standard Nokia handset, the letter 'j' should appear in the search box. If the user presses '5' again within FINALIZATION_INTERVAL (example: 1.5 seconds), the letter 'k' should appear. If the user now waits FINALIZATION_INTERVAL or presses a digit other than '5' (for instance, '8'), then the letter 'k' should remain in the text box and the cursor should shift to the next space. If a digit other than '5' had been pressed (for instance, '8'), then the first letter of that digit (for instance, 't') should now appear in the new space. If the user is in Arabic mode in their phone, letters appropriate to the Arabic language should show up accordingly. The language to use should be an input parameter to the Feature’s class, and should be tested against both English and other languages (Arabic, Chinese or some other very non-English language, with corresponding entries in the list. * After every letter is entered (or deleted), the selection or filtering is redisplayed based on the new selection text * Search text input must not disrupt use of menus or up/down navigation * Filtering is performed by comparing the selection text against the name field of the items, not the phone field. * Implementation should seek to minimize impact on jar size where possible. * The list’s class provides an interface including the following functionality: public interface OurFilteredList { /** * * @param itemsInList String array of Items to * initialize this list; each item in the array should * appear in the list as a separate entry composed of * the two strings inside the item (name, phone) */ public void setListContents(Item[] itemsInList); /** * * @return Item array of items in the List which are * currently marked/selected. */ public Item[] getMarkedItems(); } ------------------------------------------ Sample Source Code to Consult: LocalSearch: [login to view URL] Polish: [login to view URL] or [login to view URL] > Download > Proceed without Login > I accept the above rules ; source code of interest: FilteredList, TextField; [login to view URL] ; [login to view URL] LWUIT: [login to view URL] , [login to view URL] , source download: --Check out source code with a Subversion client using the following command. Note: replace the last username with your own username. --svn checkout [login to view URL] lwuit --username username --username and password should be username and password for [login to view URL] . NOTE: In examining these source codes, a major challenge we see is that none of them include logic or key mappings to support translating key clicks to non-English characters -- they assume English and a few European characters. Included in the attached zip file: * Images (png) of checkboxes for use in implementing selection. * Screen shot of suggested look-and-feel (guidance, some changes can be accepted after review and approval). Phases of Work: 1 -- If the expected implementation will differ from the attached proposal, send a mockup or screen shot of the revised proposal to verify it still meets the project’s needs. It differs if: * it does not maintain 2 lines (one for name, one for number) * it does not include a single highlighted selection * it does not have a selection text box at the top * it is not possible to type any character in the phone’s current language in that box, and have it properly reflected in the list below * ...(and similar substantial differences) 2 -- Sample binary of completed work for confirming the solution meets the requirements *** Must support SonyEricsson JP7 and JP8 phones *** 3 -- Full delivery of source code, as modified from the original ??" only after sample binary confirms proper implementation. * No code should be added that does not have a suitable license allowing free reuse and distribution in commercial products. * No libraries should be added that add costs or redistribution limitations, or significantly increase the size of the binary (ask if unsure). An emphasis should be placed on maintaining the smallest code footprint possible without including code for methods that are unnecessary for this task. Delivery: * First sample binary with source delivered one week into the project * Modifications delivered within 1-2 days after feedback * Final source code and binary delivered as soon as binary is approved. * Full duration should ideally be less than 1.5 weeks