A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
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.
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 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.
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.
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.
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?
• 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 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.
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.
How does the titanium work?
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.
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.
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.
"51CTO translation, non-authorized declined reprint, the cooperation media reprint please specify the source, the author and 51CTO translator!" 】
Start building with 50+ products and up to 12 months usage for Elastic Compute Service