I am spec'ing out an iOS app and there is a piece that is a run-on section that will need to scroll. I was thinking of doing it as a UIScrollView (have never used one but seems logical) but it sounds like the contentSize always needs to be calculated. This could be extremely variable in this case (UGC images etc...). Is this correct? Or is there a legitimate workaround? If not, would a UIWebView be the better solution?
The app functionality would be like a FB feed or Instagram. Is it known what they use (FB looks like UIWebView to me).
thx
Actually it depends on what you are trying to achieve. If you use the web view you will have to generate html code to feed it and if you have buttons, you probably have to generate more html/css/js to make everything work. Using the scroll view is not a pain... Calculating the content size is easy... All your elements' height + some offset between them. Its bounds will remain always the same, you should only set the content size.
In my experience , I have the client-side web application development experience before iOS development .For the first time, I though UIWebView is pretty easier than UIScrollView because I can handle html/css/javascript as my wish.
But I found some problem with UIWebView Performance. If you have complex functional usability and large amount of data loading. So I try to implement with UIScrollView, Of course, It's quite not easy for me to create complex View with UIScrollView but when I've been familiar with the implement instruction. I think UIScrollView have a better performance then UIWebView ,especially complex layout and usability.
I recommend you to use both of them base on situation.
For some simply ViewController that just display an information with less complicate use, UIWebView is fine if you have familiar client-side web application development.
For some complex usability, It may not easy to implement with UIScrollView but It's quite OK for performance issue.
Related
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.
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 7 years ago.
Improve this question
So I'm new to iOS development and I found it easier to write the views all programmatically. So my views have UIViews, ScrollViews, UIButton, UILabel all created and positioned programmatically. (So I never used AutoLayouts).
I've now pretty much finished my app and want to make the iPad views, and realized maybe it was a bad idea to do it like this.
Is this bad practice or should I really be using auto layouts as much as I can?
If it's ok to do it how I'm doing it right now, what is the correct way to add different views for iOS and iPad? I've seen this answer below on how to find the device, is a simple if else statement sufficient? - iOS: How to determine the current iPhone/device model in Swift?
I am using programatic views in a live app and its awesome. A bunch of people I know us this as well.
Here is a little algorithm I use to choose between the two methods:
Are you building a fast app for a client or a hobby? Use storyboard with autolayout.
Are you building an open source project that will be used by many people? Use programatic UI
Are you building an app for the long run? (1+ year) Use programatic UI
Its also harder to make an app thats supposed to be rotated without autolayout. Because doing that with code takes much more work than autolayout. Most good apps dont use this feature anyways so I don't see much problem.
A good tip is never to use constants while writing programatic UI.
If you are going to make a button thats 100px in width, do not type in 100px anywhere in the code. Instead figure out the screen sizes and place the main views according to screen sizes. Then place the subviews or secondary views according to the position of the main views. If you do this correctly you will have more powerful multidevice layout support than autolayout.
Here is a little library I wrote, please inspect and play with the code on how I place the view: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift
Also here is a good article I like about this:
http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
This is only fine, If you have enough time, patience, good skill on calculations and relationship configurations between different UI elements.
However, using Auto Layout is pretty useful and low time consuming than manual calculations.
We can easily create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization with minimal effort.
Read Adopting Auto Layout,to implement the Auto Layout in your existing application
TL;DR
It depends
Longer version
Clearly one size does not fit all. AutoLayout is pretty powerful both in Interface Builder and code (be it visual language format, or simple constraint setting), but sometimes it just seems like you're "rubbing your right ear with your left hand" - that's when adding views programmatically comes in. But beware of not having it different in each view controller - you don't want to introduce too much complexity in your project, right?
I personally like using AutoLayout as much as I can and whenever I can't use it anymore, or the StoryBoard View would get too messed up with millions of constraints, I try to separate views into containers - have the container be resized by AutoLayout and have the subviews handled by code.
Example would be a custom Media Player - maybe I want to have two stripes below and above the video - I could have the video and two UIView extended stripes handled by the AutoLayout. But the subviews (controls) in the stripes themselves would be added by code. It gives me the control over my code but still it doesn't introduce too much complexity.
First of all - if you want to develop for iOS you have to learn Autolayout. There are already a lot of different devices with different resolutions and maybe will be even more in future.
Secondary - if you want to work effectively with IB you have to read guide / watch tutorial videos and have some practice. It could be difficult to start but then you will realize that IB is powerful, fast and often the best way to develop GUI. Often, but not always!
Code advantages:
Easy to copy-paste and reuse GUI. It could be critical if you have
several similar views or want to reuse some old code.
Easy to resolve merge conflicts and check commits.
Easier to make styles - like the same font for all labels depending on the country.
More powerful (there are things that could not be done with IB) so you have to use it sometimes.
IB advantages:
You can see your GUI during development for different resolutions/localizations so you do not have to compile and run a project on different devices/simulators to check is GUI ok or not. Also IB will show you warnings if you forget some Autolayout constraints or there are conflicts. Saves a lot of time if you have a complex GUI with non-trivial Autolayout constraints.
It is much easier to understand someones else code if it is developed in IB. Especially important for complex GUI - not so easy to find a required label or button in a few hundreds lines of code.
Small bonus - if you want to use a custom control developed via code you can make it IBInspectable and use it without problems in IB
Just to summarize - if you do not need IB benefits (for example GUI is quite simple and does not use Autolayout) developing GUI via code could be easier and faster. But in case you have to support different resolutions and/or you have hundreds lines of GUI code in each view controller I strongly recommend to try IB.
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.
I want to display a number of book and magazine covers in my app (similar to the shelf view in iBooks). So far I have implemented my own UIScrollView which displays the covers just fine - unfortunately due to performance problems, I'm forced to rewrite the whole view; however I'm sure that someone else has solved this already and probably made it an open source project (possibly part of a bigger UI toolkit/library?).
Unfortunately I didn't get far by consulting Google, Google Code and github. There are a lot of projects, most of them are examples and tests or abadoned.
So basically I'm looking for a UIScrollView based class with the following features:
Possibility to define a cell size (of the thumbnail/cover)
Automatic layout depending on available space
Lazy loading (using a delegate which provides the cell contents)
Basically a UITableView, but for book shelfs.
Any pointers to existing projects or toolkits are highly appreciated!
Thanks!
Checkout AQGridView. In trying it out I was able to get a basic grid going pretty quickly, and there is support for bookshelves (as seen in Kobo for iPad), but I don't know how hard that would be.
Edit: I just noticed that it doesn't handle large quantities of items too well (after about 40 cells it started slowing down). After reading the 'Future Directions' part of the GitHub page it seems that he's going to something about it someday so it might be helpful to keep an eye on it.
Ended up writing a simple UIScrollView based class which loads contents as needed. It's not too complex to do, but I guess it would be nice if something like this was implemented in the core APIs of iOS.
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.