API Development

8 Tips to Speed Up Titanium App Development – Now and in the Future

| Rene Pot |

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

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

<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 are 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 them up & standardising them. Don’t be afraid of using one of these! Which one you choose is up to you, they both have their pros and cons.

Check out:

4. Hide 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. Style 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. Unify 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. Unify 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 following #6, I go to app.tss and can apply the font right there:

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

 

Now, when the font needs to change to something else, then you can actually just change it in the config, and it works right out of the box everywhere you’ve used it.

8. Unify colors

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

  • Good examples: genericLabelColor, windowBackgroundColor or windowBarColor
  • Bad examples: white or yellowLabelColor

Also bad, re-using the configured color for other elements. Let’s 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 are:

  1. Prevent doing double work
  2. 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.

Code strong!