CLLocation Coordinate 3D refactoring thoughts and examples.

From: http://www.mailinglistarchive.com/route-me-map@googlegroups.com/msg00296.html

This is the kind of thing that goes with the refactoring comments made 
already, an example method, and the marker manager object, and suggested 
approaches. Delete if you don't like pedantry.... it's just a suggestion.

At issue:

- (void) moveMarker:(RMMarker *)marker AtLatLon:(RMLatLong)point;

Listing the problems:

1. internally the kit is using "RMLatLong" which is arguably a big 
improvement over the cumbersome CLLocationCoordinate2D data type. 
RMLatLong typedefs over to the terribly named Apple equivalent. The 
problem is that the kit mixes and matches the two. Some interfaces you 
see CLLocationCoordinate2D, some RMLatLong and some of the others mixed 
in for the different coordinate systems cause some confusion. At the 
very least, RMLatLong or else CLLocationCoordinate2D need to be 
eradicated from the interface, one or the other should be the standard. 
I'd use RMLatLong myself and make it clear it is type compatible with 
CLLocationCoordinate2D. Flag day style replacement suggestion for 
RMLatLong+CLLocationCoordinate2D mix-n-match status quo is below.

2. AtLatLon: takes a data type of RMLatLon(g). Consistency. This happens 
all the time with google maps Javascript, the g shows up and vanishes 
all the time. The reason to leave it off is a clash with the keyword 
"long" so should probably standardize on RMLatLon and "AtLatLon:"

3. Bicaps: AtLatLon should be "atLatLon:" to fit 20+ year existing 
standard ObjC programming style.

4. Method taking "AtLatLon" *really* means "ToLatLon". It is not 
selecting the marker at the given position for movement, it is taking 
the marker given and assigning it the paramaterized coordinate.

Overall the refactored method would (in my suggestion) look like this:

// bicaps fixed, meaning fixed, type consistency fixed
- (void)moveMarker:(RMMarker *)marker toLatLon:(RMLatLon)point;

Simple changes, but makes a big difference in meaning and consistency. I 
think this kind of thing important and I think should be done regardless 
of the below part. When the interface gets cluttered up with 
inconsistency in type, meaning, bicaps, and so on, as the kit gets more 
features and functionality it gets exponentially harder to use.

STRUCTURAL SUGGESTIONS

This is a bit deeper than the cosmetic type changes.

[a] In order to manipulate a marker we need to know three things. 1. the 
map view it belongs to (so we can get the marker manager) and then 2. 
the marker manager and then 3. the marker we want to manipulate. The map 
view we only need to know so we can access the marker manager. For me, I 
suggest that it would be nice if all of this were encapsulated in the 
RMMarker object. That way to manipulate a marker, you deal with the 
marker. If you want the marker to move you tell it to move and it takes 
care of all of the things you don't need to or should know about.

For example, when we manipulate a view, we do not need to separately 
have an object on hand for its superview and for its window, and have to 
orchestrate the interaction between the three objects. We just 
manipulate the view. The creator of the view needs to plug it into the 
view heirarchy but beyond that, nobody has to know or care.

So operating it... you'd create a marker and assign it to a map view. 
Once assigned, it could internally pick up the marker manager of the map 
view, and when the user modifies its attributes, if these cause map 
operations, it should interact with the map through the marker manager 
if necessary. Otherwise, the user of the object should not know or care 
or have to go into the details of who is responsible for modifying whom.

In the current model, the marker is mostly a chunk of data, the 
modification of which is de-encapsulated and stored in the marker 
manager (it's being treated like a struct basically). This is part of 
the problem of the view-model-controller paradigm that Apple uses in 
that it bleeds over into things, none of which settle clearly into being 
views or models or controllers so is not always appropriate to try to 
shoehorn in. For example, a View does have data and you can directly 
manipulate this data without requiring a third party intemediary. *You* 
are the one doing the controlling so there is not a need to insert a 
controller there. That's your job.

With the excess controller removed from the picture, you get a cleaner 
interface, considering that your custom code is the marker "controller" 
and the marker is doing what a marker needs to do: knowing its position 
in the world, drawing, hiding, holding and displaying a label.

This is how UIView would work as a marker under the current structure:

UIView *subview = [self myCustomizedView];
UIViewManager *subviewManager;
UIView * superview = self.view; // we are a view controller
viewManager = [superview subviewManager];
CGRect frame = [subviewManager getFrameForView:myCustomView];
frame.origin.x += 10.0;
[subviewManager setFrame:frame forView:myCustomView];

If we had to do that every time we wanted to move a view... go nuts. 
Instead the code looks like:

UIView *subview = [self myCustomizedView]; // however way we have a 
reference to the view
CGRect frame = subview.frame;
frame.origin.x += 10.0;
subview.frame = frame.origin.x;

(1) we don't care about the host view (superview) or how it manages its 
subviews and (2) we don't even care if the view has a superview... we 
don't need to know, if it does, then it will do the right thing because 
the knowledge is encapsulated.

Suggestion [b]:

I would rip the RMLatLon concept out and replace with a 3d system with a 
2d interface for those who don't care about 3d. Then we drop being bound 
to "latlon" but end up having an opaque type for coordinates.

The above method would then be refactored to:

- (void)moveMarker:(RMMarker *)marker toCoordinate:(RMCoord)coord;

And if the smart marker suggestion made, this would actually boil down to:

RMMarker.h

@property (nonatomic,assign) RMCoord coordinate;

And in use:

// Move my marker on the map to a new coordinate
marker.coordinate = RMCoordMake(latitude,longitude,altitude);

...
// I got a CLLocation object, I want to move a marker based on the 
CLLocation object...
marker.coordinate = RMCoordMake2D(location.coordinate);

// -or- can add a support method to set from a CLLocation object, this 
would do the above
// internally from the object's data when being set
marker.location = location;

And everything would just work from there. To me this is clean, object 
oriented, encapsulated, and easy.

In depth:

Dump all mentions of CLLocationCoordinate2D and RMLatLong, and replace 
with a single data type, RMCoord.

typedef struct {
        CLLocationCoordinate2D coordinate;
        double altitude;
} RMCoord;

RMCoord RMCoordMake2D(CLLocationCoordinate2D coord)
{
        return RMCoordCopy3D(coord,0);
}

RMCoord RMCoordMake3D(CLLocationCoordinate3D coord, double altitude)
{
        RMCoord self;
        self.coordinate = coord;
        self.altitude = altitude;
        return self;
}

RMCoordMake(double latitude, double longitude, double altitude)
{
        CLLocationCoordinate2D coordinate;
        coordinate.latitude = latitude;
        coordinate.longitude = longitude;
        return RMCoordMake3D(coordinate,altitude);
}

The above can be put into the header file inlined following the examples 
in CGBase.h and CGGeometry.h.

Please consider the above as food for thought. Now I have to get back to 
my coding :-).

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"route-me" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/route-me-map?hl=en
-~----------~----~----~----~------~----~------~--~---