Cross-platform mobile apps – possible or not?

February 5, 2014

4 minute read

What is Titanium and how it works. Titanium is an open-source solution for cross-platform, almost-native mobile app development. It has its own MVC, JavaScript and XML-based framework Alloy. Titanium is based on assumption, that each app can be divided into two parts: UI, which is platform-specific part and application core – business logic, common to all […]What is Titanium and how it works. Titanium is an open-source solution for cross-platform, almost-native mobile app development. It has its own MVC, JavaScript and XML-based framework Alloy. Titanium is based on assumption, that each app can be divided into two parts: UI, which is platform-specific part and application core – business logic, common to all […]

What is Titanium and how it works.

Titanium is an open-source solution for cross-platform, almost-native mobile app development. It has its own MVC, JavaScript and XML-based framework Alloy. Titanium is based on assumption, that each app can be divided into two parts: UI, which is platform-specific part and application core – business logic, common to all platforms. So, inside the app, we have native UI components and JavaScript interpreted logic, communicating with each other.

If you want to write your app in titanium, you only need to know JavaScript and learn to call Titanium API for UI components. Alloy, on the other hand, is more fun, because you have to write views in XML, model and controllers in JavaScript (+ Titanium API mentioned before) and styles in something called Titanium StyleSheets, which is CSS+JSON hybrid. I must admit, the language is not an obstacle for anybody who ever did web development, or any kind of script and markup languages. It’s easy to start working with this framework.

Beginnings.

To work with Titanium, you will need Titanium Studio – an Eclipse-based IDE adapted to write and deploy Titanium apps into various platforms and stores – AppStore, Google Play etc. It has a direct access to Appcelerator Titanium Marketplace, where you can download e.g. sample applications, widgets and plugins – paid for or free of charge.

After downloading Titanium Studio and necessary SDK’s I downloaded sample code called Kitchen Sink – an example, showing possibilities of Titanium Alloy framework. I chose a device and… it worked! After (very few years of programming I get used to difficult beginnings, long configurations before the first launch (whether regarding a web app, mobile app or any kind of desktop/command line app), but Appcelerator did a great job preparing IDE and integrating it with simulators, emulators etc. After the first success I played with Alloy for a few days and here comes my conclusions.

What is great about Titanium.

1. Simplicity. Apps can be build from small files and can be developed very fast. Everybody knows basics of XML and JavaScript, so you can start writing your apps straight away.

2. Architecture. Alloy framework is very well designed. It allows installing plugins, widgets, or even native modules in a convenient way. “Convention over configuration” makes this process faster – all you need to do is put the downloaded widget into the “widget” directory and add a dependency into config.json file.

3. GitTio is a search engine that indexes all Titanium modules and Alloy widgets. It is something similar to Cocoa Controls for iOS, but more comprehensive, because it automatically finds new modules in GitHub and indexes them. GitTio provides Command Line Interface, which facilitates installing and managing widgets.

What is not-so-great about Titanium.

1. There is not such thing as “one app to rule them all”. Mobile platforms have different controls, components and UI elements. The same things are implemented by different solutions. The more complex the app gets, the more platform dedicated code needs to be written. After all, I end up writing views and controllers for each platform separately.

2. Even if you can write one view for each platform, you probably shouldn’t do it. There is one thing I have not mentioned yet – User Experience. It is extremely different for each mobile OS. Android users are used to “back” and “menu” buttons, iOS users are using navigation bar, some OS’s are using swipe moves to navigate between window. Therefore, a universal app for all platforms is doubtful idea to start with.

3. Cross-platform idea stops working when you want to use external module. There are “iOS-only” modules or “iOS and Android” modules. Very rarely, they may also include mobileweb.

What is totally not-great about Titanium.

1. Titanium is still young. It develops really fast. A lot of things have bugs, while at the same time, a lot of features get deprecated. When you find a tutorial from 2011, you may never be sure whether it’s up to date. Differences between close versions (like 3.1.3 and 3.2) sometimes force re-writing the whole view or using another widget.

2. Titanium and Titanium Alloy are two different worlds. Having got used to the beautiful Alloy MVC code I tried downloading a widget written in “plain Titanium”. This was a lot of code with a completely different approach and not so easy to integrate with Alloy. Then I found out, that I don’t have “631 Titanium modules” (gitt.io), but “178 Alloy Widgets”, so I had to found widget with similar functionality, written in Alloy. Another “little” bump on the road.

So what?

With some experience with Titanium and some experience with PhoneGap, I don’t think it is possible to write a good cross-platform app. It is hard even when you try to do this for iOS and Android only, but we have also Bada, Tizen, Firefox OS and new OS’s are developed as we speak – Ubuntu Touch, Sailfish OS and some more. Also, it is always good to have mobile web version of the app. But, even if a cross-platform app would be possible to write…

You shouldn’t do this. When you write a native app, you can learn user habits and good practises for each platform. When you write one app for every platform, you probably break about a million good-UX rules. But, if you are desperate and want to do this anyway…

It won’t save you a lot of time. When you write cross-platform apps, you have to deal with OS-specific quirks, you sometimes get native-code errors (good luck with Objective-C errors without any iOS knowledge) and it is not too difficult to miss some crucial things (while testing on 9 devices at the time).

Of course, in some cases, cross-platform apps can be a good solution. Nevertheless, in my opinion, it is not the universal solution for mobile app development.

DDevelopment & Design

33rd Degree day 1 review

byJakub Nabrdalik
March 24, 2012

33rd Degree is over. After the one last year, my expectations were very high, but Grzegorz Duda once again proved he's more than able to deliver. With up to five tracks (most of the time: four presentations + one workshop), and ~650 attendees, there was a lot to see and a lot to do, thus everyone will probably have a little bit different story to tell. Here is mine.

Twitter: From Ruby on Rails to the JVM

Raffi Krikorian talking about Twitter and JVM

The conference started with Raffi Krikorian from Twitter, talking about their use for JVM. Twitter was build with Ruby but with their performance management a lot of the backend was moved to Scala, Java and Closure. Raffi noted, that for Ruby programmers Scala was easier to grasp than Java, more natural, which is quite interesting considering how many PHP guys move to Ruby these days because of the same reasons. Perhaps the path of learning Jacek Laskowski once described (Java -> Groovy -> Scala/Closure) may be on par with PHP -> Ruby -> Scala. It definitely feels like Scala is the holy grail of languages these days.

Raffi also noted, that while JVM delivered speed and a concurrency model to Twitter stack, it wasn't enough, and they've build/customized their own Garbage Collector. My guess is that Scala/Closure could also be used because of a nice concurrency solutions (STM, immutables and so on).

Raffi pointed out, that with the scale of Twitter, you easily get 3 million hits per second, and that means you probably have 3 edge cases every second. I'd love to learn listen to lessons they've learned from this.

Complexity of Complexity

The second keynote of the first day, was Ken Sipe talking about complexity. He made a good point that there is a difference between complex and complicated, and that we often recognize things as complex only because we are less familiar with them. This goes more interesting the moment you realize that the shift in last 20 years of computer languages, from the "Less is more" paradigm (think Java, ASM) to "More is better" (Groovy/Scala/Closure), where you have more complex language, with more powerful and less verbose syntax, that is actually not more complicated, it just looks less familiar.

So while 10 years ago, I really liked Java as a general purpose language for it's small set of rules that could get you everywhere, it turned out that to do most of the real world stuff, a lot of code had to be written. The situation got better thanks to libraries/frameworks and so on, but it's just patching. New languages have a lot of stuff build into, which makes their set of rules and syntax much more complex, but once you get familiar, the real world usage is simple, faster, better, with less traps laying around, waiting for you to fall.

Ken also pointed out, that while Entity Service Bus looks really simple on diagrams, it's usually very difficult and complicated to use from the perspective of the programmer. And that's probably why it gets chosen so often - the guys selling/buying it, look no deeper than on the diagram.

Pointy haired bosses and pragmatic programmers: Facts and Fallacies of Software Development

Dima got lucky. Or maybe not.

Venkat Subramaniam is the kind of a speaker that talk about very simple things in a way, which makes everyone either laugh or reflect. Yes, he is a showman, but hey, that's actually good, because even if you know the subject quite well, his talks are still very entertaining.

This talk was very generic (here's my thesis: the longer the title, the more generic the talk will be), interesting and fun, but at the end I'm unable to see anything new I'd have learned, apart from the distinction between Dynamic vs Static and Strong vs Weak typing, which I've seen the last year, but managed to forgot. This may be a very interesting argument for all those who are afraid of Groovy/Ruby, after bad experience with PHP or Perl.

Build Trust in Your Build to Deployment Flow!

Frederic Simon talked about DevOps and deployment, and that was a miss in my schedule, because of two reasons. First, the talk was aimed at DevOps specifically, and while the subject is trendy lately, without big-scale problems, deployment is a process I usually set up and forget about. It just works, mostly because I only have to deal with one (current) project at a time.

Not much love for Dart.

Second, while Frederic has a fabulous accent and a nice, loud voice, he tends to start each sentence loud and fade the sound at the end. This, together with mics failing him badly, made half of the presentation hard to grasp unless you were sitting in the first row.

I'm not saying the presentation was bad, far from it, it just clearly wasn't for me.

I've left a few minutes before the end, to see how many people came to Dart presentation by Mike West. I was kind of interested, since I'm following Warsaw Google Technology User Group and heard a few voices about why I should pay attentions to that new Google language. As you can see from the picture on the right, the majority tends to disagree with that opinion.

Non blocking, composable reactive web programming with Iteratees

Sadek Drobi's talk about Iteratees in Play 2.0 was very refreshing. Perhaps because I've never used Play before, but the presentation was flawless, with well explained problems, concepts and solutions.

Sadek started with a reflection on how much CPU we waste waiting for IO in web development, then moved to Play's Iteratees, to explain the concept and implementation, which while very different from the that overused Request/Servlet model, looked really nice and simple. I'm not sure though, how much the problem is present when you have a simple service, serving static content before your app server. Think apache (and faster) before tomcat. That won't fix the upload/download issue though, which is beautifully solved in Play 2.0

The Future of the Java Platform: Java SE 8 & Beyond

Simon Ritter is an intriguing fellow. If you take a glance at his work history (AT&T UNIX System Labs -> Novell -> Sun -> Oracle), you can easily see, he's a heavy weight player.

His presentation was rich in content, no corpo-bullshit. He started with a bit of history of JCP and how it looks like right now, then moved to the most interesting stuff, changes. Now I could give you a summary here, but there is really no point: you'd be much better taking look at the slides. There are only 48 of them, but everything is self-explanatory.

To Java SE 8 and Beyond! | Simon Ritter

While I'm very disappointed with the speed of changes, especially when compared to the C# world, I'm glad with the direction and the fact that they finally want to BREAK the compatibility with the broken stuff (generics, etc.). Moving to other languages I guess I won't be the one to scream "My god, finally!" somewhere in 2017, though. All the changes together look very promising, it's just that I'd like to have them like... now? Next year max, not near the heat death of the universe.

Simon also revealed one of the great mysteries of Java, to me:

The original idea behind JNI was to make it hard to write, to discourage people form using it.

On a side note, did you know Tegra3 has actually 5 cores? You use 4 of them, and then switch to the other one, when you battery gets low.

BOF: Spring and CloudFoundry

Having most of my folks moved to see "Typesafe stack 2.0" fabulously organized by Rafał Wasilewski and Wojtek Erbetowski (with both of whom I had a pleasure to travel to the conference) and knowing it will be recorded, I've decided to see what Josh Long has to say about CloudFoundry, a subject I find very intriguing after the de facto fiasco of Google App Engine.

The audience was small but vibrant, mostly users of Amazon EC2, and while it turned out that Josh didn't have much, with pricing and details not yet public, the fact that Spring Source has already created their own competition (Could Foundry is both an Open Source app and a service), takes a lot from my anxiety.

For the review of the second day of the conference, go here.