CPTBarPlot: Do I need to call reloadData after changing bar fill color? - core-plot

I have an iOS app that displays a CPTBarPlot. My bar plot responds to touches by changing the color of the touched bar. I do this by keeping track of the index of the last selected bar in barWasSelectedAtRecordIndex, and then I set the color of the selected bar in barFillForBarPlot to make it a different color from the others. This works fine, but it seems I have to call reloadData every time the selected bar changes in order for the new fill color to take effect. This takes too long because there is a lot of data, making the app feel sluggish.
It seems wasteful to have to reload all the data just to change the color of one bar, so I'm hoping there's a better way, or I'm just doing something stupid.
Here is a simplified version of the relevant code:
-(void)barPlot:(CPTBarPlot *)plot barWasSelectedAtRecordIndex:(NSUInteger)idx
{
self.selectedIndex = idx
// Do I have to do this??
[self reloadData];
}
-(CPTFill *)barFillForBarPlot:(CPTBarPlot *)barPlot recordIndex:(NSUInteger)index
{
CPTFill *barFill = nil;
if (index == self.selectedIndex)
{
barFill = [CPTFill fillWithColor:redColor];
}
else
{
barFill = [CPTFill fillWithColor:blueColor];
}
return barFill;
}

Yes. The plot caches everything it loads from the datasource including the bar fills. You need to call -reloadData to tell it that new information is available to load.

Related

How to tell if a button is pressed at a certain time

I have a button with an image, and after a little while the button image will change, then change back after a few seconds. I want to be able to tell if the button is clicked while the image is different. thanks!
You have several options, but I'll detail two of them. The first is more self-contained and foolproof, but the second is arguably easier to read and understand.
Check the background image
The easiest way to do this would probably be to just test against the image itself. The image changes from time to time, but you don't really care when the button is pressed, you just care which background is visible when it is.
In other words, all you really need to know is whether the button's background is the MainBackground or the AlternateBackground, so when the button is pressed, you can simply check which one it is.
Try something like this, for when the button is pressed:
-(void)buttonPressed:(UIButton*)sender {
UIImage *mainBackground = [UIImage imageNamed:#"YOUR_IMAGE_NAME"];
NSData *imgdata1 = UIImagePNGRepresentation(sender.image);
NSData *imgdata2 = UIImagePNGRepresentation(mainBackground);
if ([imgdata1 isEqualToData:imgdata2]) {
// The button's background is the MainBackground, do one thing
} else {
// The button's background is the AlternateBackground, do another thing
}
}
Keep track of which image is currently displayed
Alternatively, you could have a BOOL value flip whenever the image's background is changed. Something like...
#property BOOL isMainBackground;
...in your H file, and then whenever you set the button's background image, you also set self.isMainBackground = YES; or self.isMainBackground = NO;
Then, your method for the button press would look something like this:
-(void)buttonPressed:(UIButton*)sender {
if (self.isMainBackground) {
// The button's background is the MainBackground, do one thing
} else {
// The button's background is the AlternateBackground, do another thing
}
}

Keep text in UITextView highlighted when the popover is dismissed

I have a UIPopover that shows up a plain view containing a UITextView filled with some text. I have managed to highlight the text. When the popover is dismissed, and re-opened, the highlight disappears. I want to keep the text highlighted even if if the application is closed. Any ideas how to achieve that?The code i used is the following :
- (void)highlight {
NSRange selectedRange = self.textViewAll.selectedRange;
NSMutableAttributedString *attributedString = [[NSMutableAttributedString alloc]
initWithAttributedString:self.textViewAll.attributedText];
[attributedString addAttribute:NSForegroundColorAttributeName
value:[UIColor redColor]
range:selectedRange];
// [highlightedRange addObject:];
// This is where i tried to save each location and length in a mutable array but didn't work
[highlightedRangeLocation insertObject:[NSNumber numberWithInteger:selectedRange.location] atIndex:indexOfHighlight];
[highlightedRangeLength insertObject:[NSNumber numberWithInteger:selectedRange.length] atIndex:indexOfHighlight];
///////////////////////////////////////////////////////////////////////////////
self.textViewAll.attributedText = attributedString;
indexOfHighlight ++ ;
}
- (void)viewDidLoad {
UIMenuItem *highlightMenuItem = [[UIMenuItem alloc] initWithTitle:#"Highlight" action:#selector(highlight)];
[[UIMenuController sharedMenuController] setMenuItems:[NSArray arrayWithObject:highlightMenuItem]];
float sysVer = [[[UIDevice currentDevice] systemVersion] floatValue];
if (sysVer >= 8.0) {
self.textViewAll.layoutManager.allowsNonContiguousLayout = NO;
}
}
Could anyone point out how to continue from here?
Edit 1 :
The code that close the popover :
- (IBAction)closeFun:(id)sender {
// self.popoverPresentationController set
[self dismissViewControllerAnimated:YES completion:nil];
// [self dismis]
}
Can't you juste save the Highlighted text range in [NSUserDefaults standardUserDefaults] whenever the popover is dismissed, and retrieve it when the popover reappears ?
I think the problem is in the fact that the popover is responsible for the highlighted state, i.e .it is the popover who keeps that fact/state.
The popover is a part of presentation layer / user interface. Surely the highlight represents some fact that ( now comes the catch ) - is completely independent of the popover.
For example highlighting a task could represent that the task is due. Or, highlighting a label to red color could mean that the balance in the bank is in negative numbers.
You see, no matter what user interface element you use, they only represent some underlying business reality.
But what probably happens you create a popover instance, you set it to have a highlighted element. But then this concrete popover instance dies, when it is closed.
And the highlight dies with it.
When you click some button (I guess), a popover shows up, but it is a different instance. This instance doesn't know about highlight.
Even if you somehow managed to keep the one instance of popover alive, and just hide and show it again, the popover should NOT be responsible to know whether something is red or due, (and thus highlighted.)
In you application, you should have a well separated model layer...which is basically a set of related objects that represent state ie. fact that are related to what the application solves from business perspective (for ex. draws lines, calculates interest..stores music..anything really). This model layer, some object in it, should store the facts..ie.e. the task is due, or the balance is low.
Every time you show your popover, you should investigate what are the underlying facts in your model layer right when the popover is being shown. Ivestigating means find a programmatic way to look into model objects, find out about values there and and set up the highlight in that moment again based on this "investigation". You should not rely on the fact that it was highlighted in the not so distant past.

iOS UIScrollView performance

I'm trying to increase the scrolling performance of my UIScrollView. I have a lot of UIButtons on it (they could be hundreds): every button has a png image set as background.
If I try to load the entire scroll when it appears, it takes too much time. Searching on the web, I've found a way to optimize it (loading and unloading pages while scrolling), but there's a little pause in scrolling everytime I have to load a new page.
Do you have any advice to make it scroll smoothly?
Below you can find my code.
- (void)scrollViewDidScroll:(UIScrollView *)tmpScrollView {
CGPoint offset = tmpScrollView.contentOffset;
//322 is the height of 2*2 buttons (a page for me)
int currentPage=(int)(offset.y / 322.0f);
if(lastContentOffset>offset.y){
pageToRemove = currentPage+3;
pageToAdd = currentPage-3;
}
else{
pageToRemove = currentPage-3;
pageToAdd = currentPage+3;
}
//remove the buttons outside the range of the visible pages
if(pageToRemove>=0 && pageToRemove<=numberOfPages && currentPage<=numberOfPages){
for (UIView *view in scrollView.subviews)
{
if ([view isKindOfClass:[UIButton class]]){
if(lastContentOffset<offset.y && view.frame.origin.y<pageToRemove*322){
[view removeFromSuperview];
}
else if(lastContentOffset>offset.y && view.frame.origin.y>pageToRemove*322){
[view removeFromSuperview];
}
}
}
}
if(((lastContentOffset<offset.y && lastPageToAdd+1==pageToAdd) || (lastContentOffset>offset.y && lastPageToAdd-1==pageToAdd)) && pageToAdd>=0 && pageToAdd<=numberOfPages){
int tmpPage=0;
if((lastContentOffset<offset.y && lastPageToAdd+1==pageToAdd)){
tmpPage=pageToAdd-1;
}
else{
tmpPage=pageToAdd;
}
//the images are inside the application folder
NSString *docDir = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
for(int i=0;i<4;i++){
UIButton* addButton=[[UIButton alloc] init];
addButton.layer.cornerRadius=10.0;
if(i + (tmpPage*4)<[imagesCatalogList count]){
UIImage* image=[UIImage imageWithContentsOfFile:[NSString stringWithFormat: #"%#/%#",docDir,[imagesCatalogList objectAtIndex:i + (tmpPage*4)]]];
if(image.size.width>image.size.height){
image=[image scaleToSize:CGSizeMake(image.size.width/(image.size.height/200), 200.0)];
CGImageRef ref = CGImageCreateWithImageInRect(image.CGImage, CGRectMake((image.size.width-159.5)/2,(image.size.height-159.5)/2, 159.5, 159.5));
image = [UIImage imageWithCGImage:ref];
}
else if(image.size.width<image.size.height){
image=[image scaleToSize:CGSizeMake(200.0, image.size.height/(image.size.width/200))];
CGImageRef ref = CGImageCreateWithImageInRect(image.CGImage, CGRectMake((image.size.width-159.5)/2, (image.size.height-159.5)/2, 159.5, 159.5));
image = [UIImage imageWithCGImage:ref];
}
else{
image=[image scaleToSize:CGSizeMake(159.5, 159.5)];
}
[addButton setBackgroundImage:image forState:UIControlStateNormal];
image=nil;
addButton.frame=CGRectMake(width, height, 159.5, 159.5);
NSLog(#"width %i height %i", width, height);
addButton.tag=i + (tmpPage*4);
[addButton addTarget:self action:#selector(modifyImage:) forControlEvents:UIControlEventTouchUpInside];
[tmpScrollView addSubview:addButton];
addButton=nil;
photos++;
}
}
}
lastPageToAdd=pageToAdd;
lastContentOffset=offset.y;
}
Here's a few recommendations:
1) First, understand that scrollViewDidScroll: will get called continuously, as the user scrolls. Not just once per page. So, I would make sure that you have logic that ensures that the real work involved in your loading is only triggered once per page.
Typically, I will keep a class ivar like int lastPage. Then, as scrollViewDidScroll: is called, I calculate the new current page. Only if it differs from the ivar do I trigger loading. Of course, then you need to save the dynamically calculated index (currentPage in your code) in your ivar.
2) The other thing is that I try not to do all the intensive work in the scrollViewDidScroll: method. I only trigger it there.
So, for example, if you take most of the code you posted and put it in a method called loadAndReleasePages, then you could do this in the scrollViewDidScroll: method, which defers the execution until after scrollViewDidScroll: finishes:
- (void)scrollViewDidScroll:(UIScrollView *)tmpScrollView {
CGPoint offset = tmpScrollView.contentOffset;
//322 is the height of 2*2 buttons (a page for me)
int currentPage = (int)(offset.y / 322.0f);
if (currentPage != lastPage) {
lastPage = currentPage;
// we've changed pages, so load and release new content ...
// defer execution to keep scrolling responsive
[self performSelector: #selector(loadAndReleasePages) withObject: nil afterDelay:0];
}
}
This is code that I've used since early iOS versions, so you can certainly replace the performSelector: call with an asynchronous GCD method call, too. The point is not to do it inside the scroll view delegate callback.
3) Finally, you might want to experiment with slightly different algorithms for calculating when the scroll view has actually scrolled far enough that you want to load and release content. You currently use:
int currentPage=(int)(offset.y / 322.0f);
which will yield integer page numbers based on the way the / operator, and the float to int cast works. That may be fine. However, you might find that you want a slightly different algorithm, to trigger the loading at a slightly different point. For example, you might want to trigger the content load as the page has scrolled exactly 50% from one page to the next. Or you might want to trigger it only when you're almost completely off the first page (maybe 90%).
I believe that one scrolling intensive app I wrote actually did require me to tune the precise moment in the page scroll when I did the heavy resource loading. So, I used a slightly different rounding function to determine when the current page has changed.
You might play around with that, too.
Edit: after looking at your code a little more, I also see that the work you're doing is loading and scaling images. This is actually also a candidate for a background thread. You can load the UIImage from the filesystem, and do your scaling, on the background thread, and use GCD to finally set the button's background image (to the loaded image) and change its frame back on the UI thread.
UIImage is safe to use in background threads since iOS 4.0.
Don't touch a line of code until you've profiled. Xcode includes excellent tools for exactly this purpose.
First, in Xcode, make sure you are building to a real device, not the simulator
In Xcode, choose Profile from the Product menu
Once Instruments opens, choose the Core Animation instrument
In your app, scroll around in the scroll view you're looking to profile
You'll see the real time FPS at the top, and in the bottom, you'll see a breakdown of all function and method calls based on total time ran. Start drilling down the highest times until you hit methods in your own code. Hit Command + E to see the panel on the right, which will show you full stack traces for each function and method call you click on.
Now all you have to do is eliminate or optimize the calls to the most "expensive" functions and methods and verify your higher FPS.
That way you don't waste time optimizing blind, and potentially making changes that have no real effect on the performance.
My answer is really a more general approach to improving scroll view and table view performance. To address some of your particular concerns, I highly recommend watching this WWDC video on advanced scroll view use: https://developer.apple.com/videos/wwdc/2011/includes/advanced-scrollview-techniques.html#advanced-scrollview-techniques
The line that is likely killing your performance is:
addButton.layer.cornerRadius=10.0;
Why? Turns out the performance for cornerRadius is AWFUL! Take it out... guaranteed huge speedup.
Edit: This answer sums up what you should do quite clearly.
https://stackoverflow.com/a/6254531/537213
My most common solution is to rasterize the Views:
_backgroundView.layer.shouldRasterize = YES;
_backgroundView.layer.rasterizationScale = [[UIScreen mainScreen] scale];
But it works not in every situation.. Just try it

ShinobiCharts selecting a column

I'm trying to make the columns in my chart to be selectable and show more details of the selected column when clicked. Every column is represented by one series (you will understand in a second).
this is how i build each series:
-(SChartSeries *)sChart:(ShinobiChart *)chart seriesAtIndex:(int)index {
SChartColumnSeries *series = [SChartColumnSeries new];
series.style.showAreaWithGradient = NO;
series.stackIndex = [NSNumber numberWithInt:0];
series.selectedStyle.showAreaWithGradient = NO;
CHART_COLOR_TYPE dataType = [TestGraphDataManager getDataType:index];
series.style.areaColor = (dataType == ACCOUNT)?
[UIColor colorWithRed:227.0f/255.0f green:179.0f/255.0f blue:0.0f/255.0f alpha:0.5f]:
[UIColor colorWithRed:0.0f/255.0f green:172.0f/255.0f blue:235.0f/255.0f alpha:0.5f];
series.selectedStyle.areaColor = [UIColor colorWithRed:129.0f/255.0f green:0.0f/255.0f blue:82.0f/255.0f alpha:0.5f];
series.selectionMode = SChartSelectionSeries;
series.style.lineColor = [UIColor clearColor];
series.selectedStyle.lineColor = [UIColor clearColor];
return series;
}
The problem I'm currently having is that only the first series is selectable. Also i made each bar represented by a different series so that i can toggle its color easly with series.selectionMode = SChartSelectionSeries
Finally I have this delegate event so that i can load the extra data but it's also being called only for the first series
- (void)sChart:(ShinobiChart *)chart toggledSelectionForSeries:(SChartSeries *)series nearPoint:(SChartDataPoint *)dataPoint atPixelCoordinate:(CGPoint)pixelPoint{
NSLog(#"click event called");
//Display data
}
Does anyone know why this is happening? It's been driving me insane all day.
Thank you, in advance for any help give.
EDIT:
I found the major problem as i do series.stackIndex = [NSNumber numberWithInt:0]; it makes all the bars with the same name stack (as nome of the names repeat its not a problem in my point of view), i do this so that all the bars are at the same distance from the tick marker and so that the bars aren't very tine. But i believe that shinobi places invisible bars for those values and they are over the other, making only the first series selectable because its over the others. If i remove that line the graphic look horrible but all are clickable.
Any idea on how to bypass this or to avoid this problem?
how it should look (using stacking indexes) but it breaks the click events:
without stacking indexes all bars are clickable but it doesn't look as good, and it gets worse the more bars i have this is using only 4 bars:
Rob here from Shinobi - thanks for getting in touch!
This can be solved by using subclassing, and returning zero for the column offset, like so:
#interface MyColumnSeries : SChartColumnSeries
#end
#implementation MyColumnSeries
- (double) offsetOfStackInChart:(ShinobiChart *)chart forDatapointIndex:(const int)pointIndex withPointSelector:(SEL)pointSelector
{
return 0.0;
}
#end

iOS - Not allocating too much memory at once

Trying to get around a crash that is happening on some iOS devices, in conjunction with advice from Apple to "not cause allocation spikes". How can I change this code to not happen all at once?
for (Item *item in self.items) {
ItemView *itemView = [[ItemView alloc] initWithFrame:CGRectMake(xPos, kYItemOffsetIphone, kItemWidthIphone, kItemHeightIphone) ];
itemView.delegate = self;
[itemView layoutWithData:item]; //this just adds an imageView and button
[self.scrollView addSubview:itemView];
xPos += kXItemSpacingIphone;
}
There are around 20 objects in the self.items array, which are used to build the 20 ItemViews. Again, is there some way to make this code less "allocation intensive"?
I personally do something along the lines of:
Make my view controller the delegate of the scroll view (if you do this in code, you have to modify your view controller's .h to say that it conforms to UIScrollViewDelegate).
Define a scrollViewDidScroll method that (a) determines the frame of the visible portion of the scroll view; (b) determine which of the subviews intersect with that visible portion; (c) load the items that are visible, and unload the ones that aren't.
So, for example, it might look something like the following:
- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
// Determine the frame of the visible portion of the scrollview.
CGRect visibleScrollViewFrame = scrollView.bounds;
visibleScrollViewFrame.origin = scrollView.contentOffset;
// Now iterate through the various items, remove the ones that are not visible,
// and show the ones that are.
for (Item *itemObject in self.itemCollection)
{
// Determine the frame within the scrollview that the object does (or
// should) occupy.
CGRect itemObjectFrame = [self getItemObjectFrame:itemObject];
// see if those two frames intersect
if (CGRectIntersectsRect(visibleScrollViewFrame, itemObjectFrame))
{
// If it's visible, then load it (if it's not already).
// Personally, I have my object have a boolean property that
// tells me whether it's loaded or not. You can do this any
// way you want.
if (!itemObject.loaded)
[itemObject loadItem];
}
else
{
// If not, go ahead and unload it (if it's loaded) to conserve memory.
if (itemObject.loaded)
[itemObject unloadItem];
}
}
}
That's the basic idea. You can certainly optimize this logic based upon your app's particular design, but this is how I generally do it.

Resources