blocks|key|98207|text|万一有人看到这个问题，需要一个答案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|98208|我还在Appcelerator+&A中发布了这个问题，在这里我得到了一些答案：http://developer.appcelerator.com/question/177739/appcelerator-titanium---alloy-vs-classic|offset|length|98209|我得到的答案是部分的，更多的信息可以在这里提出的一个问题中找到：http://developer.appcelerator.com/question/177542/classic-vs-alloy|98210|entityMap|0|LINK|mutability|MUTABLE|url|http://developer.appcelerator.com/question/177739/appcelerator-titanium---alloy-vs-classic|1|http://developer.appcelerator.com/question/177542/classic-vs-alloy^0|0|13|2I|0|0|W|1U|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

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

I have also posted this question in the Appcelerator Q&amp;A where I got some answers here: <a href="http://developer.appcelerator.com/question/177739/appcelerator-titanium---alloy-vs-classic" rel="nofollow">http://developer.appcelerator.com/question/177739/appcelerator-titanium---alloy-vs-classic</a>

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

blocks|key|189074|text|我觉得从经典转向钛合金对我来说是对的。我觉得传统的钛开发没有足够的结构，也没有提供足够的指导来构造我的应用程序。合金为您的代码提供了MVC结构，但是经典并没有完全阻止您滚动自己的代码或使用具有MVC功能的社区库。在这方面，我想我会说，使用经典的比合金更灵活，因为你可以选择如何完成你的结构，而不是适合钛合金的结构。话虽如此，我从未感到受到合金的限制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|189075|如何发展钛是你的喜好。没有正确的答案使用合金或使用经典。如果一个更适合你，就用它。我觉得用结构化的方法实现合金的显示和业务逻辑分离，为我提供了一种在开发应用程序时对我有意义的结构。|189076|我还没有发现合金比经典合金更不灵活。因为你可以在你的合金项目中使用经典代码，你可以用合金做所有你能用经典做的事情。我确信，这是一些我还没有遇到的边缘情况，在编写特定类型的应用程序时，其中一种可能比另一种更容易。这可能是经典不那么灵活，因为我不认为你可以在你的经典应用程序使用合金。我不相信编译器会知道如何构建它。|189077|每当我评估是否要使用特定的技术时，我就会制作一系列实验小程序，以确保所有的功能都满足我的应用程序的需求。如果我觉得它不合适，或者很难达到这些要求，我就不使用这种技术。例如，当我切换到合金时，我确保Ti.Paint库仍然工作。如果没有的话，我还是会用经典的。|189078|就像经典的一样，合金也有控制。有一个相当光滑的合金基滑动菜单模块已经存在。我使用Ti.Paint库，它存在于合金之前，不是合金特定的模块。|189079|http://gitt.io/是查找合金模块/小部件的良好起点。|offset|length|189080|index.xml|189081|<Alloy>
++++<Window+id="win">
++++++++<View+id="content"+/>
++++</Window>
</Alloy>|code-block|syntax|javascript|189082|1)在您的index.js文件中，您可以使用下面的经典代码来操作合金视图。|189083|index.js|189084|var+myview+=+Ti.UI.createView({
++backgroundColor:+'green'
});
$.content.add(myview);|189085|2)我不认为你能在你的经典项目中使用合金代码。正如您前面提到的，它需要对代码进行转换，一个经典的项目可能会跳过这个步骤。|189086|3)您是在询问是否可以根据具体的Android或IOS来包含或删除部分代码吗？您可能可以在if+(Ti.Platform.osname+==+"android")语句之间战略性地放置include/require语句来完成这一任务，以便在您想要的代码中或不需要您的代码。如果代码是为Android编写的，那么需要这个代码，如果是IOS代码，则需要在该代码中使用。|189087|4)从未尝试过检查经典项目和合金项目之间的性能。我想，因为我改变了，从来没有注意到一个问题困扰我或我的客户，我从来没有投入太多的想法。合金自动生成代码完全有可能在某些情况下速度较慢.我从来没注意到。|189088|我觉得我在使用合金所获得的效率远远超过了作为一个直接关注的问题。另外，如果我觉得我不喜欢通过合金创建特定控件的方式，我可以使用经典代码来定义该控件，并拥有来自一个经典项目的定义的所有控件。|189089|entityMap|0|LINK|mutability|MUTABLE|url|http://gitt.io/^0|0|0|0|0|0|0|F|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1J|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1K|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1L|8|@]|9|@$L|1M|M|1N|1|1O]]|A|$]]|$1|N|3|O|5|6|7|1P|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1Q|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|1R|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|R|7|1T|8|@]|9|@]|A|$S|T]]|$1|10|3|11|5|6|7|1U|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1V|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1W|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1X|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|19|$1A|$5|1B|1C|1D|A|$1E|1F]]]]

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. 

<a href="http://gitt.io/" rel="nofollow">http://gitt.io/</a> is a decent starting point for finding Alloy modules/widgets.

index.xml

<pre><code>&lt;Alloy&gt;
 &lt;Window id="win"&gt;
 &lt;View id="content" /&gt;
 &lt;/Window&gt;
&lt;/Alloy&gt;
</code></pre>

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

index.js

<pre><code>var myview = Ti.UI.createView({
 backgroundColor: 'green'
});
$.content.add(myview);
</code></pre>

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.

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 (<a href="https://github.com/jaraen/Ti.UX.Templates" rel="nofollow">https://github.com/jaraen/Ti.UX.Templates</a>) which is written for Alloy.

few other questions:

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

Thanks

Appcelerator Titanium - Alloy vs Classic

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我要开始一个新的钛项目了。到目前为止，我所写的是现在被认为是“经典项目”(我一直在写钛应用程序从以前的合金)。我想知道在我的新项目中改用合金是否值得。我知道，合金在编译到java项目或objective项目之前，基本上会编译成“经典”钛代码。我也知道在“预编译”过程中有一个很大的优势，那就是在只与Android或iPh...

问钛合金与传统钛合金
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问钛合金与传统钛合金EN