Photo by Farzad Nazifi on Unsplash

8 Quick tips to speed up Titanium app development now and in the future

There are always things that you need to do while developing apps. Things that keep coming back, or things you don’t do often enough. This article should cover some cases, so you can spend more time on actually developing.

1. iOS & Encryption

Every build, Apple asks you wether or not you use encryption technology. Record the answer in your tiapp.xml file and you’ll never get the question again. (in this example, the answer is “no”.

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

2. NavigationWindow and cross-platform

So want to use NavigationWindow, but want to use the same code for iOS and Android? Use XP.UI

jasonkneen/UTiL

<NavigationWindow module="xp.ui">

Now, it works on Android and iOS. You can even call the openWindow method. Of course, there is no actual NavigationWindow on Android, but it wraps it in such a way you don’t have to think about it while developing.

3. HTTP calls

HTTP calls is something most apps need, but why rewrite your logic all the time? There are a couple modules/libraries out there that help you immensely with setting it up & standardising it. Don’t be afraid of using it! Which one you choose is up to you, they both have their pros and cons.

raulriera/XHR

jasonkneen/RESTe

4. Hiding ActionBar on Android

Sometimes you need to hide the ActionBar in certain pages. When you need this, just set a theme on the Window in the tss.

"Window[platform=android]": {
    theme: 'Theme.AppCompat.NoTitleBar'
}

5. Styling the Window

If you style every window the same, you might want to unify your styling. Too often I see the same style over and over again in every controller tss file. So, create a class in app.tss and apply that in every controller where it needs to be applied.

".generalWindowStyle": {
    barColor: "#333333",
    backgroundColor: "#ffffff",
    titleAttributes: {
        color: '#ffffff',
        font: "OpenSans"
    }
}

Then in every view:

<Window class="generalWindowStyle">

Why not just style using the "Window": {" logic? Well, at one point you’ll want to style a certain window differently, then you’ll either need to change every window everywhere to add a class at that point, or else you’ll be trying to override properties you don’t even need. I always add a class, so you don’t have any “magic” in your app, you always know what you’re doing.

6. Unifying further styling in the app

As with #5, you probably have labels styled the same throughout the app. Use a class in app.tss for this and apply that to the label in every controller. Keep in mind, just like with css you can apply multiple classes to a label, so don’t make them too specific, but apply naming in such a way they make sense.

Good example: #defaultLabelStyling

Bad example: #label14ptWhite

Why is the second bad? What if you change the font, which is slightly bigger, so you want to change all 14pt font sizes to 13pt? Then you’ll either have to rename the class, or have a class called 14pt while the font is actually size 13.

7. Unifying fonts

So you’re going to apply a redesign in the app, and the designer decided to make the main font something else. Now you’ve got to change all the files you’ve used the fonts and colors in. Which is, a lot of places. Even if you used tip #6, you’ll still have like 20 classes to adjust. It can easily be done, but its better to configure it right so you’ll be finished with the redesign in a second.

In the app root folder there is a config.json file you can use for this. Usually I structure it like this

{
 "global": {
  "design": {
   "fonts": {
    "regular": "Montserrat-Regular",
    "bold":"Montserrat-Bold",
    "italic":"Montserrat-Italic"
   }
  }
}

As you can see, I specify the font names right there. So now when going to, following #6, app.tss, I can apply the font right there:

".defaultLabelStyling": {
    font: {
        fontFamily: Alloy.CFG.design.fonts.regular,
        fontSize: 14
    }
}

Now, when the font needs to change to “Comic Sans” (god forbid) then you can actually just change it in the config, and it works right out of the box everywhere you’ve used it.

8. Unifying colors

For colors you could do something like this too, but it is trickier. You need to do the naming and implementation right.

Good example: genericLabelColor or windowBackgroundColor or windowBarColor.

Bad example: white or yellowLabelColor

Also bad, re-using the configured color for other elements. Lets say you have the windowBarColor and you want to have a label with the same color, don’t use the property for it! Make a new property, because you’ll hit your head against the wall if things start changing colors that you didn’t intent to change by altering the config.

Conclusion

The main takeaways from this article is prevent doing double work, and make your app maintenance faster and easier. Even if you don’t intend on changing colors or fonts later, some future developer that will take over the project after not changing for 3 years will be really happy you implemented it right.