Skip to content

Adapting to app development with Titanium from a web development background

20th June 2022

5-minutes read

If you have a background in web development, there are some key concepts and differences you will need to understand if you're planning to work on app development using Titanium.

But first, here's one similarity: I've worked as a web developer since 1999 so I remember writing code specifically to accommodate different browsers (it was Internet Explorer versus every other browser, at the time). It was as frustrating and time-consuming as it sounds. There's a parallel with app development because the code you create for an iOS app is fundamentally different to an Android app.

And that's where Titanium comes in, as it provides an environment in which you can create a single codebase, written in native JavaScript, and compile separate iOS and Android apps from there. But just as we had to do as early web developers, expect on occasion to have to acknowledge in your code some differences between iOS and Android.

Setup

Let's get started. Assuming that you want to develop Android and iOS apps, you're likely to need the following:

  1. A Mac

    To build an iOS app, you need an Apple computer so if you're a Windows PC person, make space on your desk for a second machine.
     
  2. Patience

    Overall, there's a fair bit to install to get your development environment setup and expect some hassle along the way. Titanium's website is your starting point and you'll get friendly with this site while you're developing as you'll refer to its API docs often.

    Also, although we're jumping ahead a bit, when you get to the point that you're ready to distribute your app, more patience is needed! The distribution process for iOS apps is intricate and you'll soon encounter terms you've previously not heard of - such as "distribution certificates" and "provisioning profiles". But don't worry: the Titanium community is vibrant and you'll often find help there.
     
  3. Alloy

    When you combine Titanium with Alloy, you (sort of) have an MVC environment which will feel familiar if you're a back-end web developer. Although you can code apps with Titanium using controller files only, don't. Alloy makes defining your presentation layer more intuitive and maintainable and it reduces the amount of code you write.

Styling

Alloy links a stylesheet (a .tss file) with its counterpart controller (your .js file) and you're going to feel at home with this straight away. While the syntax is a little different compared with CSS, you can apply styles to a component (defined in your .xml file) by referencing its ID, by assigning it a class(es) or by applying styles to all components of that type:

.xml file:

  1. <View id="myThing">
  2.   <View class="myOtherThing">
  3.     <Button>Click me!</Button>
  4.   </View>
  5. </View>

.tss file:

  1. "#myThing": {
  2.   property1: value,
  3.   property2: value,
  4. }

  5. ".myOtherThing": {
  6.   property1: value,
  7.   property2: value,
  8. }

  9. "Button": {
  10.   property1: value,
  11.   property2: value,
  12. }

But the subtleties and intracacies possible in a CSS file aren't matched in TSS. You can't use embedded selectors:

  1. //Valid CSS
  2. .someClass .someOtherClass {
  3.   property1: value;
  4. }
  5. //Invalid TSS
  6. ".someClass .someOtherClass": {
  7.   property1: value,
  8. }

And you can't use adjacent or direct descendent selectors:

  1. //Valid CSS
  2. .someClass + .someOtherClass {
  3.   property1: value;
  4. }

  5. .someClass > .someOtherClass {
  6.   property1: value;
  7. }
  8. //Invalid TSS
  9. ".someClass > .someOtherClass": {
  10.   property1: value,
  11. }

And pseudo-selectors such as :first-child, :before and :focus aren't a thing in TSS either.

You'll quickly get used to it!

One key thing here: as a web developer, you spend hours ensuring that your website looks the same across different browsers and, on occasion, you add CSS hacks to target a particular browser to get the outcome you want.

Don't think like that as an app developer.

iOS and Android apps are different. Their components look different and their users interact with apps differently. Don't force an Android app to look like its iOS counterpart or vice versa. You'll waste time striving for an outcome that, ironically, your user base won't appreciate.

Layout

When you're ready to code the presentation of your app's screen, first spend time understanding how layout works in a Titanium app.

You can assign to each <View> in Titanium one of three different layout properties: composite, horizontal or vertical. Composite is the default value unless you specify otherwise and, for a web developer, think of this as absolute positioning. Any child component of a <View> with composite layout gets positioned on the screen based on its X and Y co-ordinates. More specifically, you can specify values for top, bottom, left and right to set the exact position of your component (although you'll often find that setting top or bottom and setting left or right is sufficient as your component will automatically size itself from its given starting location).

When a <View> has horizontal layout, its child elements automatically stack from left to right across the screen, much like a containing element in HTML with child elements that have float: left set in their CSS.

And a <View> with vertical layout also stacks its children but it does so vertically down the screen.

Expect to use a combination of several different layout options within the same screen as it's often the best way to achieve the positioning that you're after while retaining the flexibility that allows your app to render well on devices with different screen sizes.

Structure

Spend time reading up on - and understanding the need for - windows, navigation windows and views. Your app maintains state and this is fundamentally different to a website. Typically, when you click a link on a website and move from page A to page B:

  1. page B has no knowledge of what happened on page A
  2. you don't need to worry about tidying up memory management on page A before you open page B
  3. all browsers open page B in the same way

With this in mind, plan the structure of your app before you start coding. Are you building a single-window app that loads different controllers / shows different views based on the user's interaction? Will a multi-window app suit you better but require you to open / close windows appropriately? Do you need a tabbed app, where each tab maintains its own stack of windows?

Coding

Get to know the <View> component intimately. Lots of other components, such as <Button>, <ListView>, <ScrollView>, <TextView> etc., extend from the <View> object, so whatever you're able to do with a <View> you'll be able to do with the other components that extend it.

Apps maintain state. When a user resumes an app on their device, they carry on from the point at which they left it. When a visitor returns to your website, its previous state is only maintained if you've coded to make that happen, which is usually as a result of providing users with an individual login.

Updates

Apps, of course, are installed locally on each user's device so you need manage the possibility that at any one time, different users could be running different versions of your app. This isn't the case with your website: if you make a change to its codebase, all users access the same, updated website from that point onwards.

Supporting different versions of the same app is most apparent as an issue if you're also maintaining the API to which your app connects. You can't make a breaking change to the API to accommodate a new requirement in version 2 of your app if you still have version 1 users accessing the same API endpoint. Adding new functionality to your app and its API while retaining support for older versions does, once again, require planning!

A background in web development is going to stand you in good stead as you build your Titanium skills. But on occasion, you'll need to challenge your existing knowledge (and certain assumptions you naturally make because of it) so that your approach to developing mobile apps produces functional, maintainable code.

Jeremy Flight

Jeremy Flight

Technical Director

Jeremy Flight

About the author

This article was written in June 2022 by Jeremy Flight, Technical Director at Rubiqa.

He has worked in the web design industry since 1999 and has helped many private businesses and public sector organisations with complex website projects. As the technical lead at Rubiqa, he is the primary contributor to our software products and is involved with projects relating to website design, eCommerce, database systems and mobile apps.

Away from work, Jeremy is a qualified cricket coach and works with junior players at his local club. He is also interested in property investment, golf, photography, playing the piano and holidaying in France.

Connect with Jeremy Flight on LinkedIn

What we do

Send your enquiry

To prevent unwanted spam, we ask you to enter the answer to this simple sum: