I want to implement a description page in an iPhone app. It's the final page in a drill-down navigation structure and needs to include a title, description, icon, large image, date and some buttons the user can click on to activate another application. The information comes from an external source and the title, description and image all vary in size.
I've seen various ways of doing this, such as laying out each piece of information inside table cells, and creating views that look like web pages. I've come up against layout problems using a standard UIView and UILabel because of the variable size content.
Looking at other apps, I think Facebook and the App Store have the most attractive layouts and handle variable size content well. I'd like to know what the easiest way of getting an attractive layout is, and also which way will produce the best (as in best looking) results.
a few things first you are in luck because a lot of the facebook UI stuff is available in the three20 project
http://github.com/joehewitt/three20/tree/master
there are a lot of templates that you can use in there that might solve all your problems, however documentation is a bit light on, and it may take some reverse engineering.
Also, you didn't mention the UIscrollview this might help you get a layout with more information on the page.
To get the best looking apps unfortunately you need to have the eye for detail (or pay someone who does) read through apples Human interface guidelines, as they seem to know what they are doing.
Related
I was asked by a client to make a "skinnable" app and I don't really know what that means.
I googled like crazy and I didn't found a clear answer or an example.
If anyone has a clue about this, any tip would be appreciated.
Thanks.
Generally this means the app will allow the user to choose different looks for the UI, each of which will have a different color scheme, feel, etc.
What I actually did with my project. I decided to use multiple storyboards to give me greater control over the entire UI and UX of each theme. I programmatically link them all together via a master storyboard that links them all together. That's what I did, and it works very very well. Performance is great, while still maintaining high level of fine grain control over each theme. You can even keep your Header and Implementation files the same for individual view controllers, just so as you keep the names the same on the storyboard.
So for instance, one of my apps that I'm working on called Jam-mout (A music player) has multiple high quality themes. (Image attached). Each theme has it's own storyboard.
For iPhone apps, where the majority of the GUI design is provided by the operating system, you could do it by setting custom Navigation bar background images, custom button graphics, and different fonts/sizes/weights and whitespace. Make sure you're working with a designer who's familiar with the iPhone GUI (if you're not working closely with a designer this is going to be a nightmare).
I recently put together an app for a client who wanted a heavily customised GUI: http://itunes.apple.com/us/app/gogoparis/id428497937?mt=8. A 'skinnable' app would have several sets like this, so the user could choose between several different overall styles. (I hope your client has an enormous design budget!)
my post here should help you get started:
What is the recommended method of styling an iOS app?
if you need live theme changes, each theme in this example could post notifications when the user selects another theme (or skin) - then you can update either the theme instance itself.
alternatively, you can create identifiers for themes which are mapped (NSCFDictionary) to a central theme factory. an example identifier for a specific view for use with the theme factory could be a string MONImageSelectorTableCellThemeIdentifier.
an example manager/factory which handles all theme loading and vends references to themes:
#interface MONThemeManager : NSObject
//...
- (MONTheme *)themeForCurrentlySelectedSkinForViewWithIdentifier:(NSString *)identifier;
//...
#end
beyond that, it's hard to answer your question in more detail without knowing your requirements. the implementation of skinning an app can range from very simple to very very complex. good luck.
Already some good answer here, but I'd add that if you use a ui toolkit such as Three20
you can skin everything using CSS as you might for web pages.
I do realise this is an old post, but I thought I'd share my penny on the matter:)
To make any Cocoa app skinnable you need you think of 3 aspects of the app:
1) Uniformity: By this I mean that on all windows, views (including buttons, text inputs etc...) you want to have a 'standard' that will apply throughout the app. This is the first thing you need to look at. Although iOS and OS X alike already have 'themes' as to put it i.e. Apples default way of shading and laying things out, you can override these (refer to the individual view / window etc... documentation.
2) Performance: With skinning etc... performance is always an issue when it comes to writing your own drawRect etc... methods. The code apple have in place for the 'default' is already optimised, so you need to keep a close eye on the performance of the app whilst you are doing this. Good examples are: Do I use an image with a gradient, or do I use NSGradient? Both of which have performance issues when it comes to rendering them, but it's a question of which is the better of the two
3) userDefaults: This is generally the area where you'd be getting your 'skin settings' pulled from. userDefaults is basically where you store all of the information which you generally set in a preference pane.
If I were you I'd look into the class reference of it:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/
Furthermore, here's a nifty example of using userDefaults:
http://mobile.tutsplus.com/tutorials/iphone/nsuserdefaults_iphone-sdk/
Hope this helps!
What is the best way to display lots of RichText (HTML formatted)
At the moment I'm working on an app for a forum. As you'd expect the posts on the site have lots of HTML formatting, lists, images bold text, colored text, etc...
Now there are several options I can think of (non of them ideal, please if you think of any other options post them in the comments):
Custom Cells using NSAttributedString+HTML + DTAttributedTextView for each post?
Problems: I used the NSAttributedString+HTML categories in the app elsewhere and it was less then ideal, creating an NSAttributedString seems to be quite expensive (slow) even in small amounts.
For 10+ posts each of which may be the length of an entire article would be awful + although DTAttributedTextView supports the IMG html tag (an most tags) it doesn't support remote loading of images unless you specify their width and height in the img tag. And for a forum where an IMG tag could be a smiley (10*10) or a screenshot (640*960) there's no way to predict that.
(Since writing this NSAttributedString+HTML, which is now renamed DTCoreText, has added full support for <img> tags and improved greatly!)
Custom Cells with a UIWebView in them for each post?
This one I considered for quite a while, however when reading this blog post I realised a problem that would cause, Smooth scrolling. The idea of having a native application for a site is that it is better then using a simple UIWebView to view the sites mobile theme. If the app lags and is jerky while scrolling that is worse not better (also as I need to display images hiding the webview's like he suggests wouldn't work). Also UIWebView's need to be created on the main thread or they break.
Back to the UIWebView?
Annoyingly besides doing a pathetic cheat, (like in the iFans app) where you only display text and then if they click it a UIWebView loads with all the nice images etc..., the only option left seems to be to do what I think the TapaTalk app does and have the entire thread view as a UIWebView. This isn't too bad as it will probably have quite good performance and will allow me to possibly add user controlled themes etc.. but I find the idea of using a UIWebView in a websites native app repulsive.
Does anyone have any experience creating web powered app, like maybe a facebook client, forum app, or new site app which had to display content from the site (I don't really count a twitter client as it only has to deal with text & links in small amounts per post). Or any ideas on the best way to display RichText content in an iOS app?
Any idea's would have to deal with the lot:
Multi Coloured Text.
Right, Left & Center aligned text.
Images (of variable size).
Bold text.
Text of different sizes & fonts.
Underlines text.
YouTube Videos.
HTML tables.
Just in case the actual question wasn't very clear in all of that I'll sum it up:
"What is the best way to display lots of RichText (HTML formatted) content for a forum client app"
So if I am reading this right, you want the forum posts of a given topic to be cells of a UITableView and the cells need rich formatting?
Assuming this is correct, I imagine each post will take up a lot of the screen (large cell height). In this case, having a UIWebView as a subview might not be as bad performance-wise as you might think. UITableView reuses cells so really only the visible cells need be loaded into memory.
I'm also assuming you are able to access the forum via an API, right? In which case, you should be able to pre-load data immediately prior to loading the view and the UIWebViews will only be used for formatting. You can even load a CSS file from your app bundle when you loadHTMLString into your UIWebView so you're not loading that from a server every time.
All that being said, if you did have a lot of concurrently visible cells it might be a different story and I'd maybe consider only showing plain text in the UITableView index and displaying the rich formatting only when the user taps the cell to view the single post. This might also be better from a design standpoint as having a ton of differently formatted cells on screen could potentially end up looking a bit sloppy.
Also, this may be obvious (especially since you seem to be both performance and design conscious) but please don't use UIWebView for UI controls. Any time I see a UIWebView tab bar or fake navigation bar I cringe (ack, Netflix). For formatting though, a lot times it's the only way to fly if you're loading a lot of dynamic content from a server.
NSAttributedString+HTML already supports lazy loading of images. See the Demo that shows how to do that. It's reasonably fast but you want to hold of parsing the HTML for content that is not on screen.
It mostly depends on what UI you want to achieve. NSAS+HTML is meant for situations where you control the quality of the HTML (i.e. because you generate it yourself). There it affords you with an unprecedented level of control over the view hierarchy because you can embed your own custom views to show images.
In other cases where you cannot be sure about the quality of the HTML you have to use UIWebView and work around all of it's limitations, one being that it takes enormous amounts of RAM and it slow to show the contents. Also UIWebView is not thread-safe (because WebKit is not).
This is a question for iPhone development and I'm hopin someone can point me to the right direction on how i should go about implementing this.
I am trying to write a chat application that supports emoticons/smileys. Where the smiley/emoticon images are stored can be figured out later. I think few iphone applications out there are already doing this (i.e. skype + ebuddy(?)) but not sure what method they went for.
After searching around, there seems to be a few ways of doing this (i think):
bubble chat style which has been discussed before. UITableViewController with custom UITableViewCell. For emoticons, might have to do a whole bunch of calculations to determine where to stick a UIImageView for each emoticon.
Use UIWebView as the whole "window". Style it to look like bubble chat. Takes away any manual calculations on image smiley placements.
I have no idea what the performance is like for each of these two methods, how complex it can get etc, so any comments and guidance will help for sure. Cheers
If you use custom UITableViewCell, then I'd probably implement drawRect: instead of adding labels and images. One will probably take as long to implement as the other, but it will perform much better.
The UIWebView might be worth a short, although you will have to make sure that everything looks right there, too. Instead of using one big web page, I suggest simply throwing in a web view into each table view cell.
Personally I prefer the first approach, measuring and layout of text is not too complicated, but then I've never been the ultimate HTML guru.
I agree with #Eiko on making custom UITableViewCells, especially using drawRect instead of adding labels, images, etc.
If you used a UIWebView how would you handle updating it? A complete reload each time new text is sent? That seems like it will be a cause of issues. Once you get a long conversation reloading the entire UIWebView's contents will cause some flickering which isn't acceptable in my opinion. Also using a UIWebView would require you to have 2 complete copies of each conversation in memory. 1 as your backend data and 1 as the HTML. Where using a UITableView you have your backend data, and only enough of that will be duplicated that can fill 1 screen at a time.
First: No, none of the content should be loaded from the web. All content parts are shipped with the main bundle.
I have n images and mass of text (including lists). Instead of building all view parts programmatically in objective-c if was thinking of using an UIWebView and build "only" the HTML dynamically.
Does anything speaks against it?
How does UIWebView work with local content?
Links and resources welcome.
Thanks
I would not recommend using the WebView for building application UIs. It introduces many elements that may cripple the user experience. Well, it basically depends on the complexity of the UI.
I created an App UI in WebView myself, using JavaScript and all that advanced CSS animations/transforms that WebKit has to offer, but in the end it was not good for the consumer. My goal was to make the app skinnable, but if something goes wrong - for example in JS - the WebView is stuck, except you spend the time into building a WebView wrapper for your app that deals with this.
That said I, i don't know how complex your UI is going to be, but I would say using IB or building the UI in code with cocoa is still more efficient.
Regards, Erik
I've thought about using web views in these situations sometimes, but then decided against it. 99% of the time, it's better to design the screen in Interface Builder. That will be as fast as or faster than creating an HTML page, and will give you all the benefits of elements functioning as expected (text input for example) and the possibility of customizing things programmatically. But of course, in many scenarios a web view might be the way to go (in fact, several standard UI elements have underlying web views).
I have a probaly large list of images and want something like the photo app but with custom toolbar.
I wonder how do this. I see the sample of Apple http://developer.apple.com/iphone/library/samplecode/Scrolling/index.html but that not will work for a large set of images.
I have a product list and some of my customer need download as much as 12,000 products in the device (I have a solution for the PocketPC I'm porting to iPhone).
In this thread How make a view of thumbnails in landscape mode? somebody suggest is possible use a TableView, but then I'm not sure... mainly how hide the section caption then could be...
UPDATED correct the link
The "Scrolling" demo won't work as-is for a large image set, but some minor adjustments can easily fix that. The trick is to use UIScrollView delegate methods to load images on demand and then unload them after they disappear. For decent performance you'd want the central image and one or two on either side to be loaded-- meaning that you can extend that design to support as many images as you like but still never have more than 3-5 in memory at a time.
The Stackoverflow link you post doesn't actually mention table views, so I'm not sure what approach you have in mind there. If by "section caption" you're referring to section header and/or footer text, then just don't provide any. Table views don't have a default for this, so if you don't give one to a table view then it won't show one.