Titanium

project observations

Here are some observations made during the preliminary code review.

Environment variables

Every value that is subject to change depending on the targeted environment must be
placed in the config.json file. This file contains dedicated sections to be uses per platform
and per environment.

{
"global": {},
"env:development": {},
"env:test": {},
"env:production": {},
"os:android": {},
"os:ios": {},
"os:windows": {},
"dependencies": {}
}

In the projects alloy.js file, we find the urls used by the application, meaning that once
we want to deploy to the App Store (or Google Play), developers will need to edit the source
code itself.

Alloy.Globals.urlProxy = "https://client.nordnet.dev/apiclient/api/";
Alloy.Globals.urlLogin = Alloy.Globals.urlProxy +
"login_check";

This can be very error-prone since there can be instances where an application is deployed
with the wrong parameters.

Internationalization strings

All internationalization string must be contained in the /app/i18n/string.xml file. There in
only one exception to this rule and it is for the applications launcher title (the title displayed
under the icon on your phones screen) which is declared in a file names app.xml.

Right now, strings are spread across both those files. While it is true that the build scripts
tend to merge those two files together, there is absolutely no guarantee this mechanism will
be the same in the future.

Mixed visual code in the UI structure

There is no clean separation of concerns between the user interface declaration and the
visual styles.


For example, in the SignIn.xml file, we have the following declaration:

...
<View id="vLoginUserName">
<ImageView class="img_username" />
<TextField id="txtUserName"
hintText="L('sign_in_hint_text_username')"
hintTextColor="#66000000"
onChange="onTextChange"/>
</View>
...

This short sample should only define the structure of the user interface (a view containing an
image view and a text field.

The wrapping view declaration has an id defined. Which is the proper way.
The image view uses a tss class name in order to apply style, again the proper way
The text field declares an id in order to access its content through code, but the
hintText and hintTextColor properties should be defined in the SignIn.tss file,
not in the xml file. There is also an onChange property, which points to the function
name to be executed when the content changes. This should be declared in the
SignIn.js file using the following syntax:

$.txtUserName.addEventListener(onChange, onTextChange);

Not using the reusable widget feature provided by Alloy

There are many instances where the application needs to reuse existing components. In the
SideMenu.xml file, we have the following declaration.

<ScrollView layout="vertical" >
<Require src="common/views/MoreItemView" id="product" />
<Require src="common/views/MoreItemView" id="account" />
<Require src="common/views/MoreItemView" id="offers" />
<Require src="common/views/MoreItemView" id="contact" />
<Require src="common/views/MoreItemView" id="info" />
<Require src="common/views/ActiveView" id="services" />
<Require src="common/views/ActiveView" id="propos" />
<Require src="common/views/ActiveView" id="disconnect" />
</ScrollView>
Which leads to the following code in the SideMenu.js file:

$.product.initial(..., function(e) {
closeMenu();
if (currentWindow !== "product") {
var newWin = Alloy.createController('Main');
newWin.getView().open();

}
});
$.account.initial(..., function(e) {
closeMenu();
if (currentWindow !== "my_account") {
var newWin = Alloy.createController('MyAccount');
newWin.getView().open();
}
});
// Same block of code for each row
...

Which makes code difficult to maintains because of its copy-paste like nature.

The Alloy framework provides a way to develop reusable widgets that addressed this
problem. The project actually uses one widget (for the Navigation Bar). The same principles
could have been applied in this case.

There doesnt seem to be any Android tablet handling

While looking through the code, we were not able to find any reference to an Android tablet
implementation. There is plenty of occurrences where iPad is mentioned, but nothing on
Android.

Also, the specific styles should rely on the formFactor attribute in the tss instead of relying
on string comparisons like in this project.

var isIpad = (OS_IOS && Ti.Platform.osname === 'ipad');

Here is a tss example where we would want to set a different color for text fields on Android
tablets:

TextField: {
color: red
}
TextField[platform=android formFactor=tablet]: {
color: black
}

Use of dp and percentages as a measuring unit in tss

There is no need to specify the dp attribute when defining dimensions since they are used by
default. Doing so is considered bad practice since calculations will require developers to
strip the dp suffix in order to modify the value.

For example, take the following declaration (taken from the VoiceMessages.tss file)

".contactCheckbox": {
height: "16dp",
width: "16dp",
left: 45%
}

Retrieving the width of this component would not return 16, but 16dp (as a string).

Also, the use of percentages should be used sparingly since there is no way to anticipate all
screen the different sizes on which the application will be used (this is especially teue on
Android). It is recommended to

Using the file system instead of App Properties

The use of the devices file system should mostly be used for caching and media files. There
are plenty in instances where the code writes a file in order to store things like properties.

Here is a sample from the SettingOutgoingCall.js file:

file.write('{"outgoing":' + JSON.stringify(outgoing) + '}');

The Titanium framework has a dedicated set of APIs to store such data in the
Titanium.App.Properties namespace. They provide better speed and reliability. Also, on
iOS, it is important to set the files variable to null in order to close the file. Not doing so
could lead to deadlocks in rare cases.

Conclusion

While there are other things that could be improved on the projects code base. These are
the ones that stood out more and (should the development continue) be addressed first
hand.