I've a noobish question. How does tabbed browsing work? I mean that you save the current webView with it's content in an array and show it later.
like you can read here http://www.iphonedevsdk.com/forum/iphone-sdk-development/24521-please-need-help-webview.html I made few attempts but no luck so far.
as anyone a nice suggestion? Thanks in advance
Implementing a tabbed web browser is more of a design challenge than a pure programming challenge. You need to consider how the user will switch between different tabs. From a data structure perspective, you can store multiple instances of UIWebView in an array, as you mention.
From a design perspective, you should look at the way Apple implements their web browser. Their approach seems to be more of a multiple window system than a multiple tab system.
One thing to keep in mind, UIWebView's use a lot of RAM, so be careful keeping too many stored in memory.
PS: if you are interested in checking out a tutorial on UIWebView check out this tutorial
Related
I understand from threads in this forum and the Google GWT forum that in the GWT world you typically load just a single page and then what appears to a user to be a different page is just the same page with it's content being updated by user actions. A lot of posts imply that you develop your app as you would a desktop application. That sounds easy if you have done desktop development but I am coming from a pure Web services/ Servlets/ Struts background and want to see a very basic example that shows the proper way to implement a GWT app where you show a user a txt box and button and when they click the button, the view is replaced with 2 different components.
There are plenty of basic apps I have done and plenty of complex multipage type ones but I just one that takes me past the click a button to see a message type app to the next level.
Any links to such an example would be welcome
I recommend to study Activities & Places design pattern. It is the best approach, in my view, for large applications with multiple views. It provides a lot of important functionality "out of the box", like browser history management, support for tokens, efficient memory management, etc.
You may want to look into the Model-View-Presenter pattern (MVP). Using this pattern correctly will greatly decouple your application, allowing you to create views that are not only highly modular and disposable, but are very easy to swap out and change.
In fact, Google fully recommends the MVP pattern when developing GWT applications. They provide a full example and walkthrough of a MVP GWT application here, which I imagine is based off of a Google I/O presentation given on best GWT application architecture practices back in 2009.
I've been following this pattern with my latest GWT project and it's working out extremely well. It's very easy to add, remove and swap views.
We're beginning development work on a newsreader app which pulls stories from a RESTful API in XML format. Each story contains:
Html formatted text with links to external web pages (around 1000 words per story)
1 inline advert banner (640x100)
1-10 inline images (640x320 each)
The newsreader will load 10 stories at a time when opened. It needs to be robust and performant (smooth scrolling etc).
We're considering whether to display the stories using the native UIWebView or Three20 open source library but am not sure which is the best choice. UIWebView seems to have more flexible text formatting but Three20 sounds more robust and less prone to memory leaks.
I'd appreciate any advice anyone might have from their experiences.
Thanks!
Well, the answer is: Oh, it depends.
The three20 framework offers a lot of things that you would have to do on your own - if you need these offers. If you like URL-based navigation, this might be a plus for going with three20. You mentioned flexible text formatting, which you can achieve with both approaches. three20 allows you to subclass their classes, apply styles, ...
My advice: take a deeper look in the documentation, ask yourself, if you need more than one feature that three20 offers and decide then which way to go. As with all third party frameworks, you'll have to put some effort in making things work.
I am preparing an iPad app using, obviously, Objetive-C and wich tries to deploy Data Base stored content inside a view.
Now comes the problem, it will be a huge amount of records to be shown, each of them deployed inside some kind of "container" inside the view so that I was considering to make a page browser and in every page I go to change the view I apply.
Take for example, I show the first 5 items using example1.xib, for the next 5 example2.xip and so til getting to the page 10 and starting again with example1.xib.
My question is how this can be achieved? Maybe storing diferent view class based objects inside an array and alternating them or so...
Any help or hint would be greatly apreciated.
Cheers!
Always assume others have made similar apps before you. Perhaps not exactly the same ones as you, but doing similar things that you can learn from. The iPod and Spotify apps navigate large amounts of data using indexed, searchable TableViews. Go hunting on App Store for apps that have the same kind of functionality as yours, and test them out and grab what's good and discard what's bad about them.
My advice is to get hold of a nested tables example using the built in SQLite, and go from there. I've no idea what your database looks like, but with a bit of luck you could adapt example code and just open (a converted) SQL database.
Most users by now are used to the drill down paradigm rather than the paginated paradigm, so it's worth checking out the Drill Down example that comes with XCode even if it's not for databases (at least I don't think it is, I learned from a book, like Manuel.)
I would subclass UIViewController or UITableViewController depending on what type of records you plan on using.
I would recommend checking all the Apple's Examples, and most of the available online tutorial
Here are some, may be old though...
http://www.edumobile.org/iphone/iphone-programming-tutorials/tabbarcontroller-with-navigationcontroller-and-tableview-in-iphone/
http://www.aboveground.com/tutorials/adding-a-uitableview-to-a-custom-uiview
http://www.icodeblog.com/2008/08/08/iphone-programming-tutorial-populating-uitableview-with-an-nsarray/
http://blog.webscale.co.in/?p=150
http://www.ioschef.com/2011/03/un-aperitivo-de-uitableview-y-uitableviewcontroller/ in spanish..
http://adeem.me/blog/2009/05/19/iphone-programming-tutorial-part-1-uitableview-using-nsarray/ with videotutorial
I am a web developer who is trying to transition to Objective-C and Cocoa-touch. I am used to creating a table as a Dom element and then inserting it. If I wanted a link I did that as I went along. Obviously iPhone development is very different. I am looking for either a good explanation of hOw to wrap one's mind around the cocoa way of doing things.
Specifically I am looking to pull data from a web service and then make a drill down 3 or 4 levels deep. If there is a tutorial that shows how to do that perhaps I can learn through that.
Take a look at Apple's SeismicXML sample code. There's a lot in there, but it's basically what you asked for: an example of grabbing data from a web service and displaying it in a table.
There's a pretty big difference between creating a table on a web page and creating one in an iOS application. In the first case, you're actually writing down the data that gets rendered into a table by a browser. In the second case, you're creating a table object, and that table is like a living, breathing (compared to a web page, anyway) thing that can change through it's lifetime. The table will ask your code for data to display, and also what to do at certain points, such as when a user taps a cell.
Looking at a sample like SeismicXML is a good idea, but you'll still be mystified if you don't take the time to really understand what's going on. (I'm not saying you wouldn't, but there are plenty who don't and are confused to this day.) Go look, and then come back here if you have more questions.
The paradigm for iPhone tables is very different from HTML. On the web, you build the table and its elements and insert them into the DOM. On the iPhone, you have a proxy object that answers questions as the table builds itself. The table will ask the delegate how many entries it has and what it should put in each entry. That way, the delegate only needs to look up the information that is currently needed by the table, and not the whole thing, which may be only partially displayed. For instance, the delegate might to database queries as needed.
The simplest way is for your delegate to grab the info it needs from the web site and store it in an array for when the TableView asks for it.
The TableView itself is placed on the screen by calling addSubview: on a parent view.
You're asking more than one question here. You should split them up into multiple, more specific questions.
There are a variety of ways to make HTTP requests, anywhere from using the bundled classes like NSURL to using external libraries like ASIHTTPRequest. It also depends on what kind of data you are getting from the Web service -- there are various libraries to parse XML and JSON.
To make a "drill down" I assume you are describing table-based navigation. There are dozens of examples in the Apple sample code archive of projects showing off how to use UITableViewController, and probably hundreds available on Stack Overflow.
I'd like to know more about the pros and cons of using interface builder when developing iPhone/iPad apps.
I've written a fairly complex and customized app that's on the app store right now, but all of the interfaces are hand coded as they are fairly complex. I've customised the navigation and tab bars with backgrounds, table view cells are manually drawn for speed, and some views are complex and scalable with many subviews.
I'm pondering whether or not to start using interface builder but I'm not sure to what extent I'll use it and whether it's worth it at all. Is it quicker? Can things still be easily customised?
Any advice would be most welcome!
There is absolutely no reason not to use it. One thing that scares people off is their experiences with other GUI tools, things that generated code for them or some other mess. Then the problem becomes that it is hard to round-trip the interface, you cannot easily modify things once they are generated because of the complexity of pushing those changes back into the emitted code.
Interface Builder does not generate code, it uses NSArchiver to read and write an actual object graph for the GUI. This has many benefits, starting with the fact that you can easily round-trip the interface and make incremental changes. It really is all good, use it. :-)
Personally I've found Interface Builder quite tricky to ramp up on, and sometimes it doesn't expose all the properties I want to edit (although this may have changed in the newer versions), so generally I've tended to create my UIs in code.
If you do use Interface Builder, make sure to consider localization. Apple's iPhone Developer docs recommend that the NIB be a localized resource that gets translated. That way the translator can see if the new text fits in the view. Unfortunately this means the translator needs to be capable of opening NIB files and editing them (or a developer needs to get involved in the translation process).
Personally, I prefer providing localized text resources and setting the text to the UI in code. I then provide comments in the Localizable.strings file saying how long the text can be, and providing any context the translator might need.
There are no cons.
Why dont use it? It makes everything easier :)