Appcelerator Titanium - Alloy vs Classic

Question

I'm about to start a new Titanium project. So far, what I've written is what's now considered as "Classic Project" (I've been writing Titanium apps since before Alloy).

I was wondering whether or not it's worth while to switch to Alloy for my new project. I know that basically, Alloy compiles to "Classic" Titanium code before compiling down to the java project or objective-c project. I also know about a big advantage in that "pre-compilation" process, which is to mark in alloy code that are relevant only for Android or iPhone and not including the other in the compiled "Classic" code.

My main concerns are flexibility - as with "Classic" I feel like I have more control over the code and what's going on.

Second concern, I have controls (like open sourced sliding menu) that are not written for alloy - how will I be able to have them as part of my project?

I started asking myself rather to use Alloy or not after finding (introduced in TiConf 2014) TI UX (https://github.com/jaraen/Ti.UX.Templates) which is written for Alloy.

few other questions:

1. how can I have old UI code run inside Alloy?
2. Can I have controls written for Alloy run in a "Classic" project?
3. Can "Classic" project also map out code not belonging to iOS/Android?
4. is there a difference in performance between Alloy projects and Classic projects? what about other flexibility issues?

Thanks

Answer 1

Just in case someone sees this question and needs an answer:

I have also posted this question in the Appcelerator Q&A where I got some answers here: http://developer.appcelerator.com/question/177739/appcelerator-titanium---alloy-vs-classic

The answer I was given is partial, and more info could be found in a questions asked here: http://developer.appcelerator.com/question/177542/classic-vs-alloy

Answer 2

I felt that the switch to Titanium Alloy from classic was right for me. I felt that classic Titanium development wasn't structured enough nor provided me with enough guidance on a good way to structure my app. Alloy provides a MVC structure to your code, but classic didn't completely prevent you from rolling your own or using one of the community libraries with MVC capabilities. In this respect I guess I would say it is more flexible to use classic over Alloy, because you can choose how to accomplish your structure, rather than fitting into Titanium Alloy's structure. That being said, I've never felt limited by Alloy.

How you develop in Titanium is your preference. There is no right answer to using Alloy or using classic. If one works better for you, use it. I feel that the structured approach to Alloy's separation of display and business logic provides me a structure that makes sense to me when developing an app.

I have not found that Alloy is less flexible than classic. Since you can use classic code in your Alloy project, you can pretty much do everything in Alloy that you can in classic. I'm sure that are some edge cases, that I haven't run into, where one might be easier than another when coding a specific type of application. It may be that classic is less flexible because I don't think you can use Alloy in your classic app. I don't believe the compiler would know how to build that.

Whenever I assess if I'm going to use a particular technology, I make a series of experimental mini programs to make sure all the capabilities are present for my application's requirements. If I feel that it doesn't fit or it is too difficult to reach those requirements, I don't use that technology. For example, when I switched to Alloy, I made sure the Ti.Paint library would still work. If it didn't I would still be using classic.

Just like classic, there are controls for Alloy. There is a pretty slick Alloy-based sliding menu module out there already. I use the Ti.Paint library, which existed before Alloy and isn't an Alloy specific module.

http://gitt.io/ is a decent starting point for finding Alloy modules/widgets.

index.xml

<Alloy>
    <Window id="win">
        <View id="content" />
    </Window>
</Alloy>

1) In your index.js file, you would have the following to use classic coding to manipulate an Alloy view.

index.js

var myview = Ti.UI.createView({
  backgroundColor: 'green'
});
$.content.add(myview);

2) I don't think you can use Alloy code in your classic project. As you mentioned before, it needs to do translation on the code and a classic project would likely skip that step in the process.

3) Are you asking if you can include or remove parts of the code based on if it is Android or IOS specific? You could probably do this with include/require statements strategically placed between if (Ti.Platform.osname == "android") statements to require in or not the code you want. If the code is for Android, require this one, if it is for IOS, require in that one.

4) Never attempted to check the performance between classic and Alloy-based projects. I think, since I switched and never noticed an issue that bothers me or my customers, I never put much thought into it. It is entirely possible that Alloy auto-generates code that is in some cases slower. I've never noticed it.

I feel that the efficiency I gain in using Alloy far outweigh that as an immediate concern. Plus, if I felt that I didn't like the way a particular control was created through Alloy, I could use the classic code and define that control myself having all the control of a definition from a classic project.