Design and implementation questions iOS SDK 10.1.1

[RichardDeavers]

Greeting,

Being new to the ARCGis platform and iOS SDK I'd like to ask a few questions regarding design and implementation such that the resource footprint will be as small as possible.  For my questions I'd like to keep the program simple.  i.e. A program that displays graphics and feature data from our server.  No editing.

I work for a local government. 
We have some layers with little data (to show at city level) and some that are data intensive (to show at some predefined min max scale).

We have a REST MapService setup that contains a few feature layers that basically look like this...

MobileBase (MapServer)/
  Feature Layer 0 (District boundaries - light data)
  Feature Layer 1
  Feature Layer 2 (Parcel layer - heavy data)
  Feature Layer 3 (City Boundary layer - the extent to which all other layers are contained)
  Feature Layer 4
  Feature Layer 5 

I've experimented with two ways to get the graphics and features for the layers.
Method 1.
               Create a DynamicMapServiceLayer using a single URL
               Create a dynamic layer object
               Set dynamic visibleLayers property to show the graphics for each Feature layer
               Add dynamic layer to mapview

This method seems to respect the max and min scales defined for the layer.  E.g. the parcel graphic's aren't drawn until we've zoomed down, which is great. 

Questions:           Using this method, how do I access each Feature layers graphics and feature attributes so that I can manipulate them before they are drawn?  I.e. change line color in graphics and text size/color.
                              What object and at what point is calling the server for the parcel layer once we zoom into range?  What event???s would be useful to help understand this?
                              Is this the best approach to use for displaying information only in terms of resource use? (No editing)

Method 2.
               Create a graphic layer object, graphic object, Query Task object, Query object for each Feature Layer.
               Add each graphic object to mapview at viewload time.

Questions:           Is there any benefit to doing it this way versus method 1 for display purposes?
                              If doing it this way, should I use the query and events to only get data within the basemap extent and the layers max min scales?
                             Which events are appropriate for these queries?

I can figure out the "how to" implement details.  I'm looking for some guidance on "which" objects give me what and at what time.
Thanks in advance for any input on this.

[DanaMaher]

...I can figure out the "how to" implement details.  I'm looking for some guidance on "which" objects give me what and at what time.
Thanks in advance for any input on this.

For Method 1, the AGSDynamicMapServiceLayer, what you are actually getting back from the service are tiles rendered on the fly with the layers you have selected to be turned on. You cannot actually change the symbolization on the client side; it is determined by the map service. You can register for notifications as to when the layer's extent changes and when it is going to redraw itself.

For Method 2, the AGSFeatureLayer or AGSGraphicsLayer populated by a query, you are getting back JSON for each object matched by the query and drawing that JSON as AGSGraphics. 

If you want to display many layers in a service at once and are concerned about network overhead, Method 1 can save you bandwidth, at least compared to the upfront cost of querying a large number of graphics on several layers. However, if you want to query feature attributes and allow the user to dynamically interact with features on the map, you will have to use an AGSGraphicsLayer or AGSFeatureLayer. The same if you want to change symbolization.

I have had success with using an AGSDynamicMapServiceLayer at first to show the user what is being mapped, and then performing queries to get live features based on user selections. This balances allowing the user to see map features and allowing the user to interact with map features. It also gets around some pitfalls of querying large numbers of features just to display them all:

1. Loading large numbers of features has a high initial network cost.


2. Loading large numbers of features may have a high client side memory footprint depending on the attributes of each feature.


3. For the 10.1.1 SDK, there are currently some issues with drawing large numbers of AGSGraphic objects using either graphic or feature layers. See my earlier post.


4. The backing map service has a MaxRecordCount configuration value that determines how many features can be returned by a single query. Be aware of this.

My approach has a possible disadvantage in that it is necessary to clearly communicate to the user which part of the map has been selected for live interaction with features. I spent a lot of time figuring out a UI/UX that makes it clear to the user that they have a) selected features within a certain area of the map and b) can now interact with those features.

I think a live-features-first approach might work well for certain use cases. If you go this way with yours, you will need to figure out some issues with selection; if your user tries to tap on a parcel feature but misses, the SDK will probably interpret that tap as a selection of an encompassing city boundary feature. You may want to allow the user to switch between selecting different types of features.

[RichardDeavers]

Thank you for the response.  I have decided to go with a way to select a single feature layer at a time.  Though, I haven't decided on implementation yet.

I also went with calling each feature layer using the AGSFeaturelayer featureServiceLayerWithURL API.  This seems to be pretty effective so long as the services have well defined attributes on the server.  So I guess I'm asking for a quick answer on this.  How do I override the default text and symbol graphics on returned featurelayer object before it is displayed.  i.e. Which object/methods do I use.

Thanks.

[DanaMaher]

So I guess I'm asking for a quick answer on this.  How do I override the default text and symbol graphics on returned featurelayer object before it is displayed.  i.e. Which object/methods do I use.
Thanks.

You should be able to do this with the AGSRenderer class. An AGSFeatureLayer has an AGSRenderer member, renderer, which is constructed by the service JSON returned via AGSFeatureLayer's initWithURL: method. You can create your own AGSRenderer and override the default rendering. You will need to familiarize yourself with the AGSSymbol group of classes. If you have graphics that are text, geometry, and/or icon composites, you will probably need to use AGSCompositeSymbol.

[RichardDeavers]

Thank you Dana for all the information.  You have saved me a great deal of time putting together a "phase 1" proof of concept application.  I will do a little deep diving into the render object today to finish it off. (pouring you a drink)

[RichardDeavers]

Thank you Dana for all the information.  You have saved me a great deal of time putting together a "phase 1" proof of concept application.  I will do a little deep diving into the render object today to finish it off. (pouring you a drink)

sub-classing the AGSRenderer class works like a charm...  Thanks again

[DanaMaher · Accepted solution]

...pouring you a drink

Beer really should be the currency of programming. 😛 Glad I could help. As a developer with a few years sunk into ESRI's SDKs and API's, I'd like to see this ecology thrive.

You might mark one of my replies as the answer in order to mark this thread as resolved/answered.

[RichardDeavers]

Beer really should be the currency of programming. 😛 Glad I could help. As a developer with a few years sunk into ESRI's SDKs and API's, I'd like to see this ecology thrive.

You might mark one of my replies as the answer in order to mark this thread as resolved/answered.

I like the way you think.  This is one of the few products that I'd have to say has some serious potential.  I hope to do some interesting things with it in the future.