
BAM RMC support feature completion summary as of Thu Oct 18 08:29:04 PDT 2007.
Slide references are to Robert Tartz' "BAM 2.1- RMC_UI_v3_100307.ppt".

Features are given one of the following statuses:

	NOT IMPLEMENTED
	NOT TESTED			(coded, not tested by developer)
	DONE					(coded, tested by developer)
	BROKEN				(coded, tested by developer and found incorrect)

In addition, at the end there is a list of miscellaneous issues that have
not been thoroughly investigated by the RMC team.

The files that were modified with RMC support stuff are:


	BrewAppMgr.c
	BrewAppMgr.h
	BrewAppMgrSettings.h
	BrewAppMgrUtils.c
	BrewAppMgrUtils.h
	MobileShop.c
	MobileShop.h
	res/custom1/languagespecific/en/256/brewappmgrls.brx
	res/standard/languagespecific/en/256/brewappmgrls.brx


{===============================================================================


1.	Memory card icons show app parking status in main menu, categories, and
other screens where apps are enumerated.

	Slide(s): 3, 5

	Status: NOT IMPLEMENTED

	Remarks:  Bill Sears had a partial implementation for this 

2. App on card can be placed in any category (Work, Fun, etc)

	Slide(s): 3

	Status: DONE

3. All apps downloaded to device are shown, even if on a different card
	or if no card inserted

	Slide(s): 3

	Status: DONE

4. All Settings screen options available if RMC not inserted

	Slide(s): 4

	Status: DONE

5. If RMC is supported on the device intall events are logged with the
	destination: "Installed to card" or "Installed to phone".  If device
	does not support RMC existing log entry format is used.

	Slide(s): 4

	Status: NOT IMPLEMENTED

6. Settings / Manage Apps screen shows apps on phone, on inserted card, and
	on other card.

	Slide(s): 5

	Status: DONE

7. In Settings / Manage Apps, display status of app on card if in focus,
	regardless of whether app's card is inserted or not

	Slide(s): 5

	Status: BROKEN

	Remarks:  App data in the status pane is incorrect

8. In Settings / Manage Apps, apps on other cards are selectable and will
	display Options list

	Slide(s): 5

	Status: DONE

9. In Settings / Manage Apps, apps on other cards are selectable and will
	display an Options screen

	Slide(s): 5

	Status: DONE

10. In Settings / Manage Apps, phone and card memory displayed if System
	Info is in focus  (Card memory not shown if no card inserted). 

	Slide(s): 5

	Status: DONE

11. In Settings / Manage Apps, full phone and card memory screen displayed
	if System Info is selected  (Card memory not shown if no card inserted). 

	Slide(s): 5

	Status: DONE

12. Graphical elements indicating card insertion status should change
	dynamically (as appropriate) when card is inserted or removed.

	Slide(s): 3, 4, 5, others

	Status: NOT IMPLEMENTED

	Remarks:  Need to register for appropriate device notifier events and
	redraw current state in response.

13.  Settings / Manage Apps / Options screen will always offer either "Move
	to Card" or "Move to Phone" as appropriate except Move to Card will
	not display if app is preconfigured to stay on the phone.

	Slide(s): 6, 7, 8

	Status: BROKEN, NOT TESTED

	Remarks: Whether Move to Card is not offered for a preconfigured app
	is not tested.	"Move to Phone" is (incorrectly) not shown if the
	app is disabled.  It should be shown - the code for the resulting
	notification dialog is in place.

14.  Locked app cannot be parked or unparked - attempt triggers dialog

	Slide(s): 6, 7

	Status: BROKEN

	Remarks:  Implemented for park only, not for unpark.

15.  Parked apps can be removed, even if card holding the app isn't inserted

	Slide(s): 6

	Status: DONE

16.  "View Properties" screen should show app Location: Phone or Card

	Slide(s): 6

	Status: DONE

17. Attempt to unpark or unpark app when destination space is not sufficient
	fails with dialog

	Slide(s): 7, 8

	Status: BROKEN

	Remarks: Resulting dialog flashes to screen but is immediately
	overwritten by redraw of app options screen.  Also it's clear that
	the option list menu is not released prior to drawing of certain
	dialogs - it's possible to force the menu to redraw on top of the
	dialog by using the up/down arrows.

18.  Parked apps can be upgraded IFF card with app is inserted.  No special
	UI vs upgrading an unparked app.

	Slide(s): 6, 9, 10

	Status: DONE

19.  Before launching parked app BAM verifies that card with app is inserted
	and sufficient space to temporarily unpark the app is available.

	Slide(s): 12

	Status: DONE

20.  If app launched from card creates too much data to allow reparking the
	app or card is removed while app is running, app is moved to phone
	and a dialog is displayed.

	Slide(s): 13

	Status: NOT IMPLEMENTED

	Remarks: No idea how this can be accomplished because the unparking
	and reparking of launched apps is done inside BREW.

21. If no card is inserted BAM presents the existing download screens,
	including all error scenarios

	Slide(s): 14, 15

	Status: DONE

22.  After attempted download to card, if app is not card-enabled user
	is notified that app was downloaded to phone.

	Slide(s): 14

	Status: NOT IMPLEMENTED

23.  Apps can be downloaded to card even if other apps are executing
	in the background.

	Slide(s): 14

	Status: NOT TESTED

	Remarks:  Doubtful that BAM plays any role in this.

24.  Download to phone with RMC inserted

	Slide(s): 14, 15

	Status: DONE

25:  Download to card, including all anticipated failure scenarios

	Slide(s): 14, 16, 17

	Status: DONE, I think.

	Remarks:  There are a lot of scenarios - hope I didn't miss one

26.  Apps on the card are never disabled and restoring apps only applies to
	apps on the phone.

	Slide(s): 18

	Status: NOT IMPLEMENTED

	Remarks:  MobileShop relies on IDownload to create an auto-disable list
	and to do the auto-disable.  It's not clear what role BAM/MobileShop has
	in preventing IDownload from disabling parked apps.  Disabled apps can't
	be parked (slide 8), so in theory BAM shouldn't have to check parking
	status at enable time - but it might be a good idea anyway.

27.  Miscellaneous issues.

	All discussion to date has assumed that BAM/MobileShop will be insulated
	from the notion of "reserve memory" by the AppParker API.

	Park/unpark operations interrupted by an incoming call or SMS should
	abort, perhaps leaving dangling files.  User will have to restart the
	operation.

	RMC issues in an auto-upgrade scenario are not understood (by me anyway).

	In general BAM/MobileShop does not respond intelligently to situations
	in which an RMC is removed during an ongoing RMC operation after
	BAM has checked for the presence of a card.  Exactly how BAM should
	respond is not well defined for all possible scenarios.

	Similarly, if the End key is pressed or the battery dies mid-operation
	BAM/MobileShop may not do the right thing - needs further definition.

	Certain scenarios (like removing a card) could result in 'dangling'
	files left on the phone or card.  A coherent strategy for cleaning
	them up has not been settled on.  Don't know if BAM has a role.

	In some use cases the UI spec specifies using the existing screens,
	but the "existing" screens don't exactly match what's in the spec.
	Robert Tartz has been made aware of this.

	In a download-to-card scenario the mod size availabe from IDownload
	will not match the size of the parked (encrypted) mod, which will
	generally be a bit larger.  Therefore the pre-download check for
	adequate card space can fail.  The latest idea for coping with this
	was simply to put up a notification dialog if the park operation
	failed so the user knows the app is on the phone.  No such dialog
	is implemented.  There was also some investigation into having
	AppParker calculate the exact parked size before download, but no
	way to accomplish that was found.

	In the case of a free or demo app the "confirm purchase" dialog is
	intentionally bypassed.  The confirm purchase dialog is where the
	user chooses download destination (if a card is inserted), so free
	and demo apps always go to the phone.  Robert Tartz is aware of this.

	In a download-to-card the app gets parked when the download finishes.
	If the user opts to run the app directly from MobileShop the app will
	then be unparked and reparked after the app exits.  Robert Tartz has
	asked if the redundant park/unpark/repark sequence could be reduced
	to a single park after the app runs.  No mechanism to accomplish
	this has been identified yet.

