I want to build an iPad application that has a user interface close to the one that has been used for iBooks, or the one that Apple uses for the iPhone and iPad operating systems, so is there any component in Cocoa that makes it easy for me?
In fact, I thought about the UIImagPickerController, but I'm sure yet.
iBooks appears to be just a UITableView with a set of custom UITableViewCells that are drawn like the shelves. There is presumably a custom class which represents the books.
Apart from the level of drawing required, and the horizontal element, there is nothing 'special' in the way it is done.
Related
I am looking for a iOS Music app style Callout functionality. What I mean with that is that I want to get the same kind of callout "bubble" you get when press-and-hold within the Music app on iOS5.
I have been searching for a good solution for this, but can't find it.
The closest to what I need is: Use UITableView bubble/callout like iPod app However, this user didn't share what solution he had.
The libs I have looked at are:
https://github.com/jayway/CWUIKit
https://github.com/edanuff/MonoTouchCalloutView
http://www.eidac.de/?p=183
All of these have one this in common: They are useless.
The problem with these are that they all use a static callout view using PNG images, not one with a pointer beneath. Also, they do not adapt to the size of the screen; thus the bubble gets outside of the screen.
Any suggestions on a good library which I can use to implements this within my app?
What about WEPopover?
It might be what you want.
WEPopover for iOS
If i wanted to create a system whereby you could display a little rectangle ON TOP of an app already running, in which I could put any number of things, what would be the best, most apple standard way of doing it?
I'm thinking of something similar to iAdd. basically layers of views I suppose. I know that microsoft has a standard war of coding game menus for example. they're layered - each one has various event handlers for when things start and finish and they're own little update / load / draw methods etc that get called when appropriate. is there something similar for apps?
The most important thing really is just the starting point. what should I be doing in order to create another view over the existing one?
All UI elements in iOS inherit from class UIView. To add one view inside another use [view addSubview:subview]
For detailed information about how to use the UIView class, see View Programming Guide for iOS
I currently have an iOS application that was originally developer for the iPhone; it was then decided that it was going to be required for the iPad as well. However, there are not many changes to cater for this (only things such as layout, text size and a few others) - the app is just a bigger version for iPad in reality.
One of the things my app makes use of is a UITableView (with a custom UITableCellView). Each one of these then moves onto a UIView. In order to make it a bit more unique to the iPad, I would like to implement a UISplitView to combine these two, to make better use of the larger screen!
This application was handed to me from a previous developer. A large part (95%) of the UI was coded (and not done in Interface Builder). While I am picking up objective-c, there are still some things which throw me. Therefore, my question to you guys is: would this require a huge change in code if I was to combine my UITableView and UIView into a UISplitView? From what I have seen from playing around with the UISplitView, it doesn't seem so. However, because of all the rest being coded, I think the UISplitView will have to be, is that right? Or can I dump in an xib and string up the coded UITableView and UIView?
Final question, is there a tutorial anyone knows about where they have coded a UISplitView? All of them appear to be using Interface Builder.
I hope that is not too much information!
I am developing an RSS-reader-type application. I am toying with the possibility of using a normal TableView application but showing the articles as a film-strip. I am mainly thinking for an iPad application (but possible it works on the smaller iPhone as well).
The idea is to have the cells passing/scrolling across the screen using swipe touches (but horizontal, and not vertical as with the normal TableView). They will be some-kind of miniatures of the full article, and when tapped (or with multi-touch zoom to have better control) can be enlarged to read. Then can then just be be moved on as soon as the user has seen enough of it.
Does anybody know if there is an easy way of accomplishing something like that?
The most obvious solution that springs to mind would be to use a UIScrollView, as this will provide the inertial effects, etc. for free - all you'd have to do it populate it with the relevant sub-views. (UITableView's actually use a UIScrollView.)
For more information and sample code, see Apple's UIScrollView docs.
If you want horizontal scrolling, take a look at Jeremy Tregunna’s JScrollingRow. It’s open source under a public domain licence.
This is Cocoa Touch (et al), iPhone, XCode only.
After completing my first commercial iPhone app, I'm struggling a bit to find a way to start and expand an app from scratch which gives the most linear development (i.e., the least scrapping, re-write or re-organization of code, classes and resources) as app specs change and I learn more (mostly about what Cocoa Touch and other classes and components are designed to be capable of and the limitation of their customization).
So. File, New Project. Blank window based app? Create the controllers I need, with .xib if necessary, so I can localize them and do changes requested by the customer in IB? And then always subclass each class except those extremely unlikely to be customized? (I mean framework classes such as UIButton, CLLocation etc here.)
The question is a generic 'approach' type question, so I'll be happy to listen to handy dev practices you've found paid off. Do you have any tips for which 're-usable components' you've found have become very useful in subsequent projects?
Clients often describe programs in terms of 'first, this screen appears, and then you can click this button and on the new screen you can select... (and so on)' terms. Are there any good guides to go from there to vital early-stage app construction choices, i.e. 'functions-features-visuals description to open-ended-app-architecture'?
For example, in my app I went from NavBar, to Toolbar with items, to Toolbar with two custom subviews in order to accommodate the functions-features-visuals description. Maybe you have also done such a thing and have some advice to offer?
I'm also looking for open-ended approaches to sharing large ("loaded data") objects, or even simple booleans, between controllers and invoking methods in another controller, specifically starting processes such as animation and loading (example: trigger a load from a URL in the second tab viewcontroller after making sure an animation has been started in the first tab viewcontroller), as these two features apply to the app architecture building approach you advocate.
Any handy pointers appreciated. Thanks guys.
Closing this up as there's no single correct answer and was more suitable for the other forum, had I known it existed when I asked :)
If you want to know the method I ended up with, it's basically this:
Window-based blank app
Navigation Controller controls all, whether I need to or not (hide when not used)
Tab Bar Controller if necessary
Connect everything <-- unhelpful, I know.
Set up and check autorotation, it might get added to some view later.
Add one viewcontroller with xib for each view, you never know when they want an extra button somewhere. It's easier to copy code than make the max ultra superdynamic adjustable tableviewcontroller that does all list-navigation, etc.
Re-use a viewcontroller only when just the content differs in it, such as a detail viewcontroller.
Minimize code in each viewcontroller by writing functions and methods and shove them in a shared .m
Everything that's shared ends up in the App delegate, except subclassed stuff.
Modal viewcontrollers are always dynamically created and never have an xib.