POST
|
I'm having some trouble with the AGSAttachmentManager downloading attachments. The following methods are all in a ViewController that implements AGSAttachmentManagerDelegate, but when it runs, the delegate methods don't fire. I've tried adding calls to retain, in case it was an issue with the manager getting prematurely cleaned up, but that doesn't appear to be what's happening. This happens with calls to a feature that definitely has an attachment visible in REST. Is there a reason why the first function in this code would run but the second two wouldn't?
-(void)setSelectedGraphic:(AGSGraphic *)selectedGraphicValue
{
_selectedGraphic = selectedGraphicValue;
[self.relatedTableFeatureLayer clearAttachmentManagers];
AGSAttachmentManager *am = [[self.relatedTableFeatureLayer attachmentManagerForFeature:_selectedGraphic] retain];
am.delegate = self;
[am downloadAttachmentInfos];
}
-(void)attachmentManager:(AGSAttachmentManager *)attachmentManager didDownloadAttachmentInfos:(NSArray *)attachmentInfos
{
for(InspectionFormViewController *controller in self.viewControllers)
{
controller.attachments = [NSMutableArray array];
}
for(AGSAttachmentInfo *info in attachmentInfos)
{
AGSAttachmentManager *am = [[self.relatedTableFeatureLayer attachmentManagerForFeature:self.selectedGraphic] retain];
am.delegate = self;
[am downloadAttachmentDataForId:info.attachmentId];
}
//[attachmentManager release];
}
-(void)attachmentManager:(AGSAttachmentManager *)attachmentManager didDownloadDataForAttachment:(AGSAttachment *)attachment
{
for(InspectionFormViewController *controller in self.viewControllers)
{
[controller.attachments addObject:attachment];
}
//[attachmentManager release];
}
... View more
11-15-2012
12:29 PM
|
0
|
1
|
428
|
POST
|
I'm implementing an identification workflow that uses a UINavigationController that contains a series of UITableViews that allow the user to drill down into the data. Unfortunately, when I insert the navigation controller view into the callout, it weirdly overhangs the UITableView it contains: [ATTACH=CONFIG]16435[/ATTACH] As you can see, the navigation bar overhangs the top row of the table, which is difficult to see and access from under it. I'm using the following code to put the view up:
-(void)identifyTask:(AGSIdentifyTask *)identifyTask operation:(NSOperation *)op didExecuteWithIdentifyResults:(NSArray *)results
{
NSLog(@"Identify task returned with %d results.", [results count]);
if (results && results.count > 0)
{
IdentifyResultsViewController *idWindow = [[IdentifyResultsViewController alloc] init];
idWindow.results = results;
UINavigationController *nvc = [[UINavigationController alloc] initWithRootViewController:idWindow];
map.callout.customView = nvc.view;
nvc.view.frame = CGRectMake(0, 0, 275, 400);
[map showCalloutAtPoint:self.mapPoint];
}
}
I've played around with setting the frame of the idWindow.view, but haven't had any luck with that. Are there any better ways to get this layout working correctly?
... View more
07-27-2012
06:25 AM
|
0
|
3
|
1394
|
POST
|
I resolved the problem outside of this sample - the above code was being called by a NSOperation that was being killed before the AGSMapServiceInfoDelegate received the callbacks.
... View more
07-27-2012
06:13 AM
|
0
|
0
|
197
|
POST
|
I have an instance of AGSMapserviceInfo which I'm trying to use to retrieve legend info: -(void)queryLegendWithMapServiceInfo:(AGSMapServiceInfo *)msi { if(msi.version >= 10.01) { msi.delegate = self; [msi retrieveLegendInfo]; }else { NSLog(@"Skipping layer [%@]. ArcGIS Service must be version 10 SP1 or above",msi.URL ); } } - (void)mapServiceInfo:(AGSMapServiceInfo *)mapServiceInfo operationDidRetrieveLegendInfo:(NSOperation*)op { NSLog(@"Do stuff"); } - (void)mapServiceInfo:(AGSMapServiceInfo *)mapServiceInfo operation:(NSOperation*)op didFailToRetrieveLegendInfoWithError:(NSError*)error{ NSLog(@"Error encountered while fetching legend : %@",error); } Unfortunately, this doesn't notify the delegate on either the didFailToRetrieveLegendInfoWithError or on the operationDidRetrieveLegendInfo methods. I've checked this in the debugger and under the Allocations instrument, and msi is neither nil or deallocated. Is there another reason why this call wouldn't even give an error?
... View more
07-24-2012
05:22 AM
|
0
|
3
|
2949
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|