Integrating Customizations

Integrate customizations into the clean version of the project generated with the new API. This example suggests a migration approach; adapt this method to your unique customizations.

Prerequisites

Verify there are three copies of the application (the directory names for your application may vary):

Original customized version in \myCustomizedApplication
Legacy API version in \Generated Hybrid App\project_name_OLD
New API version in \Generated Hybrid App\project_name

Task

Compare the original, customized application with the legacy API version of the application just generated, and compile a list of areas on which to focus the migration effort.
A typical scenario includes many changes in the standard customization file, Custom.js, new CSS files, some new JS files, and some customizations in API.JS and Timezone.js.
Copy the CSS files and new JS files from the original directory into the new API directory, and edit the HTML file or JS module loaders for the file references. Use the same procedure you used for your original additions.
Use a directory-wide comparison program to compare all the files in the original and legacy directories. This means comparing the two directories:
- Original, customized version in:
```
\myCustomizedApplication
```
- Clean legacy API version in:
```
\Generated Hybrid App\project_name_OLD
```
Differences should include only:
- The Sybase Unwired Platform bug fixes between your last version and the current version of Sybase Unwired Platform.
- The code changes originating from your own modifications to the legacy API.
  
  As described above, differences are most likely to be in Custom.js, with some changes in API.js and Timezone.js. There will be other differences throughout the files, some from your customizations, and some Sybase Unwired Platform evolutionary changes and Service Pack bug fixes.
Open another session of the directory-wide comparison program, ideally a version that allows both comparison and merging. Open your original version, and the new but still clean API version to compare the two directories:
- Original, customized version in:
```
\myCustomizedApplication
```
- New API version in:
```
\Generated Hybrid App\project_name
```
You might see many differences, however the important ones are the same as those identified in the legacy API comparison (step 3).
Make the appropriate changes in Custom.js, and merge the changes function by function.
The order and most of the function signatures have been retained in the new API, which should simplify this process. Keep in mind that:
- The new API functions are in the "hwc" namespace. This affects any code that uses the API functions; any such code must use the "hwc." namespace identifier.
- All other changes, such as the Workflow to HybridApp name change, must also be addressed.
In the Timezone.js file, make the appropriate changes, including any evolutionary changes, and your customizations. Keep in mind that a Service Pack fix might have corrected a bug that you fixed using a different approach.
Make any appropriate changes in the API.js file.
Any customizations you have made to this file will be challenging, due to both the size of the file, and to separating the "container communication" aspect into hwc-comms.js. The new API keeps functions in the same general order, which should make migrating from an older code line more efficient.
Address any other differences in your legacy API comparison, and migrate them into the new API version.
Launch the application in an environment you can monitor, such as FireFox or Chrome (or even the Android Emulator); test the application and fix any errors.
Set the logging level all the way up, and continue the process of finding any missed "‘hwc"’ references and any other missed items. During this process, examine the server logs for enter/exit function notifications, to help find errors.
Once the application is migrated to the new API, it should:
- Run faster, due to caching device data like in PlatformIdentification.js.
- Be smaller and more efficient, due to better minification and runtime engine optimizations from the localization and compartmentalization.
- Use fewer global variables and functions, and use a cleaner global namespace.
- More easily integrate with third-party packages, because of the cleaner global namespace.
- Be easier to maintain and extend, due to separation of the container API and the application level API functions.