All Products
Search
Document Center

Android FAQ

Last Updated: Feb 20, 2021

What is the difference between handleEvent and interceptEvent when I use a custom JSAPI operation?

Answer: If you are listening to events handled by the container, you must add the custom JSAPI operation to handleEvent and enable the operation to return true. If the operation returns true, the event stops being transferred. If the operation returns false, the event continues to be transferred to other plug-ins. If you are listening to other events of the container, you must add the custom JSAPI operation to interceptEvent.

When I customize a JSAPI operation, I have added the event parameter to config.setEvents("event");. Why do I have to add the event parameter to the onPrepare operation of the plug-in?

Answer: The container plug-in is lazily loaded, that is, loaded during page creation. The external config.setEvents operation is called to inject the name of the event that you want to listen to. The plug-in object is instantiated only when a JavaScript call occurs. The instantiated plug-in distributes events in the onPrepare operation in the plug-in. Therefore, you must make sure that the event in config.setEvents("event") is consistent with the event in onPrepare.

What is the difference between the page, session, and service that are specified during registration of a custom JSAPI plug-in?

Answer: A page corresponds to a WebView. A session corresponds to an app object of an mPaaS app. A service is a global singleton.

  • If the custom JSAPI plug-in is registered at the page level, a plug-in instance is created every time a WebView is created, and the onRelease operation of the plug-in is called back when a WebView is destroyed.
  • If the custom JSAPI plug-in is registered at the session level, a plug-in is created every time an app object is created.
  • If the custom JSAPI plug-in is registered at the service level, the plug-in is globally created only once when the container is opened for the first time.

Is signature verification to verify the source or integrity of an offline package?

Answer: On the offline package publishing platform, if you configure a signed private key for the offline package, the .amr file delivered by the platform contains the signature information of the offline package. This information is the ciphertext obtained by encrypting the hash value of the offline package by using the private key. During signature verification, the public key that is preset in the project is used. In detail, a hash value is obtained by decrypting the ciphertext obtained in the previous step. The hash value of the offline package is locally calculated. Then, the two hash values are compared to check whether they are the same.
This process ensures that the content of the offline package is integral and the source of the offline package is valid.

Why am I unable to hide the progress bar for offline packages?

Answer: This problem may be caused by the failure in switching the resource to the offline mode. The failure causes the page to fall back to the online mode. In the fallback mode, the HTML5 container force restrict the progress bar. As a result, you cannot set the startup parameter SHOW_PROGRESS to hide the progress bar that shows the page loading progress.