For keyboards installed via keyboard packages, use the welcome.htm if it exists for keyboard information
- Update PackageProcessorTest to include CustomHelpLink info
- Renamed Welcome.htm to welcome.htm in test_resources/**/gff_amh_7_test_json.kmp.
Due to Android's limited set of regex characters for intent actions, any local `.kmp*` file triggers the Keyman app. (e.g. `.kmp` is treated the same as `.kmpo`). Added Toast notifications for when the intent inadvertently triggers the Keyman app.
Also updated PackageActivity to display the package name when no `welcome.htm` file exists.
- Modify kmp.json to have package versions 1.4 and 1.5.
- also made exception string more descriptive when JSON object doesn't contain a valid "options" object
Intents from the DownloadManager use paths like `/document/number/` so additional code needed to determine the kmp filename.
protocols also separated in switch statement for maintainability.
- Changed PackageProcessor to skip processing keyboard ID's if JS not found
- Fix a PackageProcessorTest to use the correct package ID
- Added a dialog for when Packge install fails
-
Add intent-filter and storage permissions so Keyman app will process keyman://, http://, https:// protocols, along with local KMP file. Also add external storage permission
Update MainActivity to pass the downloaded kmp file to PackageActivity.
PackageActivity then unzips and parses the package version, and displays the Welcome page with the package version. If Welcome.htm is not in the package, just display the package ID.
Lastly, copied package processing code from KMKeyboardDownloaderActivity to PackageActivity.
TODO: cleanup KMKeyboardDownloaderActivity
Keyboard paths that get passed to KMW will depend on the `packageID`
1. Keyboards distributed ad-hoc via kmp (stored in `/packages/packageID/` won't have version strings in their filename.
2. Legacy keyboards in the `/cloud/` directory will still contain version strings
Per design discussions, use "cloud" as the package ID when it's undefined. Those keyboards get stored physically at `/cloud/`.
Later on, keyboards installed via kmp will be installed at `/packages/packageID/`
Also update version checker depending on package ID:
1. cloud: use the version string within the filename
2. all others: parse kmp.json for the keyboard version
Include language name and keyboard name when updating keyboard version. Dismiss the updateProgress dialog when keyboard has finished downloading.
Also fixed a typo in comment
For now, disable calls to `KMKeyboardDownloaderActivity.removeKEyboardDownloadEventListener()`. The parent activities will always pause when KMKeyboardDownloaderActivity runs, and we want the event handlers to trigger when the keyboards finish downloading.
Also fixed processing custom JSON to handle the JSONArray `languages`.
Currently in `KMManager`, there's 3 methods to download a `KMKeyboard` (2 in `KMKeyboardDownloader`, 1 in `KMCustomKeyboardDownloader`) for the 3 use-cases respectively:
1. Add new keyboard (from the cloud)
2. Update a keyboard
3. Install a custom keyboard
This PR refactors the following:
1. Code from `MainActivity.checkUrl()`, `KMManager.KMKeyboardDownloader()`, and `KMManager.CustomKeyboardDownloader()` into a new activity `KMKeyboardDownloadActivity`.
Code for doing actual file downloads are kept in an `AsyncTask`.
2. `FileDownloader` moved to a separate util class.
3. Confirmation dialogs for downloading keyboards are also refactored into `ConfirmDialogFragment`.
