I am having an absolute nightmare trying to build anything of value with Sencha Touch. The docs seem to describe everything in bits in pieces without every tying everything together..
One of my key gripes is that I don't understand how anything is loaded into the browser.. If I simply define an Ext.List in index.js within this method:
Ext.setup({
onReady: function() {
}
})
Then that Ext.List is loaded into the browser for some reason. If I define multiple objects in that method, how does it know which to put into the browser? Furthermore, when I extend Ext.List and put that in the above method, nothing happens. What's going on?
Better yet, where I can find good documentation that explains how this framework works? I've pored over everything on the Sencha Touch site, including the tutorials, and all of it is horribly incomplete.
It does seem confusing at first. What's important to understand is that Sencha Touch different from jQTouch or jQuery Mobile in that you create your interface in a completely programmatic way, os there's no defining the UI in a HTML file or anything like it. The framework is written much more in the tradition of classic widget set's, QT for example. This style isn't something traditional web developers are used to, but I'd actually say the documentation is quite complete. It's just not written in a style familiar to web developers.
This is how it works: one component needs to have an attribute fullscreen: true set on it. This component becomes the root, and all other visible UI components are added to this component using the .add() method. But there all defined in Javascript. That's the most crucial thing to remember.
You have probably already found it, but the main documentation repository is the API documentation (here). If you're going to get anywhere you will have to get used to reading stuff from here quite a lot. Important facts here is that everything in the UI inherits from the Component class, and that Panel is probably
When I was getting started, I found this page a little bit better for starting. I especially recommend Drew Neil's excellent screen casts on panels.
I think this has a lot to do with the fact that Sencha Touch is still a young library, and that it has it's roots in the highly programmatic and OO-centric Ext.js framework. Taking some time to really learn the fundamentals of Ext.js probably helps a lot in the long run when trying to get going with Sencha Touch (tip: Observable is the most important class).
So sorry, you're right that the documentation isn't very friendly. But the UI you get from Sencha Touch still blows the competition out of the water when it comes to mobile interfaces, so I'd say that it's still worth it if you're really want the most slick mobile UI there is.
I recommend you to checkout the conference videos http://www.sencha.com/conference/videos specially the "Structuring Your Sencha Touch Application", I restarted an app from scratch following the MVC pattern explained in the video, in two days I got where I was before plus a ton of fixed bugs but most importantly now I really understand what I'm doing and why it was so hard to get things to work before using this standard pattern.
I found one of the best places to learn sencha touch is this 4 part series on building a simple SenchaTouch1.0 app :-
http://miamicoder.com/2011/writing-a-sencha-touch-application-part-1/
Follow it up with the MVC example :
http://miamicoder.com/2011/writing-a-sencha-touch-mvc-application/
Having completed the above tutorials gives you the comfort and confidence to approach SenchaTouch's own documentation, tutorials and screencasts.
Related
I've pretty much set my mind on using CreateJS to create an HTML5 game, but I also came across H5CGB, a boilerplate created specifically for creating HTML5 canvas games. It looks very thorough and I believe the developer when he says it would save me heaps of time writing code I would have had to write anyway.
However, looking at tutorials for both CreateJS and H5CGB, they seem to conflict quite a bit, at least in terms of how these specific tutorials implement their respective tools:
http://hub.tutsplus.com/tutorials/learn-createjs-by-building-an-html5-pong-game--active-11845
http://icecreamyou.github.io/HTML5-Canvas-Game-Boilerplate/docs/#!/guide/walkthrough
I'm basically just trying to understand how to integrate these two systems. For example, both come with their own preloader utility, so I'm not sure which to use and if they would cause issues or if it's just a redundancy resulting in unnecessarily longer loading times.
Has anyone had any experience working with these two tools together?
I believe you should probably just stick to using createJS because the two frameworks do have a lot of overlapping functionality. It wouldn't make sense to use both.
I think you should also check out other game specific frameworks like Crafty.js and possibly watch Google I/O Canvas to get a good idea on the total range of your options!
Crafty
http://craftyjs.com/
Google I/O
http://blog.sethladd.com/2011/05/source-code-slides-and-video-for-html5.html
Hope this helps and good luck learning canvas!
Shalom
I created H5CGB. (Just found this question today via the newly-released Github traffic stats.)
The biggest two reasons to use H5CGB are:
You do not have to learn any new APIs to start developing. H5CGB provides a bunch of scaffolding you can use to skip the boring stuff, but you won't get into trouble if you want to implement any part of your app yourself, and you probably can get going immediately just by editing main.js without even reading the documentation.
The code base is intended to be boilerplate, so you can use all the utilities and scaffolding H5CGB provides as a starting point and edit it if you want things to work differently.
This is in contrast to most other canvas libraries, which tend to be monolithic black boxes of no-touchiness with sparsely documented APIs.
I found this topic which says that MvvmCross has no way of detecting RequestClose or use pressing a back button: WP7 MVVMCross Detect RequestClose or BackKeyPressed inside ViewModels
backkeypressed-inside-viewmodels
Did anything change since May, 2012? Any reasons why this functionality isn't build into MvvmCross? I don't want to re-engineer the wheel it seems like this can be built very simply into Android, WP7, and iOS. If I don't find solution, I will end up building it.
The advice from before is still correct.
it seems like this can be built very simply into Android, WP7, and iOS
I may be wrong or missing something, but when in the past I've tried to build this, the simplicity seems to have become complicated quite quickly :(
While it may seem simple in one particular case, for a general framework there are numerous other cases to consider - e.g. when using pivots, tabs, popups, modals, split-views, etc - and in these multiple cases a standard approach may not be entirely universal.
iOS, in particular, sometimes makes this kind of detection much harder (especially in a general case where your UIViewController may or may not be inside a NavigationController).
What can be simpler is detecting and signalling the events for whether or not a view is visible - but even that doesn't seem to be entirely simple - there are cases in iOS where ViewDidDisappear will not get called - and besides, these events may simply not be what your app needs to respond to...
While it may feel like all you need is a wheel, the obvious fact is that there is no one universal wheel - wheels come in many different styles and sizes. I've now seen quite a lot of MvvmCross apps... and I've yet to work out what a standard app looks like. What's 'obviously' the right design and architecture in one app, can look totally different to the approach taken in others.
In general, I suspect that where individual apps need this kind of functionality then this will be in very well defined scenarios - e.g. with known view types inside a known presentation framework. In those cases, then I suspect implementing something just for that app scenario will be quite straight-forward for the app developer at the time. I also suspect that some of those scenarios can be shared between some apps - but I'm not sure that one code pattern will fit all - or even many.
I'm very, very happy to see users blog, github-post, or forum-talk about their experiences in this area when they write them. Blog posts like http://www.gregshackles.com/2012/11/returning-results-from-view-models-in-mvvmcross/ show how patterns can be applied and reused on top of Mvvm.
It may even be that out of such blog posts we find a way of getting more functionality inside the core mvvmcross (and other) libraries - but it's also important to me that we keep the core library as light, flexible and extensible as possible.
As people, like yourself, talk about their cross-platform mvvm experiences, I do my best to keep the links page up to date - http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html - that hopefully will help people share ideas, concepts and code.
I want to start a project and I am evaluating the architecture.
And now I am at point to decide the front end components.
I want to use HTML5 + Css3 + Javascript
On Javascript side I don't know what do you recommend. YUI or Backbone. I don't know how to evaluate what can be the best for me. The idea is to create a Browser web app and a Mobile app.
Do you recommend another framework for do that? Or some book, url or something that expose how to organize my front end?
This might be a bit late. But I will say this. I've looked through these so far:
Angular, Knockout, Backbone, YUI
And I read some other comments on Ember.
From what I've seen, Angular and Knockout take the same starting approach. They start out telling you how to interface with the front end. I do NOT like this. They give you a whole lot of rope to hang yourself with if you don't know how to design good architecture. Its completely up to you to build a proper MVC app with them.
From what I've seen of YUI, its EXTREMELY similar to Backbone, which is no surprise because YUI was INSPIRED by Backbone. I have spent a LOT of time looking at backbone and I'm very impressed with it. If you follow its principles and standards, it will encourage you to build a sound framework that won't leave you hanging later.
But I saw another commentor who actually actually moved from Backbone to YUI because he said YUI is more streamlined and all around better. I wouldn't be surprised if this is true. But I need to evaluate it further.
Many folks, including myself, agree that Ember, Knockback, and Angular are rather "heavy handed" in their approach. Like I said, they START with explaining how to interface with the HTML. Right out of the gate, they're wanting you to do things a certain way. This could be very problematic depending on your particular application.. OR it could make your particular application a piece of cake if it fits nicely in their approach!
My two cents!
Backbone is great for creating web apps, both for desktop and mobile. It's strongest point is that it's small and quite simple: you can actually read through the entire annotated source code. Backbone helps you structure your code in a maintainable way, which is the main benefit.
The downside of backbone is that it's not very beginner-friendly: setting up the collections, models and views can be quite challenging if you're not used to it. It also doesn't help you at all in rendering the views, which is a blessing and a curse: it's not as easy or helpful as a widget based framework, but it also doesn't get in your way, which is especially important when implementing the mobile app.
I would recommend you study the backbone todo-example ( http://documentcloud.github.com/backbone/#examples-todos ) to get an idea how the framework works.
I realize that some people think it is crazy to re-implement all the UI functionality of HTML in a canvas-based framework (and there are some stackoverflow questions that suggest this), but is anyone actually working on a library like this?
To clarify, the library would render all UI elements like edit boxes, labels, buttons, combo boxes, list views, etc. on the canvas directly. There would be no HTML or CSS.
I stumbled upon this idea today. Found the library Zebra. Haven't tried it out yet.
https://zebkit.org/
For web apps I think this makes perfect sense. HTML/CSS is just not good enough to create stable apps easily. The DOM and layouts are just too quirky and the performance too low.
What we need is something like Silverlight but without the plugin. Stable components and a great framework.
Canvas apps could be made just as accessible as html web apps. Probably more so even.
Perhaps WebGL is even better, its performance is definitely better than Canvas if done properly.
Thunderhead was a mozilla experiment built along with bespin (now skywriter).
From the project description:
Thunderhead is a Mozilla Labs experiment to explore a JavaScript-based
GUI toolkit that works with DOM elements and canvas to render
components.
The problem is accessibility, canvas just isn't.
I've just reviewed zebkit.com today. Amazing and absolutely not crazy, rather essential. Try running most DOM node trees on a mobile device and you will soon know this is true. Then in contrast run the Zebkit kitchen sink demo and be shocked. You might have to reconsider your projects approach.
Coming from Java to HTML5 I definitely see some nice OOP at play in the Zebkit API, it is needed to provide the simple canvas some powerful structure. Also I really like the JSON support, it acts much like a CSS format for the canvas. Using JSON this way fits well into the Web Component mindset and the practicality of HTML partials. There are a lot of goodies in this API.
In the end all ways of producing graphics for the Web render pixels anyways. Maybe we have just added to many abstractions between the logic we what to produce and the end screen to realize this fact. With Zebkit it feels like your almost working at the native level, plus it adds in all the graces of Javascript and JSON, sweet indeed. Plus your free to mix and match in DOM as desired.
Now there is Flutter's CanvasKit renderer. Google docs is moving to Canvas.
Does anybody know of any pre-canned gadget/widget management framework (along the lines of iGoogle etc) that I would be able to use on an ASP.NET MVC site (presumably loading divs via jQuery etc)?
In particular, I'd rather not write all the selection / location code if there is something decent already available. (I would expect to write the actual widgets / content etc myself...)
I was waiting to see if you got an answer on this one as it's something I'm interested in too. As you haven't, I'll tell you what I know (it's probably not so useful but it might get you started...)
I've used something based on the ExtJS portal demo in a previous project - there are some license costs involved depending on the deployment scenario though, and besides, it turned out to be quite slow and cumbersome, and rather tricky to customise - the default for the ext toolset is for the ui to be built entirely from javascript, not from markup, and while it was possible to coerce it into working on top of existing markup, it seemed more difficult than it needed to be. That aside, it worked well in the end, and with the paid version the support is very good.
I've also implemented a widget / portal screen based on jquery-ui sortable which worked really well - the basic implementation was very quick and easy but writing the code to save and load portal settings took more time than I would have liked.
If I were doing a similar project now, I think I'd evaluate this instead - it looks ok from a cursory glance and it's open source - it's built with jquery-ui sortable, so the core should be solid enough, and the slightly uneven animations on the demo version should be easy to sort out assuming it uses the standard jquery-ui sortable options. It has functionality to load/save portal settings too by the looks of it, so it should mean less hand coding that side of things.
I have used Telerik RadDock in the past and found it to be pretty good. It renders in divs and is relatively easy to style.
It doesn't cost too much if you are using it commercially.
http://demos.telerik.com/aspnet-ajax/dock/examples/overview/defaultcs.aspx
http://net.tutsplus.com/tutorials/javascript-ajax/inettuts/
This guy put together a great tutorial on implementing a iGoogle like drag/drop widget interface. Even links to a working example.