I was doing a bit research and I came across this comment.
I have been working with Sencha products since Ext2. Throughout all
these years I have been rewriting my code numerous time just to adapt
to their freaking changing coding pattern.
From the troublesome Class.superclass.method.call() to the new
me.callParent(), till the recent adoption of initialize & removal of
initComponent in ST2, I would suggest you to go for the newest release
since whatever in the past will not be reuse again. Learn the new
coding style, don't waste time on the old structure. It won't help you
much, considering our web is changing very fast and ST1 and ST2 is
pretty disjoint as well.
While 1.1 is good old solid (much like Ext), v2 is much fun to work
with with the auto loader.
I'm ok with change, but I don't feel like revising my application every 6months or so.
My question is: how often does Sencha bring out a new version? (Can be EXTJS or Touch).
I did already try to find it on the website of Sencha but I think previous versions are banned to the dark ages or something.
There isn't a public road map available but like any software that is still growing, expect newer versions to be released. With the mobile space changing at a rapid pace, the Sencha team has to address those changes and meet the needs of their customers. It shouldn't be a deterrent from using Sencha products. In fact, with the release of ST2 and many adoptions from Ext JS4, they have not only simplified their path/direction but made it easier for us developers.
A very quick google for ext js wiki.
A very quick google for sencha touch wiki.
Related
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 have to evaluate Sencha Touch for building native Ipad html5 based apps. I was wondering which version should I start with v1.1 or v2.0?
I bought this book and created a simple html5 app (with Panels, proxies, MVC, toolbars) and integrated it with Java Spring and freemarker templates. All worked perfectly , the book was excellent and the onine documentation was great. This was with version v1.1.
Then Sencha announced that v2 is out with lot of improvements especially in performance. This made me think whether I should start again with 2.0 or just continue building on my prototype with v1.1 and wait till v2.0 gets more mature and has more documentation.
I have been working with Sencha products since Ext2. Throughout all these years I have been rewriting my code numerous time just to adapt to their freaking changing coding pattern.
From the troublesome Class.superclass.method.call() to the new me.callParent(), till the recent adoption of initialize & removal of initComponent in ST2, I would suggest you to go for the newest release since whatever in the past will not be reuse again. Learn the new coding style, don't waste time on the old structure. It won't help you much, considering our web is changing very fast and ST1 and ST2 is pretty disjoint as well.
While 1.1 is good old solid (much like Ext), v2 is much fun to work with with the auto loader.
I built two native Cordova (formerly PhoneGap) apps on iOS lately and the performance is pretty good so far.
IMHO, Sencha Touch 2 is easier to learn and work with. While it was just released as final, there are so many improvements and enhancements to the framework that even with a few bugs here and there I don't see why you wouldn't want to go this route. The documentation is pretty well baked, sporting lots of examples and guides. I think you'll find that you can accomplish quite more with ST2 than ST1. Cheers!
I would go with Sencha Touch 2 all the way. The API is a vast improvement over 1.1 and you are getting much better performance as well, ease of use and improved MVC structure.
Here is an App I recently built using Sencha Touch 2 and was featured in the Sencha touch app gallery: http://www.sencha.com/apps/flosports/
This app was also packaged to native for both iOS and Android using phonegap 1.4.1 and it worked pretty well.
We are in the middle of a relatively large project which uses ExtJS3 and have already invested ~4 man-years, using several plugins and we have written some plugins ourselfs. After a quick glance at ExtJS4, it seems that we would have a lot of work to do to migrate the project to ExtJS4. Are there any strong reasons to switch to ExtJS4? Currently, it seems to me that compatibility with future browsers (or the lack thereof) is the only one.
We're in similar situation and our conclusion was to wait a bit more as Ext 3 is doing it's job. We experienced many problems in our "test" migration and I would say that it's more a rewrite of the application than a migration :(. Also, our experience showed that Ext JS 4 has some performance problems, forms are a bit different, store cannot reject changes, it's bigger. There are some very good new features like the new class system, mixins, new charts, ...
We have upgraded our application to ExtJS4 without fail.We are happy to say that ExtJS4 is fast compare to ExtJS3.A new class system,mixins,plugin-free charts,focus management...etc.,. But if you want to upgrade you need to change a lot of code because class system and config options are changed.We have tested the performance of our application using ExtJS3 and ExtJS4,so as per our observation ExtJS4 is fast and it will not break.As per our observation,CSS selectors are also changed if you want to customize the component you can easily do the thing in ExtJS4.
We tried to migrate from ExtJS3 to ExtJS4 previous week. Unfortunately I must say it is like translate english to german. A lot of work. From our point of view more or less just the charting system is plus, minus - a lot of components that we use are not supported, a lot of css customization shoud be done, working code in ExtJS3 breaks easily and there is sometimes almost impossible to find an error.
Not an expert but personally I'd start new project with extjs4 but leave exiting project alone. The charting stuff is amazing in 4!
First time poster, long time reader. I searched and found no questions that answered this question. If I missed a thread somewhere I apologize.
I've been looking at doing some serious Cocoa development for a few years now. Even attended WWDC back about 5 years ago. With the App Stores making things easier for distribution I figured now is about as good of a time as any.
There's also been a fair amount of discussion regarding Vim lately and how it can increase productivity once you get a good handle on it. So I've purchased a couple books on Vim and bookmarked a dozen or two websites that I've seen lately.
My question is what plugins or whatever could I use with Vim to make developing with Cocoa/ObjC better?
I'm familiar with the Cocoa.vim plugin, but looking at the site there it hasn't been actively worked on for around 10 months. Before I get used to the features in that plugin I'd rather look at alternatives that have seen more development (if there are any).
That said, I'm interested in any and all tips regarding Vim and Cocoa/ObjC. Any easy ways to integrate them? I know you can set MacVim as the default editor in Xcode. What else might someone be able to do? Doing a Command-R to build&run would be great (Cocoa.vim claims to do this), but again, lack of development makes me cautious.
Thanks,
gks
Install the XVim plugin for Xcode. It gives Vim-like key bindings to Xcode.
I start using Vim one month ago, so I'm not a master but I'm quite familiar now.
As a Cocoa developer, I've been also looking to integrate things better, but until now, even with cocoa.vim I think Xcode still better for "application development". With this expression, I mean developing the easy part, that is logic like designing controllers.
You may agree with me. That's the easy part. Writing IBActions and so on. We don't need many editing commands to do that, and Xcode has a lot of advantages here. The auto-completion is phenomenal, it's intelligent and reads what you have been typing like no other. And can you imagine things with Xcode 4? Dragging an outlet from the interface directly into code is something that will not be available in Vim in a recent future.
Now, when it comes to writing models with heavy logic and C things, I stick with Vim.
You see, I still need to learn a lot. I'd love to have Vim running in the exact place of Xcode editor, but while that doesn't happens I have been trying to get the best from both worlds. Xcode is not all about editing text, it's about developing and debugging and many more, and it does these things in a fantastic way.
I'll let more experienced users continue…
I use vim for every text editing job except Cocoa. I agree with the things Sidyll says about the advantages of Xcode. Xcode is a pretty decent development environment with it's native editor.
I do have my Xcode set so that a double click brings up the file in Vim. I use this for things like fairly complex find and replace with regular expressions.
Another feature I'd like to see in Xcode is support for literate programing. In Haskell I can compile a file wih lhs suffix, and run the same file through Pandoc (or txt2tags) and get an HTML or PDF version. With Xcode I have to keep my development notes in a separate file.
I am looking to make a Mac version of one of my iPhone apps and was looking for a good ay to hit the ground running. I know how to code in Objective-c and Cocoa, and I know how to piece something together from scratch if I have to, but I am looking for an easier way.
Are there any open-source templates for coding Mac desktop applications that I might be able to pick up and use to get started off without reinventing the wheel?
EDIT:
I guess what I am looking for is an easy way to get started on an app that has the "iTunes Look and Feel". If there are some bare-bones version of this layout as some sort of template project, that would be great. Also, why has somebody down-voted this question? Have I asked something that is not appropriate for SO?
Apple includes lots of project templates with Xcode (vanilla application, document-based application, Core Data document-based application, etc.). I don't really know how much more you would want in a template. They're generally pretty good for getting you started, I think. If you're looking for something more than these offer out of a "template," maybe you could elaborate.
If you're just looking for a starting point for the interface, then check out BW Toolkit:
http://brandonwalkin.com/bwtoolkit/
He has some nice videos on his site showing how to create a Mail-like interface very quickly.
Besides the project templates included with Xcode, you should browse the application exmples in /Developer/Examples. Most of these examples are "full" applications that demonstrate one or more Cocoa-related concepts. Many could serve as the starting point for a similarly orriented app of your own.