what is the Difference between alloy widgets and titanium modules.. ? and when to use what..
Alloy, a model-view-controller (MVC) framework for Titanium.where as modules in not mvc both can be used anywhere there is no much difference . but alloys is new MVC Framework .Where you can Devlop app more rapid than the later. Alloys are used to create some widgets and some other extra stuff . to make your App more Interactive,Fun ,and Good..
Alloy is a “component-oriented” application framework that enforces separation of concerns with a Model/View/Controller architecture. Let’s take a look at some of the core architectural concepts for Alloy.
you can folllow this link
I know it's old, but... this is the first hit when Googling "titanium modules widgets," so... I'm guessing a lot of people don't know.
Here is Appcelerator's explanation of modules:
http://docs.appcelerator.com/titanium/3.0/#!/guide/Using_Modules
And here is it's explanation of widgets:
http://docs.appcelerator.com/titanium/3.0/#!/guide/Alloy_Widgets
Biggest difference to me? Modules are old, widgets are new. Widgets include Alloy's XML and TSS structure. Use a module if you can't find a widget to your liking. Make widgets.
Related
Not sure it's the right question for this forum, but I couldn't find another place for it.
Our design team built their design system based on fluent ui libraries as described here. They downloaded the design from here.
Unfortunately, our engineering team is using Angular, so we naturally reached for the option of web component but found out to our surprise that the library is completely different - different set of components, abilities, and of course - a completely different design.
I thought that all fluentui platforms are supposed to be an implementation / interface of the same design. Why is this not the case? What am I missing?
Is there a way we can use the design described in here in Angular? (Except actually using the react library inside my Angular project).
Thanks for helping and very sorry if this question is inappropriate for this forum.
fluent web components integrated with angular.
take a look at documents
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
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:
how can I have old UI code run inside Alloy?
Can I have controls written for Alloy run in a "Classic" project?
Can "Classic" project also map out code not belonging to iOS/Android?
is there a difference in performance between Alloy projects and Classic projects? what about other flexibility issues?
Thanks
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
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.
I am coming from desktop dev background, wpf/SLight, and looking at switching to MVC application. Given I am absolutely rubbish at making stuff "pretty" what would be the best toolkit/widgets to invest in to help me on my way?
Looking for ease of use; UI look and feel; price?
I have experience with following control toolkit.
JQuery with JQuery UI : http://jqueryui.com/ Free and open source. Lot of community support, Lot of plugin to extend. you have more control over plugins and code. Very light. I have extensively use several mvic projects and I do recommend.
MVC controls toolkit. : http://mvccontrolstoolkit.codeplex.com/ - Free and open source code plex projects that you can use your mvc application.
DEvexprss mvc extension. http://mvc.devexpress.com/ : Commercial product with all necessary control for mvc application. Learning curve is bit high. But you can get very nice look for your application easily. Customization is difficult. They have good support from you technical issues. I have use for projects.
Kendo UI : http://www.kendoui.com/ commercial product from Telerik. I haven’t use in commrical project this but seems good.
One of the most popular UI frameworks is Twitter Bootstrap (FREE). It is built on top of jQuery and has lots of pretty widgets that are easy to use.
Another framework I like to use is KendoUI from Telerik (Price depends on what you need). It is very declarative so you simply need to add attributes to your html elements and it will take care of styling for you.
I'm not a javascript/css/html programmer. If anything I'm an objective-C, C#, C++, java programmer.
Looking at Dashcode there are features of the Utility project, Stacklayout project and some custom views that I'd like to combine into one webapp. This app would use 2 layers of stacklayout navigation, and use the infobutton to flip one of the views to get to the settings.
Is there a good way to combine dashcode projects? I notice the the generated "parts.js" file only contains dashcodePartSpecs for elements that Apple has included in that project. Can dashcode be used for non-trival projects? or this there a better way. (and yes I've already created an app store app, but Apple is trying to steal our subscription money.)
Cheers,
Gerry
There are similar to Dashcode tools that generate web "apps" Phonegap, iui, jqtouch, extjs and others.
They are essentially html/js/css frameworks from third parties. Dashcode does not get much attention from Apple where as both Phonegap and Extjs are actively supported. There is also an O-Reilly book covering Phonegap.