Appcelerator Developer Blog

Newbie Tuesday: Hybrid App Basics Part 1

Published on February 21, 2012 by Kevin Whinnery (Platform Evangelist)

The following is the latest entry in a series of Tuesday blog posts covering basic topics in Titanium and JavaScript development.

Titanium allows developers to use local HTML inside a WebView component. There are a variety of compelling use cases for this, in situations where the browser provides the best tools for a given job. Whether it’s badass canvas libraries like three.js, as seen in the “Twisti” series on Forging Titanium, or simply displaying structured text in HTML, there are lots of places where a WebView and local HTML content may be the best solution.

Beyond these targeted uses of HTML in native applications, some apps choose to use HTML and CSS to render their entire user interface. These types of apps are popularly referred to as “hybrid” applications, where an HTML page is wrapped in a native shell, giving it access to native functions not usually available to a web application. Now, generally we believe that native UI is best for native applications, and will produce the most performant, familiar, and responsive interface. However, there may be use cases where an HTML/CSS-based UI may make sense given your app’s requirements.

In these situations, Titanium presents a very flexible hybrid application solution, while still retaining access to the thousands of native APIs and full native extensibility provided by the Titanium Mobile SDK. In this tutorial, we will show how local web pages can access native APIs in Titanium, using jQuery Mobile for our hybrid app’s user interface.

Embedding Local HTML

Creating an embedded WebView which references local HTML is trivial in the Titanium JavaScript API:

var win = Ti.UI.createWindow();
 
var webView = Ti.UI.createWebView({
	url:'/index.html'
});
win.add(webView);
 
win.open();

Now, we place our index.html file, and the dependencies from jQuery Mobile, in our resources directory:

After throwing together some HTML to showcase basic jQuery Mobile UI, we’ll end up with a user interface which looks something like this:

iOS Simulator

Important note: By default, Titanium processes all JavaScript in the resources directory on Android to optimize for native apps. For a hybrid app today, you must prevent this behavior to keep your application HTML’s directory paths intact. To accomplish this, add the following line to your tiapp.xml:

<property name="ti.android.compilejs" type="bool">false</property>

So that’s the first part of the puzzle – in this way, we can embed and use local HTML in out native app just like we would if we were programming in the browser. But how do we access native functionality? Titanium doesn’t actually expose native APIs directly to the WebView. Native APIs are accessed indirectly using Ti.App.fireEvent and Ti.App.addEventListener. Using these messaging APIs, we can communicate between the JavaScript context of the web view wrapper and the native app.

We’ll explore techniques for doing that in the next article in this series.

    —

    Submit your app: “Built With Titanium”

    Published on February 20, 2012 by Kevin Whinnery (Platform Evangelist)

    A new community site has sprung up dedicated to showcasing the 30,000+ apps built with Titanium! Sharry Stowell (of Learning Titanium) has posted this new community site where developers can add their applications to a categorized showcase.

    To submit your application, tweet a link to your app in the store/market where it resides to TiBuilt. Sharry will process it and bring it into the fold, and your app skills will be on display for all to see. Great work Sharry!

      —

      Internationalization of App Names

      Published on February 17, 2012 by Tony Lukasavage (Platform Evangelist)

      Editor’s Note: This and all further updates to internationalization can be found in the wiki.

      In the wiki we have pretty extensive documentation on internationalization of application resources. One thing that has been a little tricky for some developers, though, is changing the actual application name based on locale.

      For example, say you had an application named “Cat”, but you wanted it to be “Gato” in Spanish locales, “猫” in Japanese, and so on. Let ‘s see how you would prepare your application to display its name appropriately for both iOS and Android distributions.

      Changing Locale for Testing

      Before learning to configure your apps to use localized strings for application names, let’s first see how we can change locales manually for testing. Below you can find short videos for both iOS and Android that show you exactly how to do that.

      iOS App Name Localization

      For iOS it’s pretty simple. Use the standard method for creating localization paths, which means creating and using the i18n directory like this (details here):

      In each of your language directories under i18n, you’ll include an app.xml file that includes the necessary XML structure for defining the localized name of your app. That structure will look like his for each file:

      i18n/en/app.xml, i18n/es/app.xml, i18n/ja/app.xml 

      And that’s it. The next time you build your application, these localized strings will be used for your application name. If everything was configured correctly, you’ll see the app name has changed based on the selected locale.

      Android App Name Localization

      In its current state, Android app name localization is a little more involved. First, we need to create language-specific resource folders explicitly for Android. To do so, we will create the platform/android/res/values-(language code) directory structure, like this:

      You’ll notice in this case we are creating the Android native strings.xml files, rather than the app.xml files used by iOS. While the file names are different, the contents will be identical to those in the iOS files seen above.

      Aside from the strings.xml files, there’s one more thing we need to add. To make your app use these localized strings, you need to modify the existing AndroidManifest.xml. In order to do that, We need to add that custom manifest file, seen in the picture above at platform/android/AndroidManifest.xml. The AndroidManifest.xml file placed here should be a copy of the generated AndroidManifest.xml file found in your project’s build/android directory. For more details on custom AndroidManifest.xml files, check out this wiki entry on the topic.

      Now open up platform/android/AndroidManifest.xml and change the android:label attributes of the <application> and <activity> elements from the defined value of your app name to the value @string/app_name. Yeah, that was a lot of instructions all in one sentence, so here’s a gist to show you what I mean:

      With these changes in place, you can now rebuild your app (probably best to give it a clean first) and you’ll have a successfully localized application name.

      For Reference…

      This is how your home screens might look on Android and iOS when Japanese is the selected language.

      And just in case my description was clear as mud, check out a Titanium project with these localizations set up first hand. Just go to the AppNameLocalization project repository on Github. It contains the very basic project discussed here. With all this, you should be well-equipped to distribute your apps in as many languages as you wish to support.

      Links

        Mobile —

        Xcode 4.3 and Titanium

        Published on by Kevin Whinnery (Platform Evangelist)
        UPDATE (3/19/2012): Xcode 4.3 is now supported in our continuous integration builds. Go to http://build.appcelerator.net to get it, and make sure you are downloading from the master branch.
        UPDATE (3/16/2012): You can get Xcode 4.3 working with Titanium as detailed in this post: http://developer.appcelerator.com/blog/2012/03/titanium-and-xcode-4-3-revisited.html

        Apple has recently released Xcode 4.3, which some developers have already started adopting. Please note that per our compatibility matrix here, Xcode 4.2 is the latest Xcode version that can work with Titanium. We are working to add Xcode 4.3 support as soon as we can.

        An unsupported and untested workaround can be found on the Q&A here, but your mileage will vary. Please refrain from upgrading your Xcode tools to version 4.3 until we can release tooling support for that version.

        Thanks, and we’ll update this post as we have new information.

          —

          Forging Titanium Episode 22: Path-like Menu

          Published on February 15, 2012 by Tony Lukasavage (Platform Evangelist)

          Editors note: This and future episodes of Forging Titanium are available here.

          Today we’re going to do something a little different with Forging Titanium. We’re going to take a popular app from the wild and see how we can implement some of its features in Titanium. Today’s target: the animated menu from the Path mobile app.

          In this episode we’ll cover topics like:

          • Advanced animation techniques
          • Rotating and scaling UI components
          • Native iOS module development
          • Cross-platform considerations
          • Titanium extensibility

          With these techniques, we’ll not only show you that Titanium can execute and perform as well as its native counterpart, but also do so from a single code base.

          Episode Resources:

            Mobile —
            Page 29 of 90« First...1020...2728293031...405060...Last »