Only after taking the following into account can you intelligently make a good tool selection:. If the task at hand was to turn a screw into a piece of wood, a hammer would be a very bad tool choice. Choosing a tool for mobile development is similar. There are multiple solutions on the market, each with their own pros and cons. The key to making an informed decision about what tool to use is knowing the pros and cons of each particular tool and using that as a guide for which one to use for a particular problem.
There are several good reasons to use Titanium. The most obvious reason is that you can develop your app in JavaScript and then compile it out to native apps on multiple platforms. Right now the most obvious and popular platforms that Titanium supports is iOS and Android. They do have a version for BlackBerry, which was updated in the summer of with many great enhancements.
Mobile Web is a recent feature added to the Titanium Framework to make it as easy to create mobile web applications. This will be a handy ability to have, since right now there is no low-cost development environment that can do this.
If Appcelerator does it right, this should make it just as easy to produce an HTML5 mobile version of an app as it is to create a native app. This will help round out their product offering so that it can address both native apps and mobile web apps from a single code base.
Since Titanium allows you to create apps on three platforms, it makes a lot of sense to use Titanium to achieve some cross-platform results.
There are plenty of differences between iOS and Android, but there are plenty of similarities too. Windows 8 support will be added to Titanium in the second half of , according to an announcement released by Appcelerator in February of that year.
There is also a very preliminary version of Titanium that allows you to create apps for the BlackBerry Z What does this mean for the future of Android? Does is mean the death of Android? I doubt it. Does it mean higher prices as Android manufacturers pay Apple a licensing fee? With this ruling in mind, Windows 8 may seem like a more viable option for mobile apps.
I always like to try to figure out what a company is going to be doing in 6 months by seeing who they are hiring now. Once you start talking about the Android platform, the next thing to examine is the number of hardware devices that the Android Platform runs on. One huge difference about Apple and other software companies is their feelings about having their software run on hardware made by third parties.
They are now strictly in the mode of controlling every aspect of the user experience, and that includes being the only manufacturer of the hardware that iOS runs on.
This does have a huge positive impact on the user experience. Apple hardware has always been top-notch and just gets better with each new release. A similarly huge side benefit for Apple developers is that by owning maybe five pieces of hardware, they can test their app on the actual hardware their users will be using.
With perhaps two or three iPhones, a couple iPads, and an iPod touch I just borrow my kids to test apps on , a developer can make sure the app will perform well on the devices. This tight control follows over onto the software side as well, helping the developer know that on hardware X running software version y , things will go well.
Just a few pieces of hardware, and a few different OS versions to test on…nice. The biggest hurdle to overcome when developing for Android is the huge segmentation of different hardware platforms. This makes it hard to ensure your app will run well on all devices.
Titanium has pretty effectively isolated the different APIs and put them in their own namespaces, which is good. In fact, with the new release, they seem to have made things a little more granular between iOS and Android, such as Ti. A compatibility layer is an API, either home-grown or developed by someone else, that runs on top of the standard API and makes calls to it internally. This is a great way to handle the differences between platforms and devices. My own compatibility layer is located in my own namespace TiCL , where I store functions that help even out the differences between iOS and Android and some simple convenience functions.
Titanium offers plenty of other value besides cross-platform development. Titanium allows you to create mobile apps using JavaScript. This is without a doubt the biggest advantage that Titanium brings. Its ability to create mobile apps for multiple platforms just makes it that much more powerful. Using Titanium allows you to write mobile apps without having to get into all the details of the platform you are deploying to.
Without something like Titanium, there are many things you would need to come up to speed on to get even a basic app done. Another aspect is the relatively large learning curve of getting up to speed on Objective-C. To help show exactly where Titanium helps bring value and increase productivity, here are the three steps that need to happen to learn and become proficient with a new programming language:.
Just about any modern programming language has a namespace and API that you need to learn. There is usually a namespace that organizes the functions into a logical manner. After working with a particular language and learning the API for a particular platform, experience is still required.
When you learn a completely new language, such as Objective-C, you have a learning curve in all of these areas. Titanium lets anyone with JavaScript skills leverage them to quickly create mobile apps.
You have already gone through the first and third areas mentioned earlier: you already know the language, and there is experience using it that you can draw upon. It is mainly learning the API where the time is spent in getting up to speed with Titanium. For Java, well, it's more or less a. Once the front end can understand your dependency matrix, we then invoke the SDK compiler i. So, a simple way to think about it is that your JS code is compiled almost one to one into the representative symbols in nativeland.
There's still an interpreter running in interpreted mode otherwise things like dynamic code wouldn't work. However, its much faster, much more compact and it's about as close to pure native mapping as you can get. We're obviously still got plenty of room to improve this and working on that.
So far in our latest 1. From a CompSci standpoint, we can now however start to optimize things that a human really couldn't easily do that - much like the GCC compiler already does today. Like jhaynie said, the application is compiled into native code, but there is still an interpreter in-place to run some javascript, which allows the application to be very dynamic.
Within the package - among others - you can find my source html and js files. There are also a lot of libraries ssl for example shipped with the package because you can have low-level access to a lot of things within this framework. I think that they take your code and wrap around some kind of interpreter software and libraries. In my case it would be like if I pack my html and js code next to a tiny browser that only displays my site. Stack Overflow for Teams — Collaborate and share knowledge with a private group.
Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Ask Question. Asked 11 years, 8 months ago. Active 8 years, 4 months ago. Viewed 42k times. Improve this question.
Darrell Brogdon. If that sounds complicated then rest assured, it's really not. Objects are nothing more than a collection of named properties key-value pairs , it's just that the values of these properties can be anything from a variable or a primitive to another function or object.
These objects can be modified at any point during your application's lifecycle, including having members removed, changed, or added. Note that even though there is not really a "method" as such in JavaScript, functions that are properties of other objects are often called methods in order to distinguish them from their parents.
Once you understand how scope and the global object works in JavaScript, you begin to understand why many developers struggled in the early days with memory leaks and poor performance in their Titanium applications, and why Appcelerator is encouraging all developers to make the move to a CommonJS code structure. CommonJS is a specification for defining how JavaScript acts outside of the browser.
Its intention is that a developer could write JavaScript code for one system, and be able to run that same code on another system or host environment safe in the knowledge that it will be compliant and will work on both. We will be explaining CommonJS in depth in the next chapter. First, let's define exactly what is meant by "global" and "local" scope.
In JavaScript, everything is defined in function scope. This means that the variables declared within a function are only available from within that function and not outside of it.
Conversely, it also means that variables defined outside of the scope of a function or statement declaration are therefore also available from within the said function or statement. The following example illustrates the difference between local and global variables:. The same principle in JavaScript applies to nested functions, which is called scope chain. This means that functions defined inside other functions will have access to their own variables, and the variables of their "parent" functions.
So we now have a good understanding of scope in JavaScript, as well as the difference between local and global scope. By the same token, you should now understand what the global object is. It's the top-level object that holds all global objects and includes functions and variables that are declared in global scope. In the browser, the global object is known as window.
In Titanium, the global object is defined as this inside your app. So why do we want to avoid globals in our code? Namespace pollution : This means that because global names are available everywhere, you may end up with a situation where you are using a global object when you think you're using a local one, or where you end up declaring a global object unintentionally for example, because of a typo. Non-locality : Good code is easy-to-read code, and the best code is created when it is modularized—meaning lots of small, localized functions or objects that are limited in their scope, making up the app as a whole.
Over reliance on globals means that you will end up with a large mess where one part of your app can be hard to distinguish from another, otherwise known as "spaghetti code".
It also means that every time your code needs to find a variable, it has to search the entire global scope which can slow your application down. Collisions : If you declare global variables in your app. It is one of the main reasons why Appcelerator and this book advocates the usage of CommonJS, which will be discussed in depth later in the book.
JavaScript can be pretty forgiving, and if you're not careful, you can get into some pretty sloppy habits as a JavaScript developer. We've all seen code before that omits the semicolons, neglects the curly brackets, and in general is just poorly formatted.
Often this is just an irritation as it makes code harder to read and understand, but sometimes it can lead to unwanted and unusual behavior.
Let's first take a look at an example. While the following code is badly formatted, it will execute just fine and run without error:. What happens if this function is extended in order to make another function call? What if our comparison happens to be true?
You may initially think that the previous code would set our message variable to Huzzah! What actually happens is this:. This means that regardless of whether the variable iLoveJavaScript is true or not, anotherFunctionCall is always going to be executed. It is therefore best practice to always use curly braces, and always end lines of code with a semicolon, even if technically they aren't needed.
This should go without saying, but avoid the use of eval at all costs. In case you weren't aware, the eval method takes a string containing JavaScript code and executes it at runtime. It's slow and full of potential security risks. While there are rare cases where you may want to use eval for example, for complex user-generated mathematics, or inside a tool that runs code on the fly for testing purposes , there are almost always better methods available to you than the eval method.
The alternatives to not using eval can be complex. One suggestion to avoid eval could include using a function instead. This keeps the evaluated code out of the global scope, i. Implementing brackets is obviously important for good JavaScript code, but just as important is the location of your opening curly bracket. Developers' preferences on the position of the opening bracket tend to come from whatever language they are most used to. For example, in C.
NET code you would format your opening statements to have the curly bracket on the following line—in fact the IDE automatically formats it like this for you:. Others tend to place the first bracket on the same line as the if statement, which is the preferred way of formatting in JavaScript, as there are certain times when the JavaScript interpreter can make your code behave in unwanted ways. Take the following code for example:. So it's best practice to always have your opening curly bracket on the same line as your opening statement, to avoid potential parser errors.
JavaScript implicitly typecasts variables when they are compared. Let's take a look at a couple of non-explicit comparisons and review the results:.
0コメント