Both PhoneGap and Appcelerator Titanium are a very popular open source JavaScript framework for encapsulating and configuring mobile applications. This article is a comprehensive comparison of PhoneGap and Appcelerator Titanium by Kevin Whinnery, the Appcelerator developer.
The following are all translations:
I've often been asked a question at various events and conferences for developers: how titanium compared to phonegap. I think it seems necessary to take some time to explain how each technology works at a macro level and to assess how the two technologies compare to each other.
At the macro level, phonegap and titanium seem to be very similar. They all provide cross-platform mobile development tools. Both JavaScript and web technologies are needed to a certain extent. Titanium and PhoneGap are open-source software with loose licenses (the Titanium Mobile SDK was released under the Apache 2.0 license; PhoneGap uses a similar licensing approach, PhoneGap is also known as a "release" of the Project "Cordova" administered by the Apache Software Foundation.
But the similarities between the two are actually limited to this. While both technologies are designed to achieve cross-platform mobile development, there is little in common with a set of ideas and approaches to solving this problem. In addition, from the sponsorship company's point of view,--phonegap's sponsoring company is Adobe,titanium's sponsoring company is Appcelerator, the business purpose behind each project is very different. I will describe these differences in terms of technology, philosophy, and business models in a detailed manner, from my own perspective.
In addition, if you have not understood before, I would like to state: I have long been appcelerator code donors and employees. Having said that, I try to make a comment on these two technologies from the technical and theoretical level, based on the technical facts of the objective. If you feel that the point I am expounding is inconsistent with the facts or fraught, please leave a message and I will update this blog post as appropriate.
I'll start by describing how these two technologies work at a macro level, and how these two technologies can be extended with additional native functionality. In terms of each technology, I will also summarize the main advantages and disadvantages of the cross-platform development approach they have chosen. The technical differences will soon be clear, but as I have done these overviews and comparisons, I will describe the conceptual and strategic differences between the two platforms and where they will go.
Let's start by introducing PhoneGap and how it works.
What does PhoneGap want to achieve?
The purpose of PHONEGAP is to allow HTML-based Web applications to be deployed and installed as native applications. The PHONEGAP Web application is packaged by the native application shell and can be installed through a native app store for multiple platforms. In addition, PHONEGAP strives to provide a common set of native APIs (application programming interfaces) that Web applications often cannot use, such as basic camera access that was not previously available in the browser, contact information in the device, and sensors.
On a more macro level, PhoneGap can be seen as a pioneer in the emerging World Wide Web Consortium device API standards, as they try to let web developers feel and appreciate the future now. Today, there is no platform to treat Web applications as a citizen, but Mozilla's promising boot to gecko platform has the opportunity to change the situation. Microsoft's Windows 8 is also making progress in prioritizing access to Web applications through the API, and it's worth watching. But the purpose of PhoneGap is to get a small subset of these rights for Web applications now.
PhoneGap End-User workflows, tools, and interfaces
To develop PHONEGAP applications, developers create HTML, CSS, and JavaScript files in their local directories in a way that resembles developing static Web sites. In fact, some phonegap developers have mentioned the additional benefits of this tool: they can be developed in a desktop web browser most of the time, without the need for a native toolchain (toolchain).
To run the PhoneGap application on the native emulator/emulator, developers have to create a project for each native platform they want to support and configure the Web root directory for the project using Xcode, Eclipse, or any of the native toolchain needed. Then use the tool to run the project. The specific steps are outlined in each platform's respective getting Started guide. Symbolic links are often used to transfer "www" folders to a common directory location across multiple native projects.
A similar workflow is required to install the native packaged PhoneGap application on the device. However, to complement this process and mitigate the need to locally install the Native Software Development Kit (SDK), the recently acquired Nitobi of Adobe has established a service called PhoneGap build, which creates an easy-to-install application in the cloud. Features that support PhoneGap compilation deployment have recently been integrated into Adobe's Dreamweaver tools.
The tools used in conjunction with PHONEGAP are standard web development tools such as Firebug, Web Inspector, and the text editor of your choice. There is also a new tool for remote debugging, called Weinre, which is now being used more widely. In general, the fact that you develop native applications is essentially abstract in the development process.
How does the phonegap work?
As we mentioned earlier, the PhoneGap application is a "native wrapper" Web application. Consider how Web applications are "packaged".
Many native mobile development SDKs provide web browser window components ("Web views") as part of the user interface framework (such as iOS and Android). In a pure native application, a Web View control is used to display HTML content from a remote server, or to display local HTML content that is encapsulated in some way with the native application. The native "wrapper" (wrapper) application created by PhoneGap loads the HTML page of the front-end developer into one of the Web View controls and displays the resulting HTML as the user interface after the application starts.
If the JavaScript file is included in a page loaded in Web view, the code is evaluated in the normal way on the page. However, native applications that create Web views can communicate asynchronously, depending on the platform, with the JavaScript code running inside the Web view. This technique is often referred to as bridge technology in the PhoneGap architecture-in titanium, bridging has a slightly different meaning, as described later in this article.
PhoneGap leverages this technology to create JAVASCRIPTAPI in a Web view that asynchronously sends messages to native code in a wrapper application and receives messages from native code in the wrapper application. Each platform implements bridging layers in different ways, but on the iOS platform, when you need a contact list, your native method call goes to the request queue that is sent through the bridge. The PhoneGap will then create a iframe,iframe that will load the Uniform Resource Identifier scheme ("gap://"), and the native application will be configured to process the Uniform Resource Identifier scheme, when all queue commands are executed. By evaluating the JavaScript string in the context of a Web view, you can go back and connect to the Web view from the native code.
PhoneGap does more than that, but it is a core part of the technology to implement bridging technology to deliver message passing from Web view to native code, which allows native code to be called by local Web applications.
Extended PhoneGap
Writing a native extension for phonegap requires you to:
In general, developers can participate in the same asynchronous messaging system that drives the core PhoneGap native API.
Advantages of the PhoneGap method
According to my estimation, the main advantage of PHONEGAP architecture is that it is very small and simple. It only does the work that you are good at. The PHONEGAP team intends to implement only the most basic native APIs for Web browser-based applications. Because the native API set is very small, it is easier to transplant phonegap into many different environments. Basically, any native platform that supports a Web view or Web Runtime environment can be a phonegap platform.
The non-visual native extension in PhoneGap is also very simple. When it comes to registering native code and receiving messages from a Web view, the requirements are very low. Thus, a simple native extension can be developed quickly. In my opinion, this plug-in architecture has also been well implemented.
There is also this advantage: native APIs and native application development are almost entirely abstract to front-end developers. Anyone who can write HTML, CSS, or even a small piece of JavaScript code can use the native app to wrap the page and distribute it as a native application. The entry threshold for using PHONEGAP to package Web pages into native applications is extremely low.
Disadvantages of the PhoneGap method
The quality of the user interface in the PHONEGAP application is different, depending on the quality of the Web view and platform rendering engine. The WebKit-based rendering engine on the iOS platform is powerful and provides the best performance. The Androidweb view can be used, but there are some obvious limitations. On other platforms, the performance of the Web view may be problematic, which depends on the version of the operating system.
There are common cross-browser issues that Web developers have always had to deal with. The user interface needs to be incrementally enhanced, media query, and a variety of ways to remain available on multiple platforms. Many mobile platforms now use WebKit, which is helpful, but even in webkit-based environments, there are still big differences.
Mobile browsers are always getting better, which will help alleviate those problems. But it's not easy to start dealing with the user interface's quality in the browser's native user interface--sencha employs a large number of web programming experts who specialize in solving this problem. Even so, on most platforms, in most browsers today, the user interface performance and responsiveness of native user interface quality is simply impossible to achieve, even with a framework like Sencha touch. However, is the browser already "good enough"? It depends on your needs and feelings, but there is no doubt that it is not as good as the native user interface. Sometimes it's much worse, depending on the actual browser.
PhoneGap is also not extensible with the native user interface. The front-end developer's application itself resides in the Web view, and the user interface is rendered by HTML. You can pass messages to native code and create native user interfaces on top of web views or near Web views, but it is difficult or impossible to integrate dynamic, Document Object Model (DOM)-based HTML user interfaces with native UI components. Appcelerator will come up with a solution-we're trying to link the native user interface to DOM elements early, but because the results are unpredictable and the quality is not good enough, we need to abandon this effort.
Strive to "the most basic" is a double-edged sword, it has another side. By default, there are very few native APIs available to PhoneGap applications, which makes platform integration very limited. There are a variety of plugins that are used to block some of these vulnerabilities, but in my opinion, their quality and maintenance levels are inconsistencies. However, the situation in this area is likely to continue to be improved--PHONEGAP has a strong community.
We'll explore PhoneGap's ideas in more depth, but let's look at the same technical aspects of titanium.
What does titanium want to achieve?
The purpose of Titanium Mobile is to provide an advanced, cross-platform JavaScript runtime environment and API for mobile development (today, we support iOS, Android, and browsers and will soon support BlackBerry 10, which will eventually support Windows Phone.) Titanium and Macruby/hot Cocoa, PHP, or node. js in fact have more in common than PhoneGap, Adobe AIR, Corona, or Rhomobile. Titanium is based on two realities of mobile development:
• A core set of mobile development APIs that can be standardized across platforms. The focus of these areas should be on code reuse.
• There are platform-specific APIs, user interface conventions, and feature features that developers should use when developing for that particular platform. There should be code for specific platforms so that these use cases provide the best user experience.
For these reasons, titanium does not want to "write once, run everywhere." We believe that developers should use the excellent, user experience enhancement features that target multiple platforms. We believe that, when necessary, native applications should take full advantage of the familiar, high-performance Native user Interface window components. However, we believe that native application developers do not need to learn to target specific platform APIs in order to draw rectangles or make HTTP requests.
Titanium attempts to implement code reuse with a unified JavaScript API, feature features for specific platforms, and native performance to meet user expectations. When you write a titanium application, you are actually writing native applications with JavaScript. Titanium should be seen as a framework for writing native applications, rather than abstracting the actual platform you are targeting.
Titanium End-User workflows, tools, and interfaces
To use titanium to develop native applications, developers need to install native toolchain for iOS and Android. However, once these tools are installed, developers can usually only interact with TITANIUMSDK's scripting interface (now Python-based). This can be done directly from the command line or through our eclipse-based integrated development Environment (IDE): Titanium Studio, which is more common in the latter way.
Using the Titanium toolset, you can create an application project directory with configuration files and localized files, as well as directories containing images, assets, and JavaScript source code written to run the application. By default, you don't have to edit HTML and CSS files unless you want to create a hybrid application that contains both the native user interface and the HTML-based user interface. The titanium application can, and often does, adopt a "hybrid" (native and Web) user interface, such as Facebook's native app. In this way, developers can actually implement PHONEGAP and titanium, but this is beyond the scope of this article.
With this toolchain, your application runs with the actual emulator/emulator for the target platform. The Titaniumstudio also provides step-up debugging, code completion, and other IDE-level features.
Installing to a device for testing is also usually done using our build system. In studio, we provide a wizard interface to configure any code signing dependencies, and then handle the task of deploying the application to a connected device. You can also use the native Toolchain to deploy or package your application if you like.
When you publish your application to the App Store, our compilation system will handle the task of creating the final application package for you. This step is done locally on the developer's machine, thanks to the native toolchain. The upload process is the same for pure native application developers.
When developing titanium applications, the underlying tool chain is mostly abstract. They are essential for development, but rarely require a front-end developer to use them directly. However, it is not abstract to develop native applications. The user interface is developed in conjunction with cross-platform components and platform-specific components that your application should handle: Background services, local notifications, application tagging, configuration, activity/purpose (on Android platforms) ... All of this is provided through the Titanium JavaScript API.
How does the titanium work?
What happens in the background of the titanium application is rather complicated. But roughly speaking, at runtime, your application consists of three main components: JavaScript source code (embedded in Java or objective-c files, compiled as an encoded string), and Titaniumapi for a specific platform with native programming languages And a JavaScript interpreter to evaluate the code at run time (the default interpreter is V8, or the Rhino interpreter for Android, or the JavaScriptCore interpreter for iOS). Of course, except in the browser, this will use the built-in JavaScript engine.
After your application starts, the JavaScript execution environment is created by native code and your application source code is evaluated. The JavaScript runtime environment that is inserted into your application is what we call the "proxy" Object-This is basically a JavaScript object that has paired objects in the native code. We are often known as the "JavaScript strip" (JavaScript Land) and "native zone" (native land) in titanium applications because they are in some way parallel to each other. The proxy object exists simultaneously in the JavaScript and native zones, acting as a "bridge" between the two.
In your JavaScript code, when you call a function for a global titanium or Ti object, such as var B = Ti.UI.createButton ({title: ' Poke Me '), this invokes a native method that creates a native user-interface object. and create a proxy object (b) that provides JavaScript with properties and methods for the underlying native user-interface objects.
User interface components (view proxies) can be arranged on a hierarchical system to create complex UI. Proxy objects that render the interface for non-visual APIs (such as file system input/output or database access) are executed with native code soft, and the results are returned to JavaScript synchronously, and the results are returned asynchronously in the case of APIs such as network access.
Hopefully this will help to eliminate two common misconceptions about titanium-the first misconception is that titanium never needed to use Web view components. Developers can create Web views as native UI widgets, but Web views are not used to evaluate titanium source code. A second misconception is that JavaScript code does not cross-compile into objective-c or Java in Titanium. Your JavaScript source code is evaluated at run time.
Extended Titanium
Titanium can be extended with native code, by non-visual functions and user interface functionality. By implementing the Proxy interface and/or the view proxy interface with native code, developers can create new native functionality for titanium applications that are provided by JavaScript. We provide the same interface for module developers who use iOS and Android platforms to create titanium own internal interfaces.
Advantages of the Titanium method
Because titanium is designed to provide a more advanced API for cross-platform native mobile development, you have direct access to a wide range of native features and capabilities, from user interface components, socket interfaces, to notification systems integration. The purpose of the titanium is to narrow the functional differences between the titanium application and the pure native application to almost zero. We may never directly support the API for the entire platform, but we want to cover 90% of the most common use cases and provide a platform so that those who need it can add the remaining 10% use cases.
Since titanium can be extended with visual components inserted into the same view hierarchy as the rest of the application, you can eventually implement any possible user interface on the underlying native platform. Need to use special native code to let table view (TableView) Scroll at 60fps speed? You can do that. Want to seamlessly integrate the OpenGL drawing surface of your game while preserving the logic of running loops with JavaScript? You can do that. You can integrate these user interface extensions directly into applications written in the core Titanium API.
The look and feel of the titanium application is also an advantage of this platform when using Common User Interface window components. No visual emulation (either by applying CSS or by using OpenGL or Flash to render the User Interface window component). When you create NavigationGroup, it gets support for the actual uinavigationcontroller on iOS. Animations and behaviors are consistent with the expectations of native application users, because you use the same user interface controls.
Because titanium provides an advanced native programming API through JavaScript, anyone who has used the ECMAScript-based language (which has many developers in the language) has greatly reduced the entry threshold for native programming. As a result of titanium, the Atwood law is still applicable. This law refers to: any application that can be written in JavaScript will eventually be written in JavaScript (see below).
Disadvantages of the Titanium method
The scope of the Titanium API makes it difficult to add a new platform-implementing the Titanium API on a new native platform is a daunting task. Because of this, the titanium platform only appears on mobile platforms that are currently considered the most important: IOS, Android, and the Web.
Our mobile web browser support has not yet reached the quality that can be put on the market-we continue to work on improving the performance and feel of our User Interface window component set while perfecting the implementation of the core Titanium API.
Because the abstraction layer provided by titanium is huge, our own internal framework still has problems with the API implementation not achieving the best standards. In some cases, some user interface components do not perform as well as native user interface components, such as a very large tabular view of layout-highly customizable. Optimizing the core user interface components is still the primary technical task for our team. As we overcome our shortcomings and our hardware is improving, we see that this is no longer a problem. We also found that in many cases it is necessary to use information architecture, especially for large datasets.
In addition, due to the ambitious goals of the titanium platform, it is not easy to expand titanium. To effectively integrate a new native control or API, an in-depth understanding of the architecture and environment of titanium is essential. Developer experience, API documentation, and overall guidance for module developers. There has been a significant improvement in our latest version 2.0, but it remains an area of concern.
The difference in philosophy
So far, I hope the difference between phonegap and titanium technology is clear. But in addition to those differences, the purpose and direction of each project are different. PhoneGap's stated goal is to eventually cease to exist. As mentioned earlier, PhoneGap is designed to be the primary means of achieving new browser standards for devices. Theoretically, once the browser vendor implements the PhoneGap feature, the platform will no longer be necessary. PhoneGap itself does not want to be a platform-it is a plug-in (shim) that adds functionality similar to native applications to Web applications. The web is designed to be such a platform.
PhoneGap New sponsoring company Adobe has a strong interest in improving the web as a platform. In recent months, Adobe has been sparing no effort to produce tools that can develop HTML 5/CSS 3 Web applications. For me and many others, as standard web technology continues to evolve, Adobe clearly believes that the role of Flash is fading.
In essence, Adobe is a company that specializes in tools. The platform is actually a channel that adobe can use to sell tools. This platform was once flash. Now, in addition to Flash, the platform is primarily a Web browser. I don't know what role PhoneGap is playing in Adobe's product roadmap, but in many ways it has a similar use to flash. PhoneGap attempts to create an abstract runtime environment that enables cross-platform deployment.
If Adobe can sell tools for web development, and the Web can be used to develop more kinds of applications, this is obviously a big win for Adobe. By the way, it's good-there's nothing wrong with selling tools.
It is worth mentioning, however, that Adobe is not the governing body of the Cordova Project and is now PHONEGAP based on the project. This project is owned and managed by the Apache Software Foundation. The interplay between these two projects remains to be seen, but my intuition is that they will not have a big disagreement. In my opinion, the purpose of these two projects will remain consistent with the concept.
Appcelerator is also interested in the improvement of the web as a platform and has given support. When the web becomes more powerful as an application platform, everyone wins. The difference is that we think of the web as an excellent platform with unique features and a range of pros and cons. We did not expect the web to be the only mobile application platform. We believe that platforms such as IOS, Android, BlackBerry and WindowsPhone continue to be influential, providing users with a great experience. This choice and competition will be a good thing for consumers, but it's still a problem for developers.
We look forward to providing developers through titanium with a single code base that covers both web and native platforms while preserving the features, performance, and tight platform integration that users of the platform expect. We expect to build a durable platform for mobile client development, and services and tools can accelerate this process. We are not a company that specializes in tools-we are a platform company, and our success is tied to the success of the developers who use our platform. Over time, we want to build an open source platform company, in the spirit of Red hat and other giants in the field.
What kind of tool or method is right for you? As with all aspects of software development, this depends on the situation. There is no omnipotent technology. But hopefully this description and comparison will help you make the right choice for your situation.
Original address:
Http://developer.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap.html
"51CTO translation, non-authorized declined reprint, the cooperation media reprint please specify the source, the author and 51CTO translator!" 】
"Editor's recommendation"
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
