Just wanted to know if Jquery mobile is stable enough to use for a live production enterprise mobile application.
There are many HTML5 frameworks out there, since our team has been using JQuery for quite some time we would prefer to use the Jquery mobile framework.
Its is still in Alpha stage but have read a lot of good reviews for the same, we also plan to build custom native apps for the Iphone, Android and Blackberry but would like to have an app that runs on all devices.
Regards,
Sheldon
It's good, but I'm not sure if it's good enough for a live production application.
I'm running a small website on it for a school project I'm doing and there's quite a lot of annoying bugs. Footers like to disappear at the most unexpected moments, I get a lot of 'jumpiness' where the page just jumps around and shows a black or white background-color, of which I don't know where it comes from. It's also fairly slow on my host, but that might just be because of the host and not because of the framework, however it's something you should probably test before going live with it.
That being said, the framework is easy to work with and if your team is good enough you might be able to hack your way through some of the bugs; it's easy to create a website with it which does look good, if you take the unexpected bugginess into account. Then again, I guess these little bugs are to be expected with an alpha release.
I personally wouldn't recommend it for a live production site, but it might be a personal thing and you should probably try it out for yourself. As far as other recommendations go, I have heard good things about Sencha Touch, but I haven't tried it myself.
EDIT: Some more information/comparisons here.
EDIT2: As far as a roadmap goes, they said they would release it when 1.0 hits. However, their release plan seems to be subject to change. Also check out this question: Is jQuery Mobile ready for production use?
Starbucks seems to think it's stable enough to work with. Disney, Audi, the BBC, and Barack Obama too.
Its good enough now to go live.
Its in 1.01 version now and quite stable
Seems like a good idea to hold off IMHO, it's alpha, there are lots of 'issues':
https://github.com/jquery/jquery-mobile/issues
I agree, jQM is still in alpha which means there are still enough bug/problems/features that are not up to par yet. But the jQM team is very quick to respond to Q&A's and is pushing for the first Beta release soon. IMHO (if time is not an option) I would start with jQM alpha if you think you're going to (in the end) use jQM for the final version of your webapp. I think getting the basic design and functionality can be done with the current release and just make the necessary updates for specific functionality when available. You can always keep track of the current (I think it's updated weekly) Status of what is being worked on/fixed/etc.. on the Blog: http://jquerymobile.com/blog/
I know there are other Mobile Frameworks out there but the scope of jQM on how many devices it should run on swayed me on selecting jQM as my framework
Related
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 was wondering that if I want to make apps for both iOS as well as Android is it worth it to get into learning the whole HTML-CSS-JavaScript route or should I learn their native SDKs?
Exactly how much will HTML5 be the future I guess Im wondering. Is it going to really replace the native mobile app?
I know noone has a crystal ball but Im just seeking input from more experienced/or more senior developers.
Much appreciated.
The reality is that HTML5 will never be a realistic replacement for native applications built in iOS and Android, as it is not powerful or robust enough to do so. Additionally, using HTML5 will only work for you if you intend to create very simple apps. Even then, you will run into problems.
Consider for example the Table view in iOS. It can be highly optimized for speed and interaction in a way that will always surpass a third-party, remote solution such as HTML5. Note that the table view is one of the simplest things you will do when creating an iOS app.
Additionally, knowing Java (Android) and Objective-C (iOS) will be beneficial to you in the long run in terms of your development career.
There is one real exception: if your app is going to be the native representation of a web app (ie. Facebook) then it does in fact make sense to go with a largely web approach (HTML5/Javascript/CSS). In fact, that is exactly what Facebook did. However, even Facebook experienced a very buggy and crash-prone existence on mobile devices for the better part of a year.
In conclusion, I know of no application developer who seriously considers HTML5 as a contender for the building of mobile applications (other than for heavily web-based apps with web-like functionality). The dream, of course, is that HTML5 will be a "silver bullet" or a "golden hammer" for developers, ushering in a brave new age in which we are able to focus on learning one set of technologies for all sorts of devices. Unfortunately, it is merely a dream. At least for now.
I want to make a site from scratch, and Im considering to use Flex to make a R.I.A instead of the standard approach (xhtml + css + some ajax).
The kind of site I want to make is something like e-bay, but less complicated.
But.. I know that 95%+ of the sites like that are built in the previous mentioned techs... so, what are the cons and pros if I want to make a pure Flex site?
Thx.
If you write an entire website in Flash, the entire website lives at one URL. (Short of mucking around with whatever Flash provides to let you offer deeper links.)
Whereas a website written in HTML, unless you go mad with your AJAX, lets people link to the stuff they’re actually interested in, like unicorns:
http://cgi.ebay.co.uk/DESPICABLE-ME-AGNES-Unicorn-Doll-Plush-Character-Doll-/180602861597?pt=LH_DefaultDomain_0&hash=item2a0cc4f81d#ht_1755wt_907
Or for a non-eBay example, Stack Overflow questions:
Flash for business web applications - why not?
HTML also has a pretty standard and understood user interface: links, and form controls. (Mainly links.)
Flash doesn't work on iPhone/iPad. End of story.
Other reasons: not a web standard, often quite slow, not good for SEO, etc.
It requires users to have a proprietary plugin which some users don't want and other users can't have (since isn't available for all platforms (iOS being a key example)).
It also has performance and stability issues on some platforms (OS X and Linux being prime candidates).
While some search engines have started to index Flash content (so long as it exposes the information), the results aren't as good as for content rich HTML sites.
You can do that simply using traditional xhtml + css + jQuery (or any JS framework if you want to increase UX). Flex won't do much in your scenario.
In my experience, performance is not a real issue unless you play video - one can write bad programs in JavaScript, too...
Your pros are mostly on the development side: You can have a great looking site quickly, and you can almost completely forget about browser incompatibilites.
You rely on the customers having the plugin installed, though, and you rely on Adobe's technology for development and playing of the content.
If this is not important to you, and you can afford to do without all iPhone and iPad users, accessibility and standards compliance... go for it!
Flex is good if you want to install as an application using Air. ebay actually has a RIA version, or at least they did for a while.
There are several concerns with a Flash site, some of which Adobe has addressed in the last couple of years.
One is accessibility. It is more difficult to make a Flash site accessible to the visually impaired, who use screenreaders.
Related, people like to be able to copy and paste content, as well as print. With standard web pages, the developer need do nothing to support this, it just works from the browser. With Flash, you'll have to take care to make your text content selectable, and I'm not sure a user could ever select a section of text + images. I've never done it, but I can only imagine that implementing printing ability in your Flash site would be nightmarish, at best.
Another is linking and addressability. For most sites, you can copy or at least get a link that you can share or save to get back to where you want to be. With Flash, you usually go to a single address and then the rest of of your experience happens inside the Flash "window" and the browser isn't actually navigating any pages. It is far more difficult to implement this ability in a Flash site.
A Flash site is usually very slow to load, especially the first time, and page load times are immeasurably important to a site's success.
Finally, you've perhaps heard the furor over the last couple of years about different vendors supporting or not supporting Flash in their products/devices. An all-flash site would be completely inaccessible on any iPhone or iPad, for example, which do not support Flash at all. Furthermore, some employers do not allow plugins like Flash to be installed on work machines, so you'd eliminate that portion of possible traffic, as well.
Nobody has yet mentioned Silverlight.?
I mostly agree with Jay's answer concerning accessibility, but as a further note would like to add that development in Flex/Flash vs HTML/CSS/JS could be more costly not only in terms of money but also for maintenance. Many Flex/Flash devs typically charge a higher price and their dev tools, which are necessary for compilation, usually aren't free, compared to HTML/CSS/JS devs, who often use freely available text editors.
I have a workmate with access to a very good IDE. He wants to use Microsoft FrontPage to write his jsps.
I know exactly what I want to say to him, but what would you say? I need a concise reason why a professional web app developer would never consider FrontPage.
It's an unnecessary abstraction for professional web developers, who need very tight control over the HTML and CSS generated.
It would be like rally car drivers using an automatic transmission. They need to know exactly what their car is going to do, and web developers need to know exactly how their code is going to act.
#1 reason:
FrontPage was discontinued in late 2006.
Personally, it bugs me seeing the extra bloat (unnecessary HTML structure, non-semantic use of HTML tags, embedding CSS directly in HTML) that Frontpage generates. I also dislike use of proprietary, non-standard HTML and CSS. Frontpage's code bloat is bad enough to have inspired such programs as Frontpage Code Cleaner. Here's another Stack Overflow question that deals with removing Frontpage bloat: FrontPage tags - Pain in da HTML.
You might also check out Why I do not use Frontpage by Greg Moreno.
Frontpage leads to bad habits for some of the same reasons Sarah Vessels lists. I used to use it myself. I was one of those who liked to design in design mode and refine in HTML. The problem was that switching between "design" and "html" views would cause FrontPage to change my precious HTML. And at some point I got fed up with it destroying my markup (something the newer tools are better about not doing).
When I began hand coding every site I worked on from scratch I learned so much more about HTML and CSS in general and how to make lightweight, efficient pages. And at that point I also realized that the markup FrontPage would generate was really old-fashioned with lots of tables and inline CSS. As I learned to do it right I also learned how to make my sites cross-browser compatible on the first try. In the end this allows me to design and build a better site, faster.
Professional web developers should really avoid Frontpage and use Microsoft Expression Web instead. It's the replacement for Frontpage and is fairly good, actually.
Frontpage itself has been discontinued. Using it simply as an HTML editor with syntax highlighting is a bit silly given how heavyweight it is.
That being said, if he's producing good code and delivering on time, it doesn't really matter what he uses.
It's intentionally dumbed-down
Great web developers build sites that:
Look good in all browsers
Degrade gracefully when Javascript or CSS or a plugin is not available
Have semantic HTML that makes sense to screen readers
Use AJAX, content compression, and caching to minimize bandwidth use
Have lovely, pixel-perfect graphics
If any GUI can do all that reliably, great. But I haven't seen it yet. And by the time you build one, the competition will be hand-coding capabilities that the GUI doesn't know about yet.
For one, FP isn't really supported anymore. The FP extensions honestly suck, they break quite often on the server side. But just as HTML editor, when the latest FP version is used and the settings are right (correct browser version and no server-side FP extensions), it's quite OK.
However (if staying on MS products), I'd rather use Visual Web Developer 2008 (o1 2010 when it gets out), it's free and has more recent technological support.
This is going off topic, but when FrontPage first came out, it was groundbreaking in how easy it was to create websites at a time when the web designer title was nowhere near fruition, but of course, FP has (de)volved into producing bloat.
The original company that created it was named Vermeer, after the Dutch painter and the story of how FP was built and how Vermeer got bought out by Microsoft is an interesting read, giving you insight into startups and Microsoft buyout tactics back then.
The same person who founded the company produced the movie, "No End in Sight", a documentary about the escalation into Iraq. Interesting segue, from software company to documentary movies.
Anyways, I think the name is Charles Ferguson. You can probably find a used version of the book on the cheap in Amazon. Definitely a worthwhile trip in the way back machine.
Because it's supposed to be catered to the crowd that isn't familiar at all with web development, mostly novices. To an experienced web developer it's fairly restrictive and limited, as is any WYSIWYG editor.
I haven't used it lately, but it used to rewrite a file with it's own garbage, even if you didn't save the file.
The same reason a professional artist doesn't use a coloring book. You're being paid to bring your skill and expertise into creating a product — using only FrontPage is essentially shirking that duty. I'm not saying it's never OK to touch it, but you need to take responsibility for the code you ultimately produce.
I personally haven't used Frontpage all that much, but I feel that you should really learn to use HTML and CSS and not rely on an application to do it for you. You really learn how things work and you have more control over what goes on.
It's Microsoft's
...the same company that brought you IE 6. I bet your site will work with IE 6, but will it work with Safari and Firefox and Opera equally well?
And if it doesn't, what are you going to do about it? You didn't want to dig into the code, remember?
Frontpage produces terrible code that won't be maintainable by other developers not using frontpage, meaning almost all web developers with common sense - especially since Frontpage got discontinued.
As mentioned - FrontPage became Expression Web. I hated FrontPage, but I think Expression Web is fantastic. I'm a programmer with deliverables, I don't have time to mess arround writing HTML code myself.
I suppose it depends what market your friend is in. If he wants to make shiny, glossed up websites with custom features & CSS - use a HTML/CSS syntax editor.
If he just wants to make quick, nice looking, clean corporate sites and have a high turn-over of generic sites, Expression Web is great. (The HTML isn't very 'pure' thought - but honestly what client would care?)
I'm looking for feedback on peoples experiences with developing sites that work across browsers. It seems to me there are at least two obvious ways to approach the task of making your site/webapp work across browser:
Constantly test across all supported browsers every step of the way; or
Pick a browser, get everything working in it as a reference implementation and then make all the other browsers match the reference implementation.
Each approach has an obvious drawback -- the problem with #1 is that you end up doing a lot of unnecessary work -- especially if you are developing a webapp that is going through a lot of iterations/prototyping/spikes etc. You will make a bunch of stuff work across browsers that will subsequently be discarded/removed.
The disadvantage to approach #2 is that while it makes the initial development much quicker and more painful it makes it much harder to figure out where some of the specific errors arose, especially for more complex issues -- whereas if you had been developing for all browsers at once you should catch it right away and know what change(s) introduced the problems.
A somewhat obvious third option would be a hybrid approach, but it seems to me that you would end up losing more by experiencing both of the problems with #1 and #2 than you would gain from the benefits of doing both.
What have you found to be the most effective way(s) to approach this challenge?
I’ve found that if you get too deep into developing a website without looking at other browsers you’ll quickly get to a place that is too much of a headache to debug. I consistently open my web pages in all the browsers I care about.
I strongly suggest you verify all browsers each time you make a large change to the site.
Make it work with all browsers up front. This will mean extra testing during development but will cause you less pain later. I find it's usually easier to diagnose problems if I've just developed the thing, rather than coming back later and trying to figure it out...along with a list of other issues.
It partly depends on whether you know it's going to have to work in all browsers up front. If you do, then you really are better off just making it cross-browser to begin with. You don't need to test that everything is 100% compliant every step of the way, but you should code toward that.
And really, it's not that hard, especially what with JS frameworks like jQuery and Dojo around that take care of the scutwork. If you find yourself continually battling one browser or another, you might want to reconsider your design, as you may have chosen to do things in a way that is inherently more difficult to do when cross-browser compatibility is important.
Well, you do #1, but you do it whilst greating a style guide. A litle bit like this: http://www.sitefromscratch.com/content/html-xhtml-css-testing.
So when designing a new site or design, you create a page containing the desired HTML for all the visual elements that will be used on your site. Ignore style for now, just use the HTML that makes the most sense.
Then you style it. Preferably, your style guide would be all on 1 page so it can be open in each browser you're supporting and all you need to do is hit refresh between changes, (avoid opting for several pages, because it will take you longer to inspect them all).
When you build your site, build from the style guide. If it's not in the style guide, add it and test it there first. If you discover a problem when building the site, (perhaps you didn't consider a particular element when it wrapped, for example), replicate and fix the problem in the style guide.
Here's the killer advantage: A new version of one of your supported browsers is released, what would you prefer to test, your entire site, or the style guide?
So that's the CSS taken care of, now you need to do that all over with your generic JS functions, if any.
I created an interface compatibility layer between the browser and my code - basically, I wrapped certain functionality and made the wrappers determine what javascript/html was needed.
As browsers change, you change this compatibility layer and you can leave the rest of your code alone.
If you have this layer in your architecture, the answer to your question becomes "whenever you want".
If you can get an enterprise lock-in then multiple browser support can become less of an issue, e.g. if your customers are all companies using Internet Explorer then why build the site to look good in Safari or Chrome?
If though you are making something for the general public then there is a hybrid approach I'd use which is that I use one browser to get all the functionality there and working and then test across browsers when I'm in that "pretifying" phase of the project. Initially the key is for it to work, then it has to look good.
I don't think I could see a logic to testing across all browsers as I initially fill out a form or do some other basic functionality as it could be a big productivity drain to test across at least a few browsers, e.g. IE 6 & 7, Firefox 2 and 3, Opera 9.5, Safari, and Chrome if one wants to get all the big boys, and at least a couple O/S as Safari on a Mac can be different than Safari on Windows, which is a lot of tests even for just one or two pages. On the other hand, near the end, this is when I can refactor my CSS and inline styling and make the code better for handing off for someone else to maintain, archive until a service pack project is planned, or keep some documents just in case something has to be done. Also, by waiting to clean things up, I can have more confidence in the final UI parts as these can evolve and change considerably over a short period of time.
I usually start out ensuring that all the HTML and controls that I write/use adhere to the specification.
Tools-->Options-->Text Editor-->HTML-->Validation-->Check Show Errors and choose your Target
This starts me out on a solid base. I functionally test new features in a single browser and then about once/twice a day test the full set of them across all browsers.
Using this approach, CSS and JS are the usual suspects when something isn't right, its rare that it's the actual HTML markup.
If you can do it right the first time. Do it then. It will probably never be right later.
Depends mostly on your experience, which could be applied to any programming activity including this one. If you know in advance what likely pitfalls you're going to have to avoid (eg. in cross-browser development, don't make it hard on yourself by trying to do something that is going to be a hassle in a different browser), then you can probably safely develop everything in one browser and then go in after it's done and tweak things to get it working everywhere.
I usually advise junior developers to keep all browsers open during development and to refresh each browser when making changes, but I myself tend to write everything with Firebug for support and then go back and see how it's doing in IE7 (etc) afterwards. Since I've been doing this for several years, most of the time I can predict what's going to be causing a headache and often immediately know where to look to fix it.
If you are new to Web Design/Development then getting things right in different browsers can be a chore at times.
However, it's really not that hard to get a website working in every major browser and coded towards the W3C standard. In my opinion EVERY designer/developer should do this out of principle, otherwise they are no better than they were in the IE years.
Develop cross-browser code, make sure it validates and never think about designing for one browser again.