Having decided to go with D3.js and SVG for visualizations it now looks like SVG will work fine in a desktop browser or native shell but I'm really perplexed by the drop in performance speed on the iOS mobile platform.
According to the following tests it now looks like SVG performance is getting better and not that far behind Canvas speeds, this is the good news:
http://bl.ocks.org/2647924
http://bl.ocks.org/2647922
The bad news is that if you run these tests in the Safari browser on the new iPad the speeds drop a lot for both SVG and Canvas. The terrible news is that if you run these tests in the new Chrome browser for the iPad the speeds drop much more.
I've read that Google is forced to use the UIWebview that is not accelerated by Apple's Nitro JavaScript engine. I've also read that Apple is pushing HTML5 but the demos only run in their own Safari browser.
What is the problem here anyways? The best target for my app is mobile yet even with great API's like D3.js and HTML5 standards like SVG performance is being pinched, is this just because Apple wants to hold up progress for their own agenda? Thats how it looks to me anyways. I'm not sure what these tests look like on Android? It would be great to know. If the tests would be positive maybe I will get rid of the iPad and just go with Android already.
The bottom line is that I'm just not sure if it is feasible to make my app using HTML5 technology due to these speed issues? I also have no interest in learning Objective-C as the future is going to HTML5. I believe in the web and its standards but it looks like they are being blocked. I'm very interested in knowing solutions to this dilemma.
iOS7 has notably bad performance animating SVG with JavaScript - although static SVG drawing is massively faster. We wrote a blog on the performance of the iOS7 release, which you can see for more gory details.
Update: iOS7.1 fixed the javascript animation performance problem. It's back to 50 fps
I found d3.js/SVG on my first gen iPad massively slower than running the same app on desktop browsers (FF/Chrome/IE 9+).
I wrote up the various improvements I attempted here: http://hivemindmap.blogspot.co.uk/2013/01/html5-and-interactive-graphs.html
Performance will usually be lower on mobile devices than on desktop kit. In general their hardware is less powerful (it's geared more towards low power consumption than outright speed) and they have a hell of a lot less RAM and storage to play with. Chrome on my desktop has multiple processors, 8gb RAM and a ludicrously powerful GPU at it's disposal. On my iPad it doesn't have anywhere near that level of power.
3rd party iOS applications (including Chrome) cannot use Nitro, that much is correct. I believe this is because Nitro is able to mark memory as executable and (for security reasons) 3rd party applications are not trusted to do that. Most HTML5 stuff will work in any browser on iOS (with the possible exception of Opera Mini). Canvas and SVG animation will be slower than in Safari because it's all driven by Javascript - again the lack of access to Nitro holds them back. This is no longer true: As of iOS 8 third party apps can now use the WKWebView framework which does have access to the same high speed javascript engine as Safari.
Native code will usually be faster because it's much closer to the hardware, hitting the display APIs directly, rather than going through the web stack.
The solution is usually to simplify everything. In the same way that native game developers had to massively reduce the complexity of their 3D games to make them work on iOS devices, so web developers have to reduce the complexity of their SVGs and canvas apps. Less stuff flying around the page means higher performance, in general.
There's a number of tricks you can do, and a lot of reading around the subject. Have a read of http://www.html5rocks.com/en/tutorials/canvas/performance/, http://www.html5gamedevs.com/tag/performance/, and the rest of Google. Personally I'd build a proof of concept and test it before completely abandoning the idea :)
This is kind of a dumb question but I've aware of classic style JDE development for Blackberry but I've never tried using WebWorks. BB website says that it's possible to build applications for both smartphones (OS 6.0+) and tablets - sounds fantastic, but what's the price?
Is here anyone using WebWorks on a daily basis and capable of describing pros and cons?
Thanks in advance
I would suggest using it if you build webOS applications before hand. It make porting to the blackberry a breeze.
Use WebWorks if you know html5, Css3 and javascript over Java and C++.
I haven't ran into any issues with the webWorks, ported two applications without running into any issues. Its your standard html5, css3 and javascript you love with blackberry APIs
WebWorks is a good development choice, particularly as it allows easy migration from earlier BB OSes to BB10. It's mostly standard web technologies (HTML5, CSS3, etc.) and the team seems focused on making it perform well (e.g. hardware accelerated WebGL graphics) while at the same time providing BlackBerry-specific APIs to make WebWork apps capable and with good UX (e.g. you can make it look like a native app).
For native apps, you should look into Cascades. This is a modern development environment with good tooling, accelerated graphics, and APIs for building snazzy apps. It's the one that will most be a "BlackBerry app".
AIR remains an option, but I would recommend WebWorks over AIR, as even Adobe is migrating from Flash to web technologies. Likewise, you can develop Android apps on BB10, but unless you are keen on Java programming, you will get more cross-platform support from WebWorks (or even AIR) so there's no particular reason to go the Android route.
WebWorks API is limited, for example it does not have socket, so you cannot port a VNC (UltaVNC, tightVNC ..) to it but you can do it with JDE.
For UI, WebWorks allowed me to write UI of acceptable quality quickly and easily, a thing that I have never succeeded with JDE.
Still on the UI side, I can make use of multi-touch (PlayBook), I don't think this one is possible with JDE.
So depending on your needs you should go either WebWorks or Native, having heard that Java may not be supported in BB10, and Air may not be future proof (Adobe favors HTML5 instead of Flash). Android appli has some lag on start up when it is run on PlayBook, some customers are sensitive to the initial even just one time slow response time.
I'm a huge proponent of Webworks. Ever since I've started using it, it quickly became the default option for my apps going forward. Especially for someone like me who is just writing a few apps on the side, I don't have the time to do it in c++.
The apps I'm writing revolve around home automation. They are client/server based from the get go.
Here's why I like it:
First and foremost, native API support. I can very easily create my own active frames, import invocation from other apps (think camera, stuff like that). I can export portions of my webworks app as an invocation card! Which means I can write say 3 unique apps (in this case home automation, lights, thermostat, security cameras). And I can very easily pull features from each app into the other. Maybe I want to turn my lights on in the living room, I can also import the camera card from my IPcam app and view the results, without having to add that code into my lights app and maintain two separate code lines.
Rapid design. Since I've been dabbling in html since I was a kid, it's now very easy for me to whip up an appealing UI in little time. Because web engines these days offer good performance in terms of graphics capability, I also can make apps that behave very fluid.
Considering the time to make something beautiful, it's hard for me to leave webworks and go for something in c++. Also the big plus is often these apps I'm making are intended for multiple devices, namely an app on my phone and being hosted on my personal website. By maintaining two slightly different css files, most of the time I need no code changes, just load a different css depending on if it's a phone or a pc. (Exactly what you'd do if you were developing a regular old website).
For that matter, I actually don't put my code on the device, I host all of my html and javascript, images etc on my server. The webworks app is just the config.xml pointing it's source to my server, and an icon. A glorified website bookmark on the homescreen, only difference is I can use native API and there's no browser bar in the app.
Also, this way I can still continue to edit the same single codeline on my server, and instantly apply changes to the in-browser app and the on-device app.
This is especially cool if you're designing an app where all of it's data is out in the "cloud", say you work for a publication and you want to write a magazine app which pulls content from your servers on the net.
Designing a web application with ASP.NET MVC I asked myself how can I also please those people using a smart phone, ipad, etc.. (everything thats touchable...) and not only a desktop/notebook with a browser.
How can I develop a better user experience.
I would be pleased to hear about technical advises concerning the asp.net mvc framework so I can later implement your suggestions concretely.
There are a few levels of friendlyness. You can start with the basic "does this site render well enough to be usable in a mobile browser?" This really should not be a problem for anything new that is using modern web standards but older sites could have problems. Corallary to this is "is my site a bandwidth hog that takes forever to render over 3g because each page is 14mb of animated GIFs and spaghetti HTML?" Or "does my site make mobile devices melt due to aggresive scripts?" Luckily this set is pretty easy to deal with -- modern websites tend to handle this pretty well by default.
The second level is "does this site do anything maddening from a touch perspective." The big thing that can clip you here is hover based menus -- there is no hover on a touch UI. The other common issue is using small links or buttons that one can't hit at least without zooming in to crazy levels. The solution here is testing -- some issues are obvious to all but you won't see some things until you are interacting without a mouse.
The final level is using a touch UI for fun and profit. If you make it this far, you are doing better than many web publishers in this day and age. What is involved here is using touch-friendly UI tools, such as jquery mobile, to handle swipe events and other touch features to make things work more like one expects with a touch UI. An easy example would be making an image carousel swipe-able rather than having to wait for the buttons.
Make the interface chunky - big icons are easy to click, text is very difficult to touch accurately. Set a minimum size for every element, at the very least as big as the individual keys on an iPhone/android's virtual keyboard and preferably much larger.
Ensure that the most relevant options are near the top, and after that the aim is simply to make it intuitive. Fewer menus are generally better.
Go through my tutorial ASP.NET MVC 4 Mobile Features
create mobile-specific views.
-use the HTML5 viewport attribute and adaptive rendering to improve display on mobile devices.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I wonder if I were to develop a mobile Web app (now, in two weeks, or in a month), which one should I go for? Which one would you mobile Web developers go for?
If jQM 1.0 were officially released today, I would most likely embrace it (as long as it actually delivers what it promises). Now that it is in alpha, I wonder whether it is worth to jump into it yet for a commercial grade project? Would Sencha Touch be a better alternative?
Sencha Touch is an application framework (you create your interface programmatically through Javascript) while jQuery Mobile is more of a mobile enhancement library (you write regular HTML for your content, then add jQuery mobile for transitions/animations). jQuery Mobile has an easier learning curve, but Sencha Touch can better simulate "native" apps.
The first question you need to ask yourself is what is the purpose of the application. If you want to release an application for sales on one of the retail outlets (iTunes, Andoid App store), or you need access to device specific functions that are not accessible via local APIs yet (accelerometer, camera, contacts, etc) then you should be thinking Native or one of the hybrid solutions (Appcelerator, PhoneGap, etc.).
If your audience is going to be more in the "mobile web" space, such as a mobile version of a corporate web desktop site, or intranet web application port, then you should be looking at Sencha Touch and jQuery Mobile. The decision between those two is really going to be based on you development experience and and what you feel more comfortable with. Sencha Touch is a VERY robust platform that has a Desktop (ExtJS) and mobile (Sencha Touch) that mirror each other so knowing one pretty much allows you to get up and running with the other. Also, Sencha has moved to an MVC model on the client which really helps to organize client side code and make it much more congruent with server-side development platforms.
The post above is actually incorrect, using the MVC pattern on the client combined with the historyUrl on your dispatch commands gives you the ability to use the browser back and forward buttons of the browser, so that is not exclusive to jQuery Mobile. Also, the Sencha Team's suite of products includes a Designer application that provides Designer which is a WYSIWYG editor that allows for the drag and drog creation of UIs. This company's roadmap has them in the process of updating the Designer app to allow for the drag and drop design of Touch mobile screens and application that will function with the MVC pattern. They are also getting ready to release a new version of the Sencha Command tool that will automatically generate entire MVC application structures for you in a matter of minutes, which you can then add the necessary custom code to round out your application. Lastly, the new SASS theming capabilities allow designers to use CSS3 and SASS config files along with variables and Mixins to generate cross-browser CSS style sheets for your application.
So, the decision of which way to go for the mobile web development question comes down to how comfortable you are with object oriented javascript. If you are very comfortable with it, then Sencha Touch is the way to go as it very extensible class system built into the core engine that can be customized to your hearts content...but if you have minimal experience with JS and you want the server to deliver your UI and don't mind seeing the Address bar drop down to move between pages (less web 2.0 looking), then jQueryMobile is the way to go.
It's pretty obvious that I am biased to Sencha Touch due to its well thought out class structure, extensibility, very active user community, web/mobile continuity, and constant improvement to the core framework and new tools that simplify development efforts. And not to mention that the Touch platform is more mature as jQM has not reached production mode yet.
I've been using jQuery mobile for a while now. It works well under Blackberry 6, iPhone, and Android.
I wrote an article about it here: jQuery mobile alpha
Though it's alpha, they are showing good progress. I've been looking into their development in github, seems like there's going to be cool stuff by early 2011.
UPDATE 2011-12-01 jQuery Mobile relased version 1.0, finally out of alpha. Read more about it here: http://jquerymobile.com/blog/2011/11/16/announcing-jquery-mobile-1-0/
If you're going to make a mobile version of a website, I am going to use jQuery Mobile. If you're going to make a “native” mobile application, I will be more likely use Sencha Touch.
http://tysonlloydcadenhead.com/blog/jquery-mobile-vs-sencha-touch
Sencha touch has lived longer than jquerymobile but I found that jquerymobile handles device back button much better than SenchaTouch.
I always consider back/history button handling is important in my apps, so I prefer jquerymobile.
I always consider myself a JavaScript programmer, but I like the fact that I rarely need to to type any JavaScript code when I use jquerymobile.
jquerymobile design is brilliant IMHO.
I am also in favor of sencha, JQM is really slow and failed to give an impression of an native app.
Praveen
why limit yourself...
Look into PhoneGap and Titanium Appcelerator
the make the comparison based on what you are trying to accomplish. I know Sencha Touch has a licensing fee and like you said jQM is not officially released yet.
This is a great time to be in the mobile space because there are so many viable options
I think jQuery mobile is easier to learn and seems to be very promising. Version 1.0 is not yet available, but its going to be a good product. I find it very attractive because it is based on jQuery - simplicity is the motto
Don't forget that there is also Dojo Toolkit Mobile. It looks nice, at least at first look and it is built on top of the proven and solid Dojo Toolkit core. http://dojotoolkit.org/features/mobile.
The Dojo Toolkit don't get too much audience recently but it looks like they made a lot of progress from the times it was a bit heavy, I think it is worth looking at it.
I've been trying out the sencha architect and to be honest ithas been a nightmare to get running.
My background is DotNet, html, javascript, VB, java and have been using eclipse etc for a while so am not a huge newbie with figuring out dependencys etc.
Here is what I have struck:
I went to the Sench site, downloaded Architect.
It then got me to download toolkit and sencha touch. I downlaoded exactly what was recommend / instructed by the help files / site.
I have Sencha Architect V2.1.0 Build 584., sencha-touch-2.0.1.1-commercial.zip, SenchaSDKTools-2.0.0-beta3-windows.exe
I also downloaded and installed a new java sdk / run time etc. The install has been done on a dead clean XP box (vmware). Web server is xampp.
Sencha does not recognise the SenchaSDKTools-2.0.0-beta3. You have to hack it using hard to find instructions. Even after hacking it the architect fails to use the proper SDK and gives error messages on deployment.
There have also been numerous errors to figure out along the way and issues where data just wont load even having followed instructions to the letter.
I have spent 11 hours getting to the point where the application will run properly without whinging but it wont deploy. It is bad enough learning a new tool / framework etc without the ide causing grief and the "instructional demos" leading you up the path.
There are lots of people getting the same errors all over.
After 15 hours of effort I am giving it up as a bad job and am returning to IBM XPages / PHP and Blueprint CSS with old fashioned, hand coded html5 / CSS3 and jquery / Ajax / JSon apps.
My reason for doing this: Application Architect keeps pushing you back to the command line. I love the command line, give me a bash shell and vi and I'm good to go. However for complex, multi file deplyoments such as mobile apps a good IDE is worth its weight in gold. Architect is not there yet. I keep needing to lift the hood and hack to get things working.
I originally looked at Sencha for a 12 year old who is interested in mobile apps and is looking for an ide to use. I tried it out - it is not suitable - even getting a hello world type app running is going to be too much for a newbie and the first app in the help files doesnt explain itself but has you copying code for pulling data from a web site you have to sign up for. (ccitybars app).
A big improvement for sencha will be when Architect works out of the box (possibly an installer with sdk, tools , touch and architect all in one) and the fisrt app -walk through is a simple hello world that then builds to entering data, saving data and then displaying data before going multi form.
I was faced with the same choice about half a year ago, then went for jQTouch instead of Sencha Touch, which I found to be extremely Javascript centered. I'm currently working on a port of that same project to jQuery Mobile and I think the transition will be much smoother than it would have been with a Sencha Touch project.
If you know basic PHP I strongly suggest jqmphp.com. Up and running in less than 3 days a whole online mobile based site to order food!
MoSync team has recently done an interesting comparison:
Which Mobile JavaScript framework is the best: jQuery Mobile, Sencha Touch, jQtouch, or Kendo UI?
http://www.codefessions.com/2012/04/mobile-javascript-frameworks-evaluation.html
http://www.codefessions.com/2012/04/which-mobile-javascript-framework-is.html
http://www.codefessions.com/2012/05/which-mobile-javascript-framework-is.html
jQueryMobile wins but huge boost in arm is because of licensing. I prefer jQueryMobile because I don't want someone(thing) else to write my markup, that way hacking becoming difficult (at least for me), however, I do have couple of HTML5 apps under my belt now, one each in jQM and Sencha Touch. Sencha Touch makes it smoother, very hard to learn though while jQM gets you started in a day, there are bug but you usually get around them because of amazing web community around this framework.
I've built a nice production app in a few days using Sencha Touch 2.0 and it's delivering as documented. And, it's FAST. There might be some bugs, but, when I've run into one (which, is rarely), there seemed to be many ways to approach a solution so that it's really not that relevant.
Sencha Touch looks great but it is difficult to use. The Sencha support forums offer minimal support. Sencha Touch 2.x is still in alpha is quite buggy
Sencha touch will be the best option is you are just starting because it is well documented and it has a community support. Also, with phonegap, you spend more time on the development and less on things about other mobile platforms. Phonegap will build the application for you , once you upload it to the builder .
Comparing the two is like comparing apples and grapes...though you want to develop mobile apps with both, the level of comfort with either depends entirely on you.
This chart might be helpful if you want to compare the features : http://www.markus-falk.com/mobile-frameworks-comparison-chart/
Sencha Touch based apps can only work on WebKit based browsers. JQueryMobile based apps can work on all mobile web browsers.
I think you can go ahead with JQueryMobile for next 2 to 3 years. I am expecting in 2-3 years all mobile browsers will be based on WebKit engine. Once all mobile browsers start supporting WebKit, move to the Sench Touch mainly because of very good quality user interface.
I suggest KendoUI
It is unbeatable and fast performance in a training of couple of days. Not to mention the fast update and new features and support for server side wrappers (asp.net, php, jsp). It is unique!
I have used both and they each have conditions where one is better suited then the other.
In my opinion you would use JQueryMobile when
1. You need a quick and light weight mobile implementation of an web application.
2. You have time constraints (definitely faster to learn and implement then Sencha Touch).
3. Native look and feel is not a requirement.
When making an extension to an existing web application where relatively simple functionalities have to be extended to extended to mobile (really fast and easy) I found JQM to be extremely useful and straight forward.
In my opinion you would use sencha when
1. You want a native look and feel
2. You want a higher degree of functionality on the mobile side (possible access to native api's through phone gap)
3. Targeting the latest smartphones (performance is impressive)
I'm looking to revamp our mobile site with something simple for phones below the ambiguous smart phone category and something a little more interesting for the phones above this category. I'm not interested in WAP/WML for this project. I'm building a ASP.Net 4 MCV 2 app and using MBDF
What I'd like to know is how best to define this differentiation when using MBDF? Screen size, Javascript, SpportsTouchScreen etc. are all in MBDF along with others but I'm not sure where to draw the line and where the data is most accurate for the broad number of devices.
What do those of you out there developing for this spread of hardware & software split on?
Thanks,
Denis
P.S. I've done my research on xHTML MP1.0 - 1.2 and the best practises for implementation to ensure broad coverage but I don't want to restrict the newer phones out there to what the base line can see.
I personally use simple mobile browser dedection script and limit max screen width to 240px. I also use simple AJAX and JavaScript calls too.
Above setup works fine for 90% of my visitors but my sites aren't business critical sites.
You can try http://wurfl.sourceforge.net/ but .net api is not as good as PHP one
So after a bit of testing myself I think I'm going to stick with testing if they support JavaScript and Touch using the MBDF. This line in the sand isn't perfect but it seems like the best out there to me.
Here is a neat little tutorial on Browser Detection using JavaScript
Browser Detection