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 SUGGESTIONSThis 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 controllerviewManager = [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 viewCGRect 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 coordinatemarker.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 setmarker.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-~----------~----~----~----~------~----~------~--~---
