I have a ScatterPlot displayed within a CPHostingView which takes up the bottom 25% of the screen (the hosting view is 320x100).
Now i would like to display a Pie chart at the top of the view (maybe 50x50, roughly).
What do i need to do to make this possible?
My research suggests that i shouldnt create multiple instance of CPXYGraph and that i should just use multiple CPHostingViews.
Problem is, my hosting views do not take up the entire screen, thus, im having trouble determining how to render a pie-chart in one view and a scatterplot in the other.
You should use multiple hosting views.
The Core Plot hosting view is a subclass of UIView on iOS. It inherits the standard view layout mechanism from UIView. Set the autoresizingMask in code or in Interface Builder.
Related
I am attempting to make a custom view that looks like the attached picture. The top two cell would be static while the bottom three would scroll if there are more than the screen can fit, and only scroll within that given area. I am wondering what the best approach is to making these types of custom views. I know how to make custom UItableviewcells and have custom content in them, but I am struggling with an overall strategy to make a custom UITableview that has certain cells be static and others scroll. Should I just implement a table view to be part of the screen in storyboards? Or are there better ways to do so?
I would do this by making the top two "cells" just be UILabels, and the bottom a table view where both the cells and the table view would have a clear background. The table view should be set to have no separators between the cells, and the cells should have a UILabel with a background cooler the same as the top UILabels.
This was the result:
I normally do not like to use story board much. And prefer SubClassing UIView. It might take more time to code at first but in a long run it is easier and very dynamic to control the UI programmatically.
In your problem I would make two static UIView(s). If the two view are similar the advantage of using UIView class is that you can use same class with different data model to generate multiple views. But if you use story board you need to copy past multiple times. Hence try to create UIViews class objects as much as possible.
And then the bottom one will be a simple table view. Do not think there is much you can do in this case. Do submit some codes you have done so that we can better refine it.
I want to implement a grid view like the one in Pinterest
I thought about implementing as 3 table views. But I was not able to scroll them together well. When I implemented the scrollViewDidScroll and set the contentOffset for the table views other the scrollView , the scrolling became slow and unusable.
Another implementation I did was of was having a set of images to load and calling the viewDraw function in scrollViewDidScroll. The ViewDraw function just draws the necessary images and removes the rest of the images from the memory which were already drawn but wont be visible .
this too makes the ScrollView scrolling slow. And another issue with it is that there are white(background color) patches before the images are drawn.
What should be the best way to implement this grid view ?
Solution 1 (i don't know if this works and I don't like it very much)
How about having 3 vertical table views side by side, but forward any touch events from any tableview to the other ones. I understand that you had performance problems when trying to sync the tableviews, but maybe working on an event level things would work better. Maybe.
Solution 2
Use a UIScrollView (for the scrolling purposes of course). For performance and memory reasons you also need to implement a load-on-demand mechanism so that you don't load all your images at once.
To do this I would create a class, CustomImageStrip that handles a vertical image list. This class works together with the scrollview and uses contentOffset to decide when it is time to load/unload a image from the strip.
By having 3 independent image strip classes, the images can be of any size and don't need to be aligned. But, since they all belong to the same UIScrollView the scrolling will be done simultaneously.
I'm writing an iPhone app (which will be my first ios app) that has about 50 screens, each of which has the same background - where the background is an image covering the entire screen real estate and another image at the top as a banner.
Each screen will have some text along with 0, 1, 2 or 3 buttons appearing beneath the banner image.
What is the best design for putting this together?
The options I could think of were (in every each I was planning on having a root controller which is responsible for displaying each view as appropriate).
1) Have 50 separate screens as xibs (and associated view controllers), each of which contains the two background images plus however many buttons each particular screen needs.
2) Have 4 superclasses as xibs - (representing no buttons, 1 button, 2 button, 3 buttons) and have each of those contain the background images and as many buttons as appropriate. Then have 50 subclasses which simply just set the text and button content as appropriate using the superclasses instance variable outlets.
3) Have the root controller have a view which contains the two background images which is there permanently, and each of the 50 views displays its text and buttons on top of that.
4) (If this is possible, I need to check if a window can have images). Same as 3, except the root controller doesn't have a view, the main window displays the background images and each class displays its text and buttons on the top of this. So each view controller would have to load and display the text and button objects using code (in which case there's not much point to have xibs for them).
Is there another solution? Is one of these the "best" solution?
If I went with 3 would it not be possible to define the position text and buttons in a xib? (because in order to do so they would need a parent view in order to position them in interface builder, but if that were the case then when the view is drawn the background wouldn't be visible).
If 4 is possible, then the root controller has no view, therefore does it still need to be descended from UIViewController, or could it simply be descended from NSObject?
I think at the moment I am leaning towards option 2) as that way I can design all the views visually as xibs, but there are only 4 of them. Unless there is a better more elegant solution.
TIA
What you can do, is one XIB with all the buttons and then you would set then hidden accordingly. Although it would tie you up a bit. The 2) option is more flexible. The 3) is ok too. You could have one rootViewController, just to hold the images and then you could something like this:
[rootViewController.spaceForMyChildView addSubview: myNewViewController.view];
The "spaceForMyChildView" would be a view that would hold your child views.
I would do fusion between 2) and 3) probably.
UIWindow inherits from UIView, so can have anything within it. So (4) is feasible, though you're starting to get into tricky water if you want to support any sort of view rotation.
I'd think an inverted (2) would be the easiest thing — have a single superclass that upon viewDidLoad adds the background and top banner programmatically. Have your specific controllers inherit from that and design them graphically to contain whatever you want, mindful that the image and banner will subsequently be added.
That said, if your views are really as simple as a single text area and up to three buttons, always with fixed positions, then it sounds like a single view that repopulates its fields from a data source, as Jacky Boy suggests, is probably the smartest thing.
i'm new to the ios sdk and i'm developing my first app. i need to implement a curl transition between multiple views; giving the user the impression they are reading a book. the documentation only talks about doing it between two views in a single view controller. like i said i need to implement this with a stack of several views. do i need to use more than 1 view controller? if so how? or do i have to use 1 view controller but use say 10 views in a stack? again how would i go about doing this.
would greatly appreciate your help.
Ideally, you would use only two views for this: one for the view being animated (to an offscreen position), and one for the view underneath. To handle multiple flips, you would animate the top view to its offscreen position, then fill it with the data for the page underneath the current page and then insert it underneath the current page. For the subsequent flip, you would animate the current off the screen, etc.
You could alternatively use a number of views that matches the total number of pages you want to display. This might make your coding simpler, but it would eat up a lot more memory.
I have an idea about an application that I want to build and Im new to iPhone/iPad development (but not new to development in other languages/frameworks such as .NET and Java). I want to layout some views on the screen so that they animate (slide in) from different directions into their places.
The question is about the strucuture of the application, if I have say 4 rectanglular areas on the screen that contain business data, such as contacts (name, photo, etc...) and they all take up different widths of the screen (say the first contact takes up one row of the screen, but the next 2 take up half the width of the next row each, and so on).
Should I create a custom view for the different sized contact views, (i.e. LargeCustomView and SmallCustomView, and any other special type that I make) or should it all be one type, say, CustomerDetailsView which could be stretched to fit at design time?
Also, if there were, say, 3 different instances of the same custom view on the one screen, are there 3 instances of the view controller also? Im a little confused about powering the data behind a view, can someone shed some light on this for me? Do I just set the properties (say an instance variable ContactForView) on the view controller for each instance?
Thanks for any help you can give
Cheers,
Mark
Should I create a custom view for the different sized contact views, (i.e. LargeCustomView and SmallCustomView, and any other special type that I make) or should it all be one type, say, CustomerDetailsView which could be stretched to fit at design time?
I think only you can answer that question. If UIView autoresizing masks are enough to accomondate both layouts, you should probably go for just one class. If that's not enough, you can either override layoutSubviews to account for different sizes or perhaps go with a common superclass to contain the logic and two subclasses to do the different layouts.
Also, if there were, say, 3 different instances of the same custom view on the one screen, are there 3 instances of the view controller also?
Because of the way UIViewControllers work, Apple generally recommends not having more than one view controller per screen. From the docs:
You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller.
Otherwise, things like device rotation can get tricky as a view controller that is not full screen should probably react differently to such events and Apple's UIViewController is not written to do that. However, nobody stops you from writing your own view controllers (derived from NSObject, not from UIViewController) so that's what I would recommend: if the view is quite complex, write a custom controller class for it but stick to one UIViewController per screen.