I'm currently scoping out a project for the iPad which is rather text and font heavy. There are many pages of styled text, which also need custom fonts. I have toyed with the idea of simply rendering PDF or PNG files on-screen, but I think we need to be able to dynamically repaginate the text.
We've used UIWebView in a previous project quite successfully, however there are a few things I don't like about it... Firstly, you have to hide all the silly drop shadow elements to stop them showing when the user scrolls beyond the bounds, and we had to add some JavaScript to find out actually when a page had fully loaded. Overall, the experience seemed a bit clunky, as well as worrying if the project could potentially break if Apple decided to update the subviews...
The other thing we've been looking at is Core Text, which looks very powerful. The only worry with this is that it appears to be a rather steep learning curve for us since we've mainly been working in UIKit (with a bit of Core Graphics). I couldn't even work out how to change the size of the font after a morning's work.
Are there any other alternatives*? Should I stick with Core Text? Is there any way of using UITextView with multiple fonts and styles?
Thanks!
:-Joe
EDIT: *by alternatives, I am really looking for built-in iPhone SDK alternatives only please... I would rather not mess with third party frameworks because I don't have the time... Thanks :)
You could use Pango, which uses CoreText when on iOS.
Related
I have lots of views - sub classes (UILabel, UIVIew, UIButton etc) using core graphics (within drawrect).
These show fine within normal interface builder.
However they do not show in the preview assistant editor for the storyboard (where you can see how views should look on actual devices).
I've been doing some research and found posts suggesting prepareForInterfaceBuilder should be used. However this doesn't show in preview for me.
I asked this question some years ago, IB_DESIGNABLE, having views show in preview? however I can't reproduce this, I'm not convinced it did work back then either.
I'm still following the same approach, with a framework and that link shows my implementation.
I know that prepareForInterfaceBuilder should be used to do something different, to show something basic. Therefore I believe that core graphics won't work.
However, I can't even get a simple change in background color to work in the preview, although it does work in normal interface builder.
I would like to know if this is a bug (that core graphics can not be used in preview) or still a limitation in xcode?
At the very least I'd like to do something simple (like a change in background color). I have a lot of views and an impossible task to make auto layout changes.
Previously I was producing lots of screen shots, different devices, languages etc (via automation) just so I could see my auto layout changes, which is really slow way to work.
I can verify this is a long standing bug. Apple doesn't care. Custom view be damned. All those dollars spent for more broken Xcode functionality.
Android?
Daniel
I am having a problem with iOS scrolling on an iPad. Every other platform tested works just fine. I love iOS, but hate it too. I was able to get the entire iframe contents scrolling within the parent, but there are two DIVs that are fixed that shouldn’t scroll within the iframe.
Before I spend a lot of time trying to work this out, I am just looking to leverage everyone’s experience for whether it, in fact, CAN be done. If it IS possible, then I will proceed to trying to work out a simple model and report it back for others. If experience shows that it can NOT be done, then you will all have saved me a lot of headache, not to mention time.
Here’s a drawing of what works on all other platforms but NOT iOS:
Simple question: Is it possible?
The simple answer is, in fact, YES.
I'm looking for a way to draw "Lines" above a UIWebView.
I have a UIWebView that display a PDF file, the user should be able to add "Lines" and "Sketches" (simple one color lines etc) for sure this could be done with a UIView on top of the UIWebView but i m running into 2 logical problems.
First can the UIView where the drawing is, be transparent beside the lines - so you can view the pdf through it?
How could i handle the zooming in the PDF, if a user zoom the WebView, the UIView have to zoom "with each other" - so the drawing stays at the same spot/zoom level?
Is there any other way to display a PDF and add drawings/annotations to it? Currently i m using a QLPreviewController where i see no way to add any kind of annotations?
Is three any best practice for this?
PSPDFKit handles this (and many other hard PDF problems) very well. Using a web view for this kind of problem is likely to have many little corner cases. Any commercial product that has non-trivial needs around PDFs should definitely start there. For open source projects I don't have a great answer beyond "yeah, PDFs are a pretty tough; good luck."
That said, here are some starting points that may help you.
You can turn off zooming with webView.scalesPageToFit = false
You can get the current zoom scale using webView.scrollView.zoomScale
I believe you can KVO observe zoomScale to track it while it changes, but you may only get the target value (which will cause you to lag).
You can disable zooming (scalesPageToFit) and then re-implement it yourself with a UIPinchGestureRecognizer and scrollView.setZoomScale(_:animated:). That way you could track the zoom changes better. You could also try to handle the animation yourself with a CABasicAnimation so that you could keep it in sync.
My experience with scroll views, web views, and PDF is that there are a lot of little funny interactions that will surprise you. Getting something that "kind of" works isn't that hard, but getting it really clean, smooth, and beautiful can be a nightmare. That's why I typically recommend PSPDFKit to clients. You'll generally spend much less on the license than on the custom development.
I'm in the process of developing an iPad-only survey-app using MonoTouch. With monotouch.dialog (mt.d) I found that building these interfaces can come quickly, which is awesome.
However... I also found that mt.d only does about 80% of what I want. Makes me wonder: should I invest in extending mt.d to my needs or should I choose something differently over mt.d?
Some of my requirements:
Radiogroups without transitions: I like the options to be
presented right away (there's more than enough space on the iPad
screen)
A rating UI control, such as
http://www.cocoacontrols.com/platforms/ios/controls/dyrateview
Mixed radiogroups: like 3 predefined elements and a fourth which
allows for manually added content
What are your thoughts on this? Can this be done easily (I'm a trained programmer, but quite new to both C# and iOS development)? Do you guys know of any online repositories of custom UI components with C#/MonoTouch bindings?
Thanks a lot!
This is of course a subjective opinion, but my take on it is that if you believe you can do your UI in UITableView (which MonoTouch.Dialog is based on), then you should go for MonoTouch.Dialog. If UITableView will not fit your needs, you should look for a different approach. MonoTouch.Dialog is quite flexible, and open-source, so if you need anything to be different you can just use the source code and modify it at will.
New to iOS, coming from the Java / Swing world, where I'm used to creating UIs programmatically, letting components size themselves and using various clever layout managers to arrange things.
It already seems clear that the iOS way is to make heavy use of Interface Builder, with a lot of fixed sizing and positioning. I'm not sure IB is ever going to come naturally, but I guess fixed layouts make sense given that you're working with limited space and a fixed window size.
It still seems like I'm writing a lot of boilerplate, though, and violating DRY, and so on.
Can somebody point me to a good primer on laying out iOS UIs, particularly programmatic UIs?
You don't really need to use IB to write MonoTouch apps. I almost never do. The CocoaTouch API is fairly simple and straightforward to develop on.
I haven't really found any writeup on UI development other than the apple documentation (which is really good, by the way, worthy reading), so here goes a couple of tips, based on my experience:
Inheritance is key to maintaining the code clean. You can inherit from basically any class in the API, like buttons, controllers, views, etc. Inherit and add your customizations in those classes. Don't shove everything in the AppDelegate like many examples show. You'll thank me later on.
Have I mentioned inheritance already?
The one thing iOS doesn't have is a layout manager, so if you're used to Java like you mentioned, this will sound a little strange. Different from what Java people think, this is not a big deal. UITableViews help tremendously with this (vide next point).
A lot of iphone apps are built on top of the UITableViewController, even apps that don't look like tables. It's a great framework to do anything related to scrolling. Learn to use it well. Almost anything that scrolls vertically is a UITVC. Follow the guidelines that define when you create and when you dispose cells and objects.
Be careful every time you add a Frame location in your control. Instead of setting hardcoded values, try using offsets from other locations (x+40, for example) whenever possible.
Make sure you add your views to the proper container as necessary. For example, if you're adding a global "Loading" view, add it to the Window object, while if you're adding a image on the left side of a table cell, use the ContentView. iOS changes those special views automatically all the time (resizing screen to fit "on call" bar at top, or rotating phone).
Miguel de Icaza has created a great framework for managing forms and tables, called MonoTouch Dialog. Take a look, and enjoy.