After reading the Worklight foundation documentation on Flexible application Development. (Worklight foundation v6.2.0 Documentation)
I came across this section :
Seamlessly mix web and native components in your application
In IBM® Worklight® Foundation V6.2.0, it is easier to mix web and native components in your application, allowing you to build a hybrid application with any composition of web and native capabilities. The following enhancements support this greater flexibility in hybrid app development.
The architecture of hybrid applications (iOS and Android) now allows you to easily use native code when the application starts. You can add code at the beginning of the application lifecycle, before the Worklight framework is initialized, and have full control over when to initialize the Worklight framework, including being able to initialize it in the background. This flexibility allows you, for example, to add a custom splash screen or to control the default splash screen behavior, and to start an application with a native screen.
Moreover, you can now navigate seamlessly between the native and web parts of your application without having to re-authenticate, and Invoke both native and JavaScript WLClient APIs in any order. For example, the following scenarios are now possible:
- Start the application in a web view page, connect to the Worklight server, and then login to access protected resources. You can then switch to a native view and access the same protected resources without the need to reauthenticate.
- Start the application in a native page, connect to the Worklight server, and then login to access protected resources. You can then switch to a web view and access the same protected resources without the need to reauthenticate
- A new API has been introduced that allows you to easily send actions (events) and data between the native and web modules of your app. This makes it easier to build applications that mix hybrid and web components, for example:
- You have an application with a JavaScript communication module and a native presentation layer. You can use the new API to easily send the data acquired by the communication module to the native layer, so that you can present it to the user in a native screen.
- You can easily trigger complex native actions using JavaScript, without implementing a Cordova plugin. You can also call JavaScript code from native code.
- You can easily show native and web components on the same screen, using this API for communication.
The navigation back and forth between native and web components does not require any additional programming efforts and can provide greater application flexibility. For example, the following scenarios are now possible:
- Start the application in a web view page, connect to the Worklight server, and then login to access protected resources. You can then switch to a native view and access the same protected resources without the need to reauthenticate.
- Start the application in a native page, connect to the Worklight server, and then login to access protected resources. You can then switch to a web view and access the same protected resources without the need to reauthenticate.
Mentioned several times in the examples are cases where your worklight application would start with a Native page. But what would be an advantage(s) when starting an application with a Native page rather than just starting with a web view page?
