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.
Related
It looks like UIWebView, but how do they implement that download progress bar and the section bar(very smooth scroll)...?
I have snooped around their logs, and I cannot guarantee that if the feed itself is a UIWebView, but it just so happened that when I went to the feed, a log message came up saying: "WebView loaded". This hints that they use a UIWebView for their feed.
I decided to do some research, and it seems I am not the only one who thinks that they might be using a UIWebView
http://www.lukew.com/ff/entry.asp?1499
If they are using a UIWebView, you should be able to easily identify its traffic in a proxy such as Charles or sniffing all network traffic using Wireshark.
After putting Instagram though Charles, I see that its calling http://instagram.com/api/v1/feed/popular/ which returns a set of JSON results. This leads me to believe it is definitely not a UIWebView and something created in native code (almost certainly a UITableView. As Andrew mentioned, the username UI elements behave exactly like UITableView section headers on a plain-style table.
I would say it is almost definitly a UITableView. Here's why I think this.
The profile picture of the poster is shown at the top while scrolling in the exact same manner that a UITableView shows section headers. (As I see you already noticed)
There is a slight delay when loading the next cell.
The scrolling is pretty smooth, but it would be smoother with continuous view (though it would take much more memory and the page would take longer to load).
What they probably do is pull information from the server and cache it in Core Data. They populate the table from this until you click refresh or close and open the app, at which point they reload the data and refresh the page. This includes comments, likes, descriptions and images.
The rest of it is choosing the right drawing methods to make the UITableViewCells as performant as possible. I won't go into this here, but there is a lot you can do to make the scrolling smooth.
#Neo
I've experienced the same gateway error as the screenshot from this article:
http://kennethormandy.com/journal/your-favourite-app-isnt-native
Safe to say their using UIWebView?
The way Instagram does this has been meticulously optimized, so what I'm about to say hardly scratches the surface of all of the methods they used to make their feed work.
They start by checking for a cache, and if one is not present, they call to server. Server returns the first meta of objects, which are cached/stored to disk.
Then they pre-allocate the height of the cell based on number & size of comments.
Now they setup their IB & UI methods, and everything (for the most part) executes normally.
The only other main thing is that they use pagination. So they're caching/saving to disk with each pagination.
Again, this is just the surface. There are a ton of hacks implemented into the feed in order to make it work so well. If you are planning to replicate this with a very similar model (content, comments, profile images, etc), it's going to take you some time to get it right.
That may seem like a broad question, but I'm talking specifically here about apps that display a lot of content (image plus some text) pulled from the net in separate cells, rows, etc. And where each of those cells can get loaded asynchronously (independently from all the others).
So for example, for iOS, is it too inefficient to use uiwebview for each of these cells? It seems like this would be a simple approach, but I'm not sure about the performance. "Pulse" has a bunch of cells on the page at one time, and on iPad this could really get to a large number. Is it better to do this using lower level techniques, or is using UIWebView a decent choice?
Update:Clarification-->
Just to clarify, I understand that the typical approach is to use UITableView and then create table cells to hold and show the data (although the "Pulse" UI may be more involved). What I'm getting at here is if those UITableViewCells could hold UIWebViews? So instead of putting a UIImageView and a UITextView in each cell and so forth, if it makes sense to just put UIWebViews there instead, and give them URLs (could pass a param to indicated the row) to load as cellForRowAtIndexPath is called or something.
Well, if you talk about the YouTube app, its not UIWebview. The common and better approach is to use UITableViews along with the custom UITableCells. As far as asynchronous loading of images is the concern, we implement "Lazy Loading" mechanism. And in this way, we are able to keep the performance benefit of native UIView intact. Whereas, in UIWebView, you would need to design the iphone based webpages which will cost you learn about Dashcode tool, or may be someother opensource css library, etc.
In short, UITableView, with Custom UITableCells, along with Lazy Loading Mechanism (achieved by some Threading Techniques) will do all the Magic for you.
Hope this answer will give you some better idea....
Do not use UIWebViews with UITableViews like that. There are far too many moving parts for a UITableView!
I wrote the NYTimes iPhone app while I worked there. I only ever used a UIwebView to display article content. This is because NYT articles and log post layout is extremely complicated and impracticle to replicate programmatically. (I did override some of the CSS in app)
The UITableView is a super high performance implementation for butter smooth high speed scrolling. UIWebViews are the opposite of that: heavy, slow and memory intensive. In fact web views actually run internal virtual machines and threads (for JavaScript, rendering, etc).
Keep in mind that table view cells are recycled very aggressively. The instant a cell scrolls off screen bottom it will, in gneral, be immediately reconfigured for use as the new cell that scrolls in from the top.
With a UITableView, you need to create VERY highly optimized custom UITableViewCells. The data displayed in the cells should be cached aggressively by you so that you don't need to recompute it or perform intensive layout calculations. Uncacheable information such as remote images should be loaded asynchronously (which might mean they show up much later).
On caching:
The NYT apps have a high performance caching system for images. The trick is to request the imge data as soon as its "needed", but to also preempt downloading images which were needed a second ago, but no longer. You also don't want to cancel partially downloaded images because that wastes the already consumed bandwidth. Check out NSOperationQueue. It has most of the levers needed to build such a system.
Another note: consider building a web app if your project may also be accessed via web or an android app.
I'm new to iPhone development, and I have a question on how to create a view for my application.
The view should display a problem (using formatted/syntax highlighted text), and multiple possible answers. The user should be able to click on an answer to validate it.
Currently, I am trying to use a UITableView embedding UIWebView as contentView. That allows me to display formatted text easily.
The problem is that it is a real pain to compute and adjust the height of the cells. I have to preload the webview, call sizeToFit, get its height, and update the cell accordingly. This process should be done for the problem and the answers (as they are HTML formatted text too).
It's such a pain that I am planning to switch to something else. I thought using only a big UIWebView and design everything in HTML. But I looked at some articles describing how to communicate between the HTML page and the ObjectiveC code. This seems to involve some awful tricks too...
So... that's it, I don't really know what I should do.
I guess some of you dealt with such things before, and would provide some greatly appreciated tips :)
The catch here is that the iPhone API does not yet support NSAttributedString so you can't just set the text to appear as you would like in a textview.
I saw one work around which essentially used individual UILabels to represent each attribute run. (Can't find the link now.) They used NSString UIKit extensions to calculate the position of the strings on the view and then used that to position the labels.
Another work around would be to draw the strings with their attributes to a UIImage and then just display the image. That would be the easiest solution I think.
In either case your going to have to basically recreate the data structure of an attributed string.
NSAttributedString does a lot of work for us. We really miss it when it is gone.
I'm taking a look at this widget, and it appears to be a UIPickerView, however I haven't seen anything provided by the iPhone SDK API that allows for horizontal scrolling only. Mostly it's all done vertically. Also there appears to be a custom graphic around this picker, so it might not be that either.
I'm curious if anyone is able to determine if this is indeed a UIPickerView or perhaps a hacked up UIScrollView? The widget is handy -- and I like its use. I found it in some random groceries app in the app store.
Here is the screenshot:
Thanks all.
I'd definitely use iCarousel library:
https://github.com/nicklockwood/iCarousel
The library is really well documented, the code is clean and maintained.
That is totally custom. You could indeed do something of the sort overlaying an UIImageView and an UIScrollView. I'd guess it's a 100% custom. As with all programming, there are many ways to do any single thing.
As I recently posted in response to this question, a class for an iOS horizontal picker control (STHorizontalPicker) has just been posted on GitHub. It's nowhere near as sophisticated as UIPickerView, but it provides the basic functionality for picking numeric values and the underlying foundation is probably a good starting point for adding more sophisticated functionality (it's a UIScrollView containing a UIView with multiple CATextLayers for the markers).
It was designed to be used in UITableCellViews and currently looks like this:
This website has source code for a picker that is aligned horizontally without subclassing it.
That definitely looks like a custom component. I'd suggest getting the .app file off your iPhone, opening up the bundle, and looking to see if there's a xib file for that interface. You may get lucky and find the component sitting in there. My guess is that it's a subclass of UIScrollView, but of course there's no way I could be sure of that without personally knowing the developer or the codebase.
You will recognize pickers by their giant screen-gobbling footprint :-) This is most likely a horizontal UIScrollView with a series of fixed-width labels (or images). The tricky bit is to have the bezel on top with a transparent center pass touches back to the underlying scroll view. Or you can take the easy way out and overlay four image strips (for each edge) and leave the middle open so touch events go directly to the scroller.
It's a custom control, but it's really not that hard to build.
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.