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.
Related
has anyone built a profile using metro ui css, i need some inspiration for an online management system using metro and not able to come across much online. Thanks.
Not necessarily using the Metro UI CSS however these examples will hopefully provide inspiration that you could use to design your own.
Metro drew on clean typography and geometry - heavy use of the grid system and white-space. As Metro has matured it's moved on from the original designs, however Microsoft have continued to champion those original concepts - check out their guidelines for developing apps, and you might find exploring their products Windows Phone, Xbox One, and the Windows 10 redesign that got leaked - This one in-particular has quite a few ideas for profiles.
I first started reading about Metro from Long Zheng's blog - istartedsomething.com. And through him I discovered Mike Guss. Guss was one of the initial designers of the Metro language. He's recently updated his website and has some great Metro work on there:
http://mike-guss.com/#windows-phone
http://mike-guss.com/#xbox-one-1
Apparently there are quite a few "Metro" front-ends, inspiration found here: https://www.sitepoint.com/metro-bootstraps/
A couple examples here:
https://juliankay.com/development/the-metro-inspired-interface/
And more here:
https://www.google.co.uk/search?q=metro+inspired+user+interface
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.
So GWT best practices encourages one to use some flavour of MVP, which should in theory allow one to write different native views while sharing the presenter business logic.
This seems to be at the heart of the GWT spin off Google project http://code.google.com/p/j2objc/ which converts the non-UI part of your code to Objective-C, allowing you to write the rest natively in Objective-C.
So my question is: If this really hard part of the puzzle is being solved, how hard would it be to include an HTML5 mobile library (like MGWT or Touch4j [Sencha]) into this MVP pipeline to have the best of all worlds?
Having dabbled with http://code.google.com/p/playn/ , this clearly seems to be the blue-print for having a cross-plaftform build system (native android & html5 & java &...), but that project is geared for single screen drawing and event loop for game dynamics and doesn't allow for keyboard input and other typical mobile goodies.
It seems a shame that if so much of the problem has been solved, that it's not possible to go the extra mile. The answer to this question would be the best plan for actioning a solution, including such nigglies as which MVP structure to choose that would ease accommodation of the various widget libraries (GWTP vs MVP 2.1), and if the best approach is to start with the PlayN code base, and start to hack it.. what are the gotchas? Or if another path is chosen, why that one? and why would it be the best??
Thanx a lot. :-)
It is not clear whether your question is - evaluation options for multi-platform app development or mvp.
You can evaluate additional technology which are used with Sencha and GWT
1) mgwt
2) titanium
3) phonegap
You can also reference - Creating a mobile app using Google App Engine and GWT?
Note: PlayN as you mention is more of gaming platform and not suitable for business app.
MVP is definitely doable... and at times you may feel like its a lot of work, but it pays off in the end. Check out the Touch4j Kitchen Sink, which is written using MVP. You can take that down to the device with Cordova if you wish. The code is on GitHub:
https://github.com/emitrom/touch4jks
The repo is actively being worked on (we are updating ourselves to Touch4j 4.0) so it won't run out the gate, but at least you can see and follow the model :-)
Titanium4j is to Appcelerator's Titanium as Touch4j is to Sencha Touch. You may want to check that out as well. Titanium4j and Touch4j rely on GWT.
Cheers.
I've been looking over Sproutcore, Ember and Blossom and other competitive framework efforts (e.g. Sencha) to select for a HTML5 client side application project. The state, information, and documentation from these projects is a bit fragmented and in need of clarity, so I am presenting this to the community.
My project is to be a native-like HTML5 application with desktop level complexity in need of a complete application framework, that will work well on desktops and run with good speed on mobile devices with touch awareness. The widgets should be native-like (not web-like), but customizable so to be unique to the application.
Questions/framework Requirement:
Native vs. Web style Applications. Framework should make it easy to
build native-like user experiences with the ability to make a custom
native feel (not just wholly imitating mac/win/iOS). Some of the text
surrounding Ember indicates it is really meant for web-style apps - which given no
UI layer maybe goes without saying. Frameworks like Sencha, can it easily accommodate custom widgets?
Mobile Appropreatness. Framework should be appropreate for mobile devices and have facilities for touch input and
gestures.Several notes I've seen in my research indicate that Sproutcore and
Blossom aren't very appropreate for mobile, and that Ember is better
geared towards mobile (size?). It isn't clear whether the
touch/mobile libraries are very developed in Sproutcore/Blossom and if they will be supported it the
current state going forward. (and blossom compile to native is not acceptable). On the otherhand, Frameworks like Sencha, do they have the facility to work well on desktop as well as mobile?
Framework Completeness. The framework should be a fairly complete application framework, with desktop-like OO expectations and management for automatically and efficiently syncing, managing, and serializing the data model with the server. Not sure if there is much difference between Ember and Sproutcore, how do other efforts like Sencha stack up?
Your question covers a lot of ground. I will pick some quotes and answer them directly.
My project is to be a native-like HTML5 application with desktop level
complexity in need of a complete application framework
Ember.js specifically bills itself as a "web-style" framework, not a an RIA framework. That said, you can build anything you want, but you would be trailblazing.
Sproutcore bills itself as an RIA framework. You have complete control over the DOM, so if you can do it in the browser, you can do it in Sproutcore.
Ext-Js is also a good application framework for desktops (Sencha Touch is for Mobile). If you like the way its examples look, then its a good choice. You can of course customize the dom and write your own widgets.
Blossom is basically Sproutcore with a canvas based view layer. It just went into beta, so you would definitely be trailblazing if you went with it.
So, you can basically use any of the frameworks you mentioned for the RIA part of your enterprise. I would eliminate Ember.js simply because the framework itself purposes itself for web-style (e.g. twitter) as opposed to RIA (e.g. iCloud) apps, which is not what you want.
The widgets should be native-like (not web-like), but customizable so
to be unique to the application.
All three of your remaining options can do this. If you like Senchas widgets, its a good choice. I don't know if they are native enough for you. That said, with any of the remaining frameworks you can customize the DOM to your heart's content.
Mobile Appropreatness. Framework should be appropreate for mobile devices
This is a tough one. Sencha Touch (which is separate but similar to Ext-Js) is very popular and gets the job done. It is performant too; a non-trivial app ran fine on my original Droid (which surprised me).
Sproutcore is very heavy weight. It has mobile support (i.e. for touch events) but you need to very careful about the dom you create, so as not to overwhelm the browser. I wouldn't choose Sproutcore for mobile, although you could if you are very careful.
and blossom compile to native is not acceptable
That does not seem reasonable to me. To be clear, NONE of these frameworks run natively on mobile devices; they ALL run in the browser. Blossom comes closes as the canvas API is mapped directly to the native API, giving you a truly native app. The only way you could get closer would be to use objective-c/java for iOs and Android.
So basically, at this point your left with Sencha(Ext-Js) and Blossom. Blossom is still in Beta, you would be trailblazing if you tried it. Sencha is established, has great support (Blossom support is good on irc), and a large developer base.
So Sencha is the choice, unless you really want to be cutting edge, and take a little risk.
Troy. Indeed, ember can run with another view layer framework such as jQuery Mobile which can provide a "app-like" look and feel.There is a github project: https://github.com/LuisSala/emberjs-jqm. In my view, if you need very cool animation you can use blossom.If you want to build a app, SC or ember should be OK. I'll choose ember because it 's loosely coupled.
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.