 I hope I am audible because I am generally not a loud person unless my code is not working, which happens every other day. Good evening ladies, gentlemen and developers, no offence meant, just the added respect for developers. As was mentioned in the introduction, my name is Gaurav Khidrpal, I am coming all the way from the deserts of Rajasthan to Ten DroidCon. And going by the sessions that we have had so far I can confidently say it's been worth it. And I hope my session continues to be great. Thanks for coming in. Yeah, thank you. Pleasure is mine. A couple of things, you'll notice a lot of visuals in almost all of my slides. And then you'll see some text in red occasionally. That's just meant to kill your funny bones and I hope that works. So, how many of you have actually heard about Accelerator Titanium? Okay, that's a sizable number. How many of you have downloaded it and tried using it? Not bad. Okay, so I am actually a member of the Accelerator Titans community. It's basically a group of volunteers who help spread the word on Titanium, who are basically contributors on the Titanium forum, who help document Titanium API and who also increasingly are attending such events in order to educate developers on Titanium. I'm not sure how many of you were in the previous talk on PhoneGaft, which actually ended with the objective of PhoneGaft Rocks. This is definitely not the objective of this session. The objective is to educate you on what Titanium can do, what Titanium cannot do, and when you should prefer native development and when you should prefer Titanium. So, this is a short agenda and the text in front is just a reminder. Post-length session, it's been two long days, so I hope I can keep you all awake. This is not sponsored by Tata Team, but I generally like the Jagure slogan because it helps people stay awake. I will be quickly walking through an introduction. I have been introduced, so I would actually like to know more about the audience. Then I'll be giving you an overview of what we plan to cover, the classical versus native and the India versus Pakistan debate. What is cross-platform development? What is Titanium? What is the mobile architecture of Titanium? How you can do Android development with Titanium? What is Titanium Studio? How you can set it up? Why Titanium? A small case study and then I'll open for questions. Okay, so I have actually been introduced, so let's phrase it as questions for you. Any school or college dropouts here? Raise your hand. Wow! Remarkable. School or college? We have a team jobs and affiliates among us. Otherwise, developers are generally too focused on the categories they don't drop out and when they end their careers, they are still developers. So I can drop out. How many of you are on the wrong side of 30? Raise your hands. Okay. How many of you are below 30? So actually you are all on the wrong side of 30 because life begins at 30. So yeah, I mean I have been working for as long as I can remember. The first app actually I made, it's widely regarded as the ultimate killer mobile app on all platforms. It's not any words. You can run it on future phones, you can run it on smartphones, you can run it on any phone. So I'll give you a couple of hints and those are actually dirty hints. It's a three-letter word. It's normally called a three-letter word in India and it's normally called a four-letter word in the western countries. Yes, so the SMS is the right answer and unfortunately I happened to be at a conference and I spoke about three-letter and four-letter words. They didn't get it. I told them that people in western countries use it all the time, we use it sparingly and then I started to get dirty answers. Just in case you didn't know, they don't call it SMS there, they call it text and that's the four-letter word. WebOS, this is an Android conference so I'm not going to details but there are two main reasons why I want to mention WebOS. Anybody has word about WebOS? Anybody has worked on WebOS? Be honest. So I thought I was the only one working on WebOS in India. So the reason I took up WebOS was it's actually a mobile platform built entirely on web technologies. So it runs on JavaScript on a framework called NEO. And all the debate around web versus native and HTML versus Java or HTML versus Objective-C We are all talking about apps but here is a platform which itself is built on web technologies. And in case you have used the Touchpad or if you have used WebOS you would know that the kind of user experience it provides is actually at par with Android or iPhone. The other reason why I mentioned WebOS is because I have tried my hands at literally all mobile platforms wherever I found an opportunity to make money. WebOS launched earlier this year. I got in and I wrote two apps which were on the first hundred apps to be developed to be launched for the Touchpad. And I made a lot of good money in the first two months. In fact even more than what I usually make out of Android apps maybe in a year. Then the unexpected happened. HP killed WebOS and same day they actually sent me a mail that I am actually the WebOS ambassador for India. And they sent me a t-shirt. I love WebOS. A few days back I tried not to communicate with them. A few days later I received another t-shirt and actually I am wearing it now. And it has a touchpad at the back so I probably say that there was a time when WebOS was close to my heart and now there was a time when it is close to my heart. Android, iOS no questions. I mean these are the two platforms where the money is. The only reason why I should deviate from these platforms is if you want to take risks like I did and get t-shirts. Titanium, yeah I have been working. I have been following that platform for the last year or so. Unfortunately I am not paid so I will not say Titanium problems. Key interest in cross-platform frameworks. So I have actually tied my hand but almost all frameworks that I have heard of. Titanium, PhoneGaps, IncherTouch, RoMobile and there are a few others as well. That was primarily because a lot of time I was actually doing trigger development which I think is an overkill if you do it on multiple native platforms. And especially true if there is a website or a application and you have to develop a native counterpart application which does not involve any rocket science. Okay so this is purely out of academic interest about the company founded in 2007 in a place called Atlanta where there are startups, 18 employees. So it is actually 100 plus it is known phenomenally and phenomenally and over the next year they will be growing at the same rate as India's population. So they may not have the 7 billionth baby but when you can be rest assured you will be hearing a lot more of Accelerator. Then I got out at a place called Mountain View where worldwide presence was strong we see so lots of firms in the back. The icons that you see the first one actually represents, can anyone tell me what that represents? If you have used something called, there is another, sorry? Aptama. Aptama. So that actually represents Aptama and that is a company which Accelerator acquired sometime back. So there used to be an IDA built on top of the platform called Aptana Studio. So that is now Titanium Studio. The other icon it just shows you can build on Macs, PCs. The last one it shows that, so there is a lot of talk about HTML5 and we have got a lot of frameworks. PhoneGap is a good example of an HTML5 framework. Companies are actually increasingly buying companies which develop or use HTML5 frameworks. So PhoneGap is a good example I don't know why it was not mentioned but PhoneGap recently got acquired by Adobe. So that's one of the reasons Adobe is pushing for HTML5 now. So Accelerator similarly acquired a little known company called Particle Core and we will see what they produce on HTML5. So coming to the classical web versus native debate, how many of you here know HTML JavaScript? You know Java? How many of you know both? And how many of you know none? You should probably go out. So frameworks like Titanium, PhoneGap, these essentially bridge the gap between a web developer and a native developer. The web as we know it is one of the applications of the Internet but it's actually the worst as an unlikely hero. The best part is you can quickly write code in HTML JavaScript. It's actually cross-platform as long as you are implementing it as using open standards and etc. We will come to cross-platform mobile apps a bit later. Open standards we all know wherever you prefix the word open it's actually either HTML5 or if you prefix the word if you suffix something called a letter against open. It kills technologies like Flash and that's what Steve Jobs did last year. So Titanium, if you know web development, great. It's a platform that you could explore. Unfortunately most developers and it's probably a part of our education system that we are mostly taught maybe C, C++, Java. But there are not many colleges which actually teach you HTML and JavaScript. So native actually gives the kit to developers. So they find it more challenging as compared to HTML and JavaScript. If I say I'm a web developer, yeah, you design websites. So then there is another debate about performance and I'll come to this shortly. Hardware interaction. So in the last session also there was a question asked about if you want to integrate the Android SDK with phone gap. I will not answer about phone gap but if you want to do it with Titanium it's a very bad idea. So anything that involves hardware or is very performance intensive you should probably stick with native. So that's where Titanium doesn't fit in. Typically this is basically the future. So it's going to be, right now it's just mobile and social. Going forward it's going to be mobile, social and cloud. So you will see a lot of apps interacting with their cloud counterparts, like Amazon Web Services, Google App Engine and lots of other cloud players. The web has evolved so has the mobile platform. So two years back HTML was the way to build websites. It used to be deployed on web servers like Apache. Now we are probably between the second and third stage right now. So you have frameworks in Java like Spring, Hibernate, Stratz. And there are application servers like Apache Tomcat and there is Weblogic, WebSphere, Sanman. We are now getting to a stage where middleware is getting increasingly important and SaaS is actually just beginning to make its presence fit. SaaS you can, as I mentioned, AWS, Google App Engine, these are all SaaS platforms. If you look at the mobile platform part, in now it's been mostly native SDKs, HTML5 is now emerging out of a draft. It will soon be a standard cross platform tools. That's where phone gap, all these tools come in. Eventually we believe that this is coming down to an integrated mobile platform. One platform where you can move and as Aishman mentioned, it's hybrid apps. So you can actually develop apps which use JavaScript, HTML as well as native code. But we aren't there yet. So cross platform development, it's probably the most abused term in mobile development. So Java, I say it's evil because it's mobile developers. It said write old ones and run everywhere. Which actually it's not true at least in mobile development because when it comes to mobile cross platform, at least in titanium, it means that you can use a lot of UI code because there are wrappers for everything. So if there is, for example, if there is a list view in Android, if there is a list view in iOS, titanium would actually expose you something for the TI.Android.ListView and TI.Iphone.ListView. So basically the wrappers can actually let you use your code but there is a catch. You have to have a good design. There is no magic wand which would reuse all of your code. The objective is to provide the best in class experience on every platform. The objective is not to write once, run everywhere. It is to write once, but to be able to adapt it to run everywhere. So titanium, it's classical definition of titanium. It's an open source framework, HTML, CSS, JavaScript. If you haven't seen the site, the Twitter, the source code is actually openly available. This is the standard sales switch that's an integrated mobile platform for enterprise and consumer applications. So there are three main entities and the companies it's in between. Community, which I'm a part of. Customers, who get apps built on titanium and then absolutely ties up with a lot of companies. Okay, so what is titanium? So basically any titanium application can be divided into four parts. There are two parts of it, which actually you do. And there are two parts which titanium provides. So you actually write the HTML, CSS, JavaScript. There is Ruby and Python supported as well, but I've never used them so I will probably not cover them. Then you are supposed to write the HTML, CSS, JavaScript code. Then you invoke the wrapper APIs, which are actually an abstraction for all the native functionality. There is a language quiz bridge that compiles all the web code into native application code, and I'll talk about this in detail. Then there is a runtime shell that accesses the application for cross-platform distribution. So generate your APKs and the IPAs and the app files. Okay, so mobile architecture, which is kind of similar to what I just spoke through. The application sits on top. It's all HTML, JavaScript, code. Then there are the wrapper APIs, UI, UI API, own API, optional modules. There is a bridge for each. There is a bridge for Java. There is a bridge for JavaScript. There is the native OS update that below that. And just to give you an example of the kind of mapping it has to UI components. There are wrappers for nav bar, nav bar. Mostly most of the standard UI components that you're trying on both platforms. Okay, so coming to Android development with Titanium. How many of you believe that the UI is the most important aspect of a mobile application? Okay, those who don't believe that it's one of the most... What do you believe is the most important part of a mobile application? If not the UI. Okay, so we have consensus that UI is important. Characteristics of an Android interface. There is a touch. So there is no... You're asking if you don't need to have a back button. So there is touch as well as hardware. There is a back button. Activities are the backbone of your Android application. Interplaces are less homogeneous. There are phones of MDPI, MDPI, HDPI, Super HDPI. There are tablets 5, 6, 7, 9, 10, 11 inches. And as a developer it often becomes a nightmare because you have to read the guidelines all the times if you have to support certain devices. As compared to Android, iOS is a bit more structured. It's all touch-centric. There are gestures. And Apple actually strongly encourages uniformly in UI conventions. It's slightly changed with the launch of the iPad and the Retina display. But it's still a lot more consistent simply because Android follows a multi-vendor multi-modern philosophy. So if you want to bridge the gap between the two interfaces and design a truly cross-platform UI, what should you do? So you should focus on the primary task. You should never try and enforce an iPhone UI scheme on an Android application and vice versa. Ideal advice is that you would probably start off with the same phase that you would do with a native application. Sketch out the information architecture for your apps, do the storyboarding, draw some wireframes, and based on those exercises when you get down to the actual design, just reuse whatever you can to use. Okay, so this is all Android. This has nothing to do with titanium as such. Just a quick recollection of how Android applications work. There are one or more activities. There are intent filters. You need to be very careful of the API level that you use. Intents, actions, categories, mind types, class names. Okay, so there is a task stack. Your app is already defined in three points. There are systems as well as custom intents. This is all standard stuff. Just a brief refresher in case. Can anybody tell me the Android life cycle, the app life cycle? What is the first stage? Okay, what's next? On create and then on stop? On stop. On stop, okay. What's next? So that's kind of good enough. Just checking. Use and launch of the app. Your intent is fired with a category and an action. I'm not sure it's very invisible. Okay, so what do you do with EI? As I said, the fundamental principle of titanium is to create a wrapper for everything that's there on the native platform. So you actually have custom JavaScript activities, which are a wrapper of your native activities. How would you configure your activities in an Android app, in a native Android app? So there is a component part for DIA.xml in titanium, which is basically the titanium version of Android Manifest. Everything else, in most cases, follows a one-to-one mapping. This doesn't work when Android comes up with a new version, like for example, Android 4.0, or for example, iOS 5. That happens, but there is a definite lag to get to that stage. So most of the... All of the Android stuff resides in a package for DI or Android. To create an intent, you simply go to DI.android.createIntent. To access your current activity, you can fix it with DI.android.currentActivity. For follow-backs, you can call this an activity.startActivity for the third. So like you would place your... In a native application, you would place your images in the resources folder, where also there is a component part in the resources folder. This is probably not very visible, I mean this is, in short, your titanium version of the Manifest file. This is how you can create an activity and an intent. So how many of you have actually attended yesterday's session by James, which was all about how to make cross-platform apps suck less? So he actually brought up valid point, and it was briefly discussed in the last session as well. I believe you actually brought that up. So there is a fundamental difference between how a native app works and how an app will not get technologies good for. So there is something called a rendering engine, which would be typically on your browser, it would be WebKit or some other engine. Similarly, there is a JavaScript engine, which runs for all such frameworks. Currently, titanium uses a framework called Rhino, which is efficient, but it needs a lot to be desired. So ideal would be to use the same JavaScript engine. We use that in Chrome, Chromium, Node.js, and others. This can actually lead to a 2x performance increase, and in many days, depending on your application, it can go through 10 to 15 times. So that's some of the criticism that comes across for most of the cross-platform frameworks that my apps aren't performing well or that it's slow. That's primarily because it's doing a lot of stuff. So you are writing HTML and JavaScript, it's actually mapping them to native implementations. So there is a significant amount of processing involved in that bridge, and that's what causes the slight delay. Some links, you can probably look at it, it is shared, it's actually shared. Okay, so what is Titanium Studio? As I mentioned in the beginning, AppTenna was a multi-level editor supporting HTML, JavaScript, and other languages. The company was acquired by Accelerator, and they named it to Titanium Studio. They added a lot more enhancements. So for example, if you need to look at... There was another question in the last session, which was how do I know if a particular API is available or not? So typically in JavaScript, if I need to know if a Java class has all the methods, I would use sci-fi. So that is one thing which is available in Titanium Studio. This is a classical architecture diagram of what all you can do. I've actually not pressed upon the Titanium desktop, but you can actually build only desktop applications in Titanium as well. And then Titanium Studio lets you build, there is a debugger which... which has to debug your applications for Android as well as iPhone, and then you can package your apps as well. Setting up Titanium Studio is actually quite simple. Go to Accelerator.com. It's free for Mac as well as Windows. On Mac, you can simply drag it to your applications. This is how it looks. I don't like it, but that's the way it is, and that's the way they decided that it should be. So it's a glyphs, then it's aptama, and then it's Titanium. So to make it look different, they actually inverted the color scheme. Some people like it, some hate it. I am in the latter category. This is how you would create a new project. You will just go to File, a new mobile project, and it would create an empty framework for you. So this again is how you would create a new project. So when you create a project, you can actually specify what are your targets and create the required files. And through preferences, you can select Titanium, and that's where you can actually configure which SDK you want to use. So why should you use Titanium? So the question of why, there is a very good example. If you've seen an ad on TV, I think two or three ads in which they should worship and there is a gentleman explaining about it and at the end of their ads, this person asks, how much will it be? So that's what I mean. So unless you see a good reason to adopt a new platform or unless there is a good reason why it would reduce your development time, you should not commit to a platform. Good part about Titanium is the core SDK is free. I hope you can resemble the icon below yesterday. It was there in the party. I'm sure lots of you enjoyed it. It's open source under Apache Roto License. There is a thriving developer community. If you're a larger organization and you want to partner with App Generator, there is so much training and support available as well. Why Titanium? I strongly believe that between native and cross-platform app, there is a definite sweet spot. And unless you hit that sweet spot, you will actually end up designing the app on the wrong platform. So as I said, if there are apps which require a lot of hardware interaction or which are very performance intensive, Titanium is not a good fit. If there are enterprise apps which actually deal with a lot of web services or mashups, if there are social utilities, if there is a brand, if you have a Facebook page for it, if you ever put a feed for it, and if you want to design a lightweight mobile app, Titanium is a perfect fit. Calibre low-end games don't ever try the post 2D or the Android and send in with Titanium. Anything that requires cross-platform support and if you can visualize a web application for it, Titanium is a good fit. These are the stats as to where Titanium currently stands. 200,000 developers, 25,000 apps, some of the top apps, some of the apps built on Titanium which have actually made it to the top 10 or top 100. NBC was in the number one iPad app, it's built on Titanium and stayed on top for quite some time. I'll actually touch upon Tripling World, it's a classical case study of Titanium. Before that, another reason why you should adopt Titanium is Uniformity in UIs, so you should actually maintain platform identity. You can actually get away with an Android app, you can put a back button on it, it will be uploaded to market but then users will come back and say, he has a back button with the Android app. That's why Google will actually fill your app out. That's why it's important to maintain platform identity. Back button for Android is just an example. This is an example of how your same code would look like on an Android phone as well as on an iPhone. Case study, okay. So Tripling World, the objective was to design an app for travelers which can actually translate questions and I'm glad if you cannot see what the boy is actually doing, so that's not very aesthetic. This gentleman is actually trying to ask his way to the bathroom and the boy is making some weird gestures. So the Tripling World team decided, okay, they'll probably start off doing this natively. So the whole team sat down and there were some hard-working developers who worked throughout the night. They wrote stories, they draw sketches and they finally built an Android app, which was great, but it took two months and then they had to do the same thing for iPhone and you would probably have to spend a few more nights like that. So then they decided they'll actually try out Titanium and with a reasonably big team, they actually, following a classical agile approach, they actually hydrated upon it and they actually built out, they actually released 50 minor versions of the app in two weeks and the result was a better looking app which actually worked just as well on iPhone as well as Android. I would like to repeat this was an app which does not require any hardware or there were no major performance constraints and it worked wonderfully well. So I think that is it. I can briefly show you me and me looking at Titanium Studio. This is how it looks like. So I actually had it working but we had a bit of a disaster yesterday in the Honeycomb lab sessions and I tried upgrading my apps and I tried upgrading my Android SDK and given the condition of Wi-Fi, I no longer have an SDK. So unfortunately I wouldn't be able to demo anything. I think we've done good work. We've asked a few questions so now is the time for you to return the question please. Questions? I have a question. I tried out the phone gap before for this cross-platform. Now if you see the Titanium, so every different API for Android IOS is there in the separate package means when I end up writing code I have to say that this code goes to Android and this code goes to IOS. Now how it makes a cross-platform like same code cannot be too different without modification? I didn't really understand your question. For example if I want to open a camera so it does not need to say I am opening camera in Android or IOS it just detects better tasks. There are actually a common set of classes activity is actually specific to Android so that's why it's under DI or Android but all the common classes are actually generated so you can use them in iPhone as well as Android. But if you just end up using activity and all the things then you can directly write in Java rather than having a lot more on the JavaScript. And if you are only building for Android I mean objective is if you are using Titanium I mean the end objective should be to develop on multiple platforms or only if you are more comfortable with JavaScript than Java. So means you can mix both activity with the common classes. So as I said people usually put PhoneGap, Titanium, Sensea all in the same packet and the comparison kind of blows up everything. So what I wanted to know is what kind of solution is Titanium trying to deliver to the market which is not addressed by a combination of Sensea and PhoneGap? Yes so actually you answered the question yourself. So Titanium is actually trying to be an end to end player so whether it's the back end, whether it's the UI the end objective is to just use one SDK if you done with the UI, if you done with the business logic all your port in one SDK. That's actually one of the reasons why a lot of people are using it with PhoneGap. So yes it helps create cross-platform application between Android and iOS and does it also help in various resolution streams which you find between iOS and Android? Unfortunately that remains a pain point so that is something which as a developer you need to handle but there are APIs which let you check that but at the end of the day it's still the same exercise if you are developing for Android you need to test on multiple resolutions, multiple devices. No scripts, no automated. Automation design and all that, that's still a pain point. I think device anywhere, the motion can offer two solutions in such space. So device anywhere is actually independent of whether you are using Titanium or whether you are doing native development. That's actually... And usually in web development when we have Titanium access test for web services we face cross-domain issues. So in Titanium that issue is a real result. No I've actually done a lot of applications which do that and I've never faced any issues if there are any specific issues that you think arise. Because I end up playing it from JavaScript. I mean so whether it's XML, whether it's JSON, whether you are filing a post request everything works as it would in JavaScript. If there were any specific concerns maybe I can address them individually. Yeah I hear the questions. Can we combine this Titanium and native development, native code? Yeah so that's actually a good question. That's something which I think Punga does at this moment. That's recently come out in a release of Titanium. I think it's still in beta so it's not available to the public but it's available to us as titles so I think you can expect it to be available within the next month also. But as of what I know it's still pretty buggy and that's the reason why it's in beta. Is there any reverse engineering allowed in this Titanium platform? For example you have let's say Android code for Android application and you want to convert it to iPhone. Directly from Android to iPhone. Why did you leave Titanium? I mean I didn't really understand. Yeah from the Java code. Yeah from the Java code. Can you reverse engineer and essentially create HTML and JavaScript? No unfortunately that's supported. That's a good idea for a startup. I saw the Android application but I actually checked the application on the App Store and I found the application looks like very much native application. So I wanted to know what sort of UI improvements they have done and it's all about HTML they have even in the full application. That's actually not developed yet so I cannot take the credit for it but I have it featured on the absolute website so I'm sure it's all right. No questions. Rather than Java to iOS code is there a way to reverse it in your Titanium Android code too? Titanium iOS code. That's not possible. In fact it suggests something like if there are few things like I know it should be like back button or something like that. There are few things like it is obvious that in Android it should be there and in iOS it should be there so once you do that in Android you should probably use iOS code easily or at least framework should be there where you can customize it. There is no mechanism to basically be able to convert Java code into JavaScript and I'm not sure if that's the intention anyway. Not a Java code to object itself. Just writing in code which I have. I'm not writing where... Yeah so I mean that's already a lot of the frameworks so if you create your UI components Titanium by itself will not create a hardware back button for you unless you want to do it. Unless you want to do it. There is a professional edition which is paid and so that's actually not free and the added benefits that you get is that you can actually become an accelerator Titanium, an accelerator Titanium yourself so then you get leads for projects for apps you can actually do a certification that they give you a badge and lots of other stuff. It's kind of same, the major difference is that there is something called a module marketplace where there are paid third party modules which you can integrate with your app so that's not available to community users. So that's the third party application which you are creating for the users of enterprise personas. The application can be used. Yeah it suffices. So I started out with community edition and then I ordered an application to the profession. Okay but as per the IE and the feature that I'm involved there's no questions. Any more questions? Okay. So let's wrap the session. Thank you so much Mr. Gaurav. Thank you for coming up. Thank you.