I publish .net web application to blackberries. In 9700 and lower versions, There is no problem, but after 9780, styles look very big in blackberry. Html table cell fonts are very big
I want to use different css file for versions greater than 9780, but How can I detect blackberry version?
I find this, but I cant detect 9780, anyone knows howe can I detect 9780 and greater versions?
var x= navigator.userAgent.toLowerCase();
var y = (x.indexOf("blackberry9") != -1);
And Im new to bbery, version 9 means bberry 9000 and greater, is it true?
Various blackberry models use different User-Agent formats. There are several different formats that you need to check for in order to handle the widest range of devices. Check this page for examples.
Related
Situation: I want to get a very simple J2ME mobile application developed that uses Persian language displaying the label and text, and this is to be installed on any mobile that runs J2ME (like nokia 1280).
Question: Is it possible to use Persian fonts and embed it in such a way that it is independent of mobile device (i.e. does not care if mobile has Persian language installed) or do we need to use png images as labels?
Standard MIDP2.1 and CLDC 1.1 doesn't have classes to let you use TTF fonts. The typical way of doing it, is to use a bitmap font. Bitmap fonts are fast to render, and lets you use a lot of colours (if you wish). The downside of bitmap fonts is that, in order to support multiple screen resolutions, you'll have create different sizes of the font.
http://mobilefonts.sourceforge.net/
But like any other platform, someone has of course developed a TTF library for JavaME (called TTME)
http://www.xiteapplet.de/
I remember checking out TTME some time back, and as expected TTF rendering is slow. (Because most JavaME enabled devices have lower-end CPU's and such).
My advice is to go for bitmap fonts or use individual PNG files for labels.
I have a blackberry application with lots of images that was build for pre-OS7 handsets. I have to make it up to date with the new screen sizes, and my 5Mb app will be almost twice as big, which means over the limit for it to work.
What is the best way to handle that in the BB Java Plug-in for Eclipse ?
I've come to the conclusion that i have 2 choices :
Including the new images as a cod (or is it jar?) library in my current project, but didn't manage to do that. Most of what i read was for the JDE anyway and i'd like to do that in Eclipse.
Have a second Bundle for new handsets, but how to do that without having 2 different projects ?
Downloading the new images on install seems to be another one, but it's not an option for this project.
Details and/or links appreciated, as i'm quite new to BB development.
Many thanks
From my point of view the better way is to use only the biggest possible images in the project and scale them down proportionally for every device at the runtime.
When you scale down an image its quality {almost} does not change. There are exceptions, sure. But in general this rule works.
Also you may use preprocessor to build different cod files for different devices with different screens.
You can keep bigger images and get rid of smaller ones. You can handle devices that has lower resolution via image scaling. This way your application becomes smaller.
According to me i suggest you that you have to make same app for only Blackberry OS 7.0 because it has different different resolution and if you manager your application for all Blackberry OS than your app will become larger size and it may be possibilities that we cant upload our app in Blackberry app world.
Remove all previous OS graphic and put into for only Blackberry OS 7 and upload it on market so OS 7.0 user download the latest app.
I recently discovered that the PDFs exported by the Fast Report's PDF export filter aren't displayed correctly in Mac OSX, iOS and Android devices.
Fast Report informed that their pdf implementation only support Windows and they can't say when the new implementation that they are working on will be available.
I also tried to use the Gnostice export filter, but their demo installer didn't work in Delphi XE and when I contacted them, they took 15 days to send me some attached dcus which also didn't work. So I'm searching for another option.
If you know or use a PDF export filter which works with Fast Report, please let me know.
November 2015: Fast Report now have PDF/A support, with this option enabled the PDFs are fine on all platforms.
October 2014 - Fast Report 5 still seems to generate "Windows-only" PDF. A production-ready solution for this problem would be a benefit for cross-platform developers, given that Fast Report is the report generator bundled with Delphi.
Here is a fresh example generated with the Fast Report 5 demo, displayed with Adobe Reader 11 on Android 4.4:
And on Windows:
Fast Report informed that their pdf implementation only support Windows and they can't say when the new implementation that they are working on will be available.
I'm not sure that should be taken literally, considering PDF is supposed to be a cross platform format. It more likely means they don't actually have the time, equipment or expertise to test with those platforms. The PDF export filter that I'm using is the one built into Fast Report! It surely has some bugs, but I managed to work around them. And I think that might also work for you: Start with a simple document that does export properly, start adding features until it brakes, then you know what brakes it and you'll know how to work around the problem.
From my experience, here's what got me into trouble:
Rounded corners in the PDF document didn't look like the ones in the Fast Report preview. My fix: Found a combination of settings that made the exported PDF look exactly like the preview document. For me rounded corners were just a cosmetic feature, and with cosmetics there's no "One Look"; The alternative worked just fine. This might actually be fixed in the most recent version, but I didn't bother changing the document to test.
Transparency issues and outline issues. When working with the Fast Report editor (and when looking at it's previews) it's easy to overlap objects. You don't see this because of the object opacity. When exporting to PDF overlapped objects somehow managed to "print" outlines, and it obviously looked ugly. My fix: pay closer attention to those objects, make sure they don't overlap or make sure they don't generate outlines if no outlines are supposed to be seen.
Also make sure you test using ADOBE Reader, on any of the given platforms. If it works with the Adobe reader but doesn't work with other readers, there might be a bug in the 3rd party reader!
Edit: Here (link) is a sample PDF document generated by my Fast Reports application. I have no idea what kinds of documents you generate, but in my book that's a mighty complex document. Notice the diagonal line that starts where the table data ends, notice the embedded images (bar code, stamp, signature).
I opened that document on the following mobile devices:
iPad, running iOS: The document renders 90% ok. Images are not rendered at all, but they're not important to my document (and that's very likely a problem with the iOS reader). All the fancy colored lines and rounded corners are properly rendered. Some text is not properly rendered, and I'm pretty sure that didn't render because the "box" that contains it is too small for the contents. That most likely happens because I didn't embed the TTF fonts into the PDF and the Apple font on iOS didn't perfectly match the Microsoft font that was used on Windows.
Samsung Galaxy S2, running Android 2.3: The document renders 100% correctly.
Samsung Something(??), running Windows Mobile 6.5 and the FoxReader: The document is totally gibberish: pictures showed up but the spacing between letters was messed so bad it's impossible to read. I blame the reader, it's not Acrobat and it probably wanted to be "smart". And it broke it's teeth in my text encoding, because my text is not English.
About the PDF format: A document is "PDF" if it conforms to the standard, here's some Wikipedia info on that. In theory a PDF document should render exactly the same way any way you look at it, but there are forces at play that might work against this:
Not all readers are "Adobe Acrobat". In theory they're all compatible, in practice they're most like not 100% compatible.
PDFs that don't embed fonts depend on the fonts available on the host system. If they're not the exact same fonts there's trouble ahead, because they might have slightly differing sizes. Since we're talking about PDF's that were generated on Windows and opened on iOS or Android, those are obviously different platforms and they're guaranteed to use different fonts (because fonts are licensed, and I doubt Microsoft will licence it's fonts to Apple. I also doubt Apple would want Microsoft fonts). One possible solution is embedding fonts, but that makes your PDF files significantly larger.
AFAIK you can export your Fast Report pages as metafiles (i.e. vectorial Windows format, which is in fact a raw serialization of GDI commands).
Then you could be able to render those metafiles into PDF using our Open Source SynPDF library. It works from Delphi 5 up to XE, is Unicode ready, can embed true type fonts, and even create PDF/A files.
It is also able to export metafiles included in reports as vectorial pictures (and not bitmaps), and could therefore highly increase the pdf quality and at the same time shrink its size.
See for instance how it can be used for QuickReport. A similar technical should be used with Fast Report.
The Gnostice support answered my e-mail which I reported that their trial installer didn't work and send me some tips about which could be the problem and I was able to install it.
The company I work for already bought me a license and I already replaced the Fast Report Export Filter, which was a task as simple as droping 2 components on the same Form as the frxReport Object and setting 2 or 3 properties.
Also, to export the report programatically was also 2 lines of code and the information was easily found in their FAQ.
In the end, based on the recomendations and after looking for other options just to find abandoned components which doesn't have any updates for years, the Gnostice eDocEngine was the best solution.
Just hope they make their installer a little more "Programmer Friendly" as if it had complained about the lack of Fast Report's units in the search path I would've been able to at least have an idea of what was going on, instead of just getting an error and blaming them for having a trial installer which didn't work.
After replacing the filter and generating the PDF's using the eDocEngine component, the PDFs now work the same in iOS, OSX and Android.
Here is my workaround solution. It's not an universal one, but helped me in my case.
The main idea: use in report font with small file size (I've found Arial-like font with cyrillic charset with size 57kb). So the exported files can be 100-200 kb.
Details is here:
http://dev-doc.blogspot.com/2013/03/fastreport-4-font-reading-and-huge-file.html
I use wPDF from WPcubed components, it's really a great product, good value for money
You can always install one of the PDF printers. These are in fact PDF convertors that install as windows printer. They work from any application including FastReprt components - just print on them.
I THINK I know the answer to this, but can't find any plain English to confirm it.
I am currently porting an Android app to blackberry. I've gotten over most problems, but ArrayLists are the one I'm stuck on, since they were only introduced in 1.5 .
Can anyone tell me if it is possible to develop for newer blackberry devices, while having java compliance set to 1.5?
I'm thinking that J2ME is the deciding factor with blackberry. So if that only supports 1.3, then EVERY app made for blackberry must be written in eclipse with a compliance level of 1.3 set, and any newer blackberrys would be the same, and therefore ArrayLists are impossible.
Can someone confirm this for me?
Thanks.
PS Would it be possible to create my own ArrayList class, with the angle brackets < > as well?
You have to use Java 1.4 compliance for BlackBerry because they use J2ME.
Use Vector for your dynamic list. You can't use Generics<>.
Is there a "BlackBerry UI" CSS/JS framework available for Blackberry - Similar to IUI for the iPhone?
Hosted over on Google Code http://code.google.com/p/iui/ there is a great open source library for providing a "standard" iPhone UI for web applications.
i.e. a JavaScript and CSS library to provide:
BlackBerry look and feel
Data Binding
Curved corners etc.
DOM utilities
Handle idiosyncrasies between browser versions
Considering the fact UI changes across blackberry hardware, I guess it's difficult to create the equivalent of what is found on iOS.
I'm referring you to this forum thread you already saw for sure: Is there a "BlackBerry UI" CSS/JS framework for BB's - Similar to IUI for the iPhone
In term of compatibility and usability, I guess slightly altering a jQuery Mobile's theme would be your best option if you want to find one that is open source (unlike Sencha for example).
BB OS 6 contains a modern Webkit browser so it's easier to use standard toolkits such as Sencha.
Besides using Jquery Mobile or Sencha, you could give a try to this (official it seems) library https://github.com/blackberry/bbUI.js
I would recommend against using jQuery Mobile on a BlackBerry app.
It's slow (especially on older/less powerful devices), bloated (lots of stuff you probably won't ever need), the UI doesn't align with BlackBerry guidelines whatsoever and it doesn't play well with focus-based navigation (which is important as some current devices still don't have a touch screen and some users prefer to navigate with the trackpad).
bbUI.js (https://github.com/tneil/bbUI.js) as mentioned by Max is an official library originally developed by someone at RIM and, while it's not without its flaws and limitations, after months of working on a large WebWorks project it is still the best choice I've found to get up and running quickly.
Alas, the OS 6 browser crashes at the mere hint of javascript load (most usually the case), slightly less from having too many tabs open (by "too many", the amouny ranges between two on the lower spec models like 9300 to 4 or 5 on the 9780). This is from my experiences. Perhaps my settings are wrong - I tend to like smaller text, Arial and set the encoding to UTF-8.
However, I have never had Opera crash on the same phones - despite having at least 5 to 10 tabs open and in the background.