Difference between titanium classic and titanium alloy?

Titanium Alloy basically follows MVC (Model,View and Controller) framework with support of backbone.js and underscore.js where as in Classic structure there is no MVC framework.

In Alloy structure, we can write the code for ui and implementation differently in different files whereas in Classic structure we write code and ui functionality in single app.js file.

Alloy structure contains the folders for Models,Views and Controllers in which we can add our code in that particular files.Whereas there is no folders for Classic structure.

Here are my two cents. While Alloy is the main direction Appcelerator wants the Framework to go. There is absolutely nothing stopping you from using classic Titanium as your code base. Keep in mind that while it is easy to create mobile applications using Titanium, it is also very easy to generate bad code that don't abide by any design pattern. It is my understanding that Alloy, by forcing developers to follow a certain path, can do some of the heavy lifting for you. (releasing objects from memory, generate requireJS code, etc.) Hence being a huge gain for medium to low-level developers.

Of course, for developers like you who have deep knowledge of the framework, Alloy brings much less value to the table. That's kind of the same old debate between managed code (like Java or .NET) and native code (C or C++). Both approaches have their advantages and their faults. For example, native code might perform better, but it is more prone to memory leaks and bugs if the developer is not highly skilled. (you see where I'm going with this...)

In conclusion, I think that Alloy might actually improve the overall quality of many applications since not all developers are highly proficient with Titanium (as you are in this case). But I think that using the classic approach (that will always be available btw) will always provide more flexibility since you have full control over the code base.

As I said, that's my two cents

How will you going to architect your project ?

• when you compile the project Titanium converts your javascript code and gets interpreted.http://stackoverflow.com/questions/2444001/how-does-appcelerator-titanium-mobile-work 
• The code present in the Resource folder gets compiled. when you build for iOS then all the code present in your Resource apart form android folder gets compiled. and when you build for android then apart from your iphone folder all gets compiled.
• When you compile for android your app will run on android devices and for iOS build it will run on iOS devices. if you want to know under the hood then visit this linkhttp://titaniumninja.com/post/10559549700/fastdev-for-ios-how-it-works/ 

How will you seperate your code on basis of plateform ?

Before we get into the strategies you should adopt, let's look at the mechanics of handling cross-platform coding within Titanium. This includes:

• Platform identification
• Recognizing platform-specific APIs and properties
• Handling platform-specific resources

Platform identification

Titanium provides platform-identification properties in the Ti.Platform namespace that you can use for conditional branching within your code. These are:

Property	Description	Sample values
Ti.Platform.name	Returns the name of the platform returned by the device	iPhone OS for iPhone or iPod, android for Android, returns thenavigator.userAgent string on Mobile Web
Ti.Platform.osname	Returns an abbreviated identifier of the platform	iphone for iPhone or iPod, ipad for iPad, android for Android, andmobileweb on Mobile Web
Ti.Platform.model	Returns device model identifier	iPhone 3GS or iPod Touch 2G or Droid (unsupported on Mobile Web)

http://docs.appcelerator.com/titanium/3.0/#!/guide/Supporting_Multiple_Platforms_in_a_Single_Codebase

Memory Management tools both in Android and Ios ?

http://docs.appcelerator.com/titanium/3.0/#!/guide/Managing_Memory_and_Finding_Leaks

How will you do unit testing in Titanium ?

https://developer.appcelerator.com/question/146254/titanium-30--unit-testing--jenkins

Provide the difference between the Android and IOS UI/UX ?

1. “Back” navigation. 
In iOS applications “back” option is placed in the upper-left corner of the navigation bar. It is used to navigate backward within the defined screens in the application however it is not used to navigate backward across the entire device.
In Android devices there are two types of “back” actions: “up and “back”. “Up” is placed in the upper-left corner of the top bar and is used to navigate up the application’s information hierarchy. In contrast, “back” option is presented as a button on the physical device that allows navigating backward across the entire device.

Back navigation in GMail for Android and Dropbox for iOS

2. Top navigation. 
In iOS applications tab navigation is placed at the bottom of the screen. In addition, according to iOS guidelines there are no more than 5 tabs displayed at a time.
In Android applications tabs are recommended to be placed at the top of the screen. Besides scrollable tabs are allowed to be used in case there are more tabs than can fit in the viewable screen width.

Top navigation in Google Play and Dropbox for iOS

3. Switching between various data views.
In iOS applications switching between views of the single set of data is typically done through the bar divided into segments.  Each segment is responsible for one view.
In Android applications switching between views is done through the UI control “spinner”. This control is presented like a drop-down list of options. “Spinner” is usually placed at the top action bar.

Switching between data views in Google Calendar for Android and iOS Calendar

4. Search.
In iOS applications the searching UI control is placed at the top of the screen mainly.
In Android applications several searching options are available:

• “search bar” at the top of the screen that is similar to the iOS approach. However the bar is hidden until the user clicks on the search icon;
• “search widget” that can be placed anywhere within the application interface. Coomonly it is used within the application’s action bar at the top of the screen.

Search in Google Play and Foursquare for iOS

5. Actions. 
In iOS applications can be accessed through the toolbar that contains action buttons, through the action button that is in the upper-right corner hand side of the navigation bar or through the buttons within the interface screen.
In Android applications it is recommended to display actions in the action bar at the top of the screen. If there is any need in displaying more actions than can fit on the action bar, either an action overflow icon appears on the action bar for devices that don’t have a hardware “menu” button, or the user accesses additional actions by pressing a hardware “menu” button on devices where there is one. Android applications may also use contextual action bar. A contextual action bar is a temporary action bar that overlay the app’s action bar for the duration of a particular sub-task.

Actions in GMail for Android and GMail for iOS

6. Screen sizes and resolutions. 
iOS phones, for instance, come in two screen sizes and three resolutions (including the latest ).
Android devices are represented by a lager list of screen sizes and screen resolutions. This issue has a significant impact on the layout while designing the application.

How will you read the crash report of IOS ?

When an application crashes on an iOS device, a "crash report" is created and stored on the device. Crash reports describe the conditions under which the application terminated, in most cases including a complete stack trace for each executing thread, and are typically very useful for debugging issues in the application. If you are an iOS developer, you should look at these crash reports to understand what crashes your application is having, and then try to fix them.

Low memory reports differ from other crash reports in that there are no stack traces in this type of reports. When a low memory crash happens, you must investigate your memory usage patterns and your responses to low memory warnings. This document points to you several memory management references that you might find useful.

Crash reports with stack traces need to be symbolicated before they can be analyzed. Symoblication replaces memory addresses with human-readable function names and line numbers. If you get crash logs off a device through Xcode's Organizer window, then they will be symbolicated for you automatically after a few seconds. Otherwise you will need to symbolicate the .crash file yourself by importing it to the Xcode Organizer. See Symbolication for details.

This document also talks about exception codes, another useful information for identifying the cause of the crash.

https://developer.apple.com/library/ios/technotes/tn2151/_index.html

What are proxies in Titanium ?

Basically, a proxy is a special JavaScript object which is a stand-in for a corresponding object in native code (on iOS or Android – this magic layer is not needed on mobile web).  


http://www.appcelerator.com/blog/2012/02/what-is-a-titanium-proxy-object/

1 2 3 4 5 6

//"button" is a proxy object var button = Ti.UI.createButton({ title:'push me!',         height:50,         width:200 });

How Appcelerator Titanium works ?

Titanium takes your Javascript code, analyzes and preprocesses it and then pre-compiles it into a set of symbols that are resolved based on your applications uses of Titanium APIs. From this symbol hierarchy we can build a symbol dependency matrix that maps to the underlying Titanium library symbols to understand which APIs (and related dependencies, frameworks, etc) specifically your app needs. I'm using the word symbol in a semi-generic way since it's a little different based on the language. In iPhone, the symbol maps to a true C symbol that ultimately maps to a compiled .o file that has been compiled for ARM/i386 architectures. For Java, well, it's more or less a .class file, etc. Once the front end can understand your dependency matrix, we then invoke the SDK compiler (i.e. GCC for iPhone, Java for Android) to then compile your application into the final native binary.

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.0 testing, it's almost indistinguishable from the same objective-c direct code (since in most cases it's exactly mapped to that). 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.