This is a question and an answer :-)
For a long time now I tried using JQM with Hebrew. Getting the Hebrew letter is easy (utf-8 encoding...) , but the thing that didn't work was the alignment..
I mean switching the direction of the elements, the text alignment, positioning etc.
I found many questions about this, but few answers (and the ones I found didn't do a complete job).
Then I found this excellent article:
http://rtl-this.com/tutorial/rtling-hello-world-webpage-rtling
And I implemented it on the css file (more precisely on the one here: http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.css ).
That worked :-)
And if I'll figure out how to upload a file, I'll share :-)
I hope this will be useful.
You have to make changes to the JavaScript file as well to make sliders and flip switches work properly. Here is the full version of jQuery Mobile RTL I made.
I've recently tried to use jQuery mobile to develop an Arabic iOS application with RTL layout, and while jQuery Mobile doesn't support RTL yet, it wasn't too hard to hack the CSS to make it look and act like a proper RTL application.
But I ended up abandoning jQM altogether because, at least as of 1.0.1, the performance was simply unacceptable.
I tried a few hacks like removing all gradients (which helped a little) and disabling animation (which didn't), but it still took a good half a second for the UI to respond to user input.
I'm sure things will improve with the time, but for now at least jQuery Mobile is not an option for me. Its a shame too because it's declarative programming model is so deliciously easy to use.
Related
It's known, that jqm works with pages, that are screen wide.
Is it possible to implement in jqm & phonegap an app, that has pages wider than the screen and lets user horizontally scroll, like it's done in MS's Modern/Metro UI?
In case of MS Dynamics, for some reason, microsoft guys using native development tools on tablets to implement this Modern/Metro UI feature. In the same time they omitting this feature in their web client. I think it's not a coincidence, but the reason behind it is unclear to me.
I can tell you this,
Jquery, CSS and HTM5 are very Powerfull.
check out the CSS Metro ui Streamer demo
http://metroui.org.ua/streamer.html
http://metroui.org.ua/
I presume that's something similar you are after if not the one.
I know that we do not have a table\datagrid component for flex mobile apps. Currently I am developing an iPad app, in which I am using datagrid(though it says it's not optimized), which works quite well on iPad. There were no scrolling issues(which I felt would be present). But only problem is while switching the tabs below, it takes very long time to move from one tab to another(it just hangs for few seconds before moving). When i removed datagrid, it was working fine again. Switching was fast as expected.
Hence i do not want to really use datagrid. I came across an alternative which says to use List\DataGroup with itemrenderer. But not sure how we can display around 10 columns. We can use a list with a label item renderer and we can adjust the space between each column value, something like this:
data.firstColValue data.secondColValue .....
But with this, I will not get the datagrid's column width increasing\decreasing functionality, which is very much needed in this project.
Is there a way in which we can remove heavy functionality and retain only core functionality(which is needed here) from datagrid? If not, are there any other alternatives with which I can achieve desired result?
Apache Flex has accepted donation of Mobile Datagrid component, so you may expect to see the component baked into future release of Flex Framework.
What is the right way to design the page structure of a WebWorks app? I'm using jQuery-mobile as well.
A: Should all the pages be in a single HTML, each page being a:
<div data-role="page">...</div>
B: Should pages be separated in different HTML files linking to each other?
I am currently using approach A, but the app is a slow when transitioning from a page to another. I suspect one of the reasons is the size of the single HTML that includes all pages.
Also another issue I'm having is that pressing the physical "back" button on the phone exits the app which is another reason I'm doubting my approach in having all pages in one HTML.
A very opinionated answer: You're using the wrong framework. jQuery Mobile is extremely bloated and I've seen it perform poorly even on recent iOS devices, not to mention BlackBerry's not exactly very performant OS.
If you continue to go down the jQuery Mobile route, I would still recommend you have all your pages in a single HTML file, not least because the user experience on WebWorks is a bit sub-par when moving between separate HTML pages. For example, you'll get very noticeable "white flashes" when you follow a link to a different HTML file, especially on older/less powerful devices (although you can mitigate that a bit by setting a background colour for your rim:loadingScreen element in the config.xml). It's up to you to decide whether that is better or worse than the slow transitions in jQuery Mobile.
As for the back button, you can override the default behaviour by attaching an event handler to the back key like so (don't forget to have the blackberry.system.event feature enabled in your config.xml):
blackberry.system.event.onHardwareKey(blackberry.system.event.KEY_BACK, function() {
// Back key pressed, go back to previous screen
}
If you're still open to an alternative solution though, I highly recommend you give bbUI.js a try (https://github.com/tneil/bbUI.js) - it's a semi-official framework that looks a lot more at home on the BB than jQuery Mobile and is better optimised for the platform (e.g. allowing you to only load scripts that you need for the particular page you're showing at that very moment, working around some WebWorks/BB-specific issues, etc.) - combine it with Zepto (http://zeptojs.com/) which is a blazingly fast jQuery replacement and you'll end up with an app that is significantly less sluggish than a jQuery Mobile based one.
You can use which ever way suits your project best. For a large app, it's probably worth having a single "index.html" which then links off to several other pages. Can make editing your code easier as well.
There are about four implementations I can think of that are capable of loading SVG graphics into a Delphi application.
One of those, by Mattias Andersson, who is the author of FMX.Canvas.VPR
, works with FireMonkey, but he's not yet prepared to release the code.
A second one, by Martin Walter, works with the VCL, but developer has quit Delphi and has no plans to convert to FireMonkey.
A third one, part of the AGGPAS framework, works with the VCL, but no FireMonkey.
A fourth one is in development by Jason Southwell, but no date has been fixed yet.
So my question: what road to take if I want an SVG component today, without trying to reinvent the wheel a fifth (and probably more) time?
I'm Mattias Andersson -- the author of FMX.Canvas.VPR; I can say that I'm still actively working on the SVG solution. I guess once I have properly added support for gradients and text rendering then I can release a first beta version. I'm relying on TXMLDocument and that is a bit restrictive in what you are permitted to do (IMO), so I've had to invent some workarounds (maybe a better option would have been to implement my own XML class from scratch.) Also, I've had to do some run-time patching of the FireMonkey classes in order to make everything work correctly. The good part is that I'm actually implementing things according to the SVG interface specifications.
The SVG component I've been working on has been released as part of our Apesuite for Firemonkey.
http://arcana.sivv.com/apesuite
Getting involved with Mattias Andersson in the development is the best option:
FMX.Canvas.VPR by Mattias Andersson looks promising and VPR is proven to be an excellent project
No spoon-fed SVG FireMonkey component working out-of-the-box is available as of the time of posting (extensive web search made in general).
You could also consider using Chromiumembedded. Just load the svg in the embedded browser. You can then mix Delphi code with javascript, mix in html and css, etc.
This way, you can just leave it up to Chrome how to draw stuff fast (for example whether to employ gpu acceleration or not).
You'll get proper svg support, it's easy to integrate into your application, it's flexible, and there is lots of documentation and example code available online.
I'd like to use a non-standard web font to improve the appearance of my HTML.
Is it preferable to embed a web font or use something like sifr?
My understanding is sifr is a flash-based viewer for vector fonts but I've been reluctant to try it because it seems somewhat complicated.
There does not seem to be a lot of encouraging talk about web font embedding (because of legal issues) so maybe sifr is more of a standard way to do this?
Any feedback would be appreciated. Thanks.
Web fonts are supported in Safari 3.1, the upcoming Firefox 3.5 and the upcoming Opera 10. Internet Explore has supported a (different) format since IE4.
At this point, the biggest problems with the implementation in Safari, Firefox and Opera is that they require you to upload the original font file to your web server. For many fonts, this would constitute a violation of the license you received from the type foundry. Therefore, web fonts right now are not an appropriate solution if the type foundry has not given you permission to use them. However, there are freely licensed fonts available.
This leaves us with roughly three other options: images, Flash, and JavaScript-based solutions. Images are often preferable in that they have minimal impact with regards to browser quirks and performance, however dynamic image generation in, say, PHP often does not look as good as other solutions. You could of course manually create images in Photoshop, but that would usually defeat the purpose.
sIFR uses Flash to render the text, and is quite flexible in that you can select the text, change it dynamically, and have some control over the styling of nested HTML elements. Hoefler & Frere-Jones has given sIFR the OK, provided you pay for a server license and take all possible measures in limiting the sIFR Flash movie to your domain name.
Cufón is a purely JavaScript solution that has implemented its own rendering engine, which is insanely clever. At this point its not as flexible as sIFR, and its legal issues are still unclear.
That said, images, sIFR and Cufón are all hacks, and we need proper web fonts yesterday.
(Disclaimer: I'm the lead developer of sIFR, so I might be somewhat biased.)
You could also consider the JS alternative(s). However, for best cross browser compatibility you're better off using images and perhaps a background-image and text-indent CSS trick to replace static text with your images.
The technique I mentioned above (and others) can be read here: http://css-tricks.com/nine-techniques-for-css-image-replacement/
Something to consider:
For every visitor who sees your 'better looking' fonts, there are just as many who won't due to having an incompatible browser or disabling that feature. Having just the right font probably isn't the most valuable design change you could work on.
Written from my mobile browser which doesn't do embedded fonts.
Note that CSS3 Web Fonts module, which defines font embedding is still a Working Draft. Indeed, the practical support of font embedding isn't good. I'd say it's better to wait another 2-3 years.
Also worth nothing: TypeKit, a service that gives you a line of JavaScript to abstract all of this away.