Closed koem closed 12 years ago
I'm not exactly sure how I feel about this request. If I assume that the feature were implemented, I as a user would demand some automatic displaying of those images (i.e. always have a solved mystery with an exclamation mark). But I'm not sure if other users think the same or different than me. But there is one thing I strongly support in this request: We should refactor the icons code in a way that using overlays on the icons becomes easier. Currently we have fixed bitmaps for the different possible cache markers (normal, unavailable, found, own cache). To my mind those should instead by constructed dynamically from the basic marker using overlays (exactly like we do with the negated attributes icons). And if we have a better infrastructure for icons with overlays, we can more easily implement (either) manually choosen (or automatically determined) markers like requested here.
about overlaying: you even don't need to put the final icon image together yourself. Android can overlay images itself. Just use FrameLayout and put multiple ImageView inside. They will be shown layered one over the other.
At least on the map this is not possible - there we have a drawable associated with the cache, not a view or anything like that. So we could construct them on the fly probably but would increase the memory-footprint nevertheless. From the user perspective I find the idea good :)
@rsudev: We would still have to create only 1 instance of each icon+overlay combination being used at runtime (which should typically not be that much). And I must admit that I would be fine with that using maybe 50 KB more RAM, if I can save 60 bitmaps from the application package on the other hand. I always use the developer version of c:geo, but this has become a beast of around 10 MB for the APK already (if you don't go through all the Ant scripting which does the whole optimization stuff, but just let the project be compiled).
I wanted just to mention that independent of how we create them, we need to make avilable and cache all icon combinations with the corresponding memory footprint increase, especially in a users homezone. But this effect has to be explored. In nay case we could try how large the runtime effect is, to create the overlayed icons dynamically and use such a method to increase maintainability and lower the memory footprint of the installation. BTW: This is why I wanted the install_release ant target :)
I just wanted to open a similar issue: label caches with modified coordinates (mysterys & multis) with an extra icon, e.g. a pencil. Then i discovered this issue ,-) The "pencil" and the "piece of paper" could be attached automatically, what about the rest ? How do you image the UI ?
"Piece of paper"(notes available) and "Pencil"(modified coordinates) would be a good start and I would like it very much. Another idea which came to my mind while doing a multi: If I look onto the maps with waypoints it would be good to have a numbering in the wp-icons reflecting the position in the wp-list.
And what's with gc-vote ratings directly in the map? And a visible D/T-rating would be great!
What I want to say: We have a details-view for the details, a map must be easy to read and unterstand (this semester I have "Geodatenvisualisierung" at university) and such details can be confusing if there are a lot. Different icons for cache-types should be enough.
But in case of caches with "Work in Progress" (Notes available, modified coordinates but not found) the visualization could be helpful in my opinion. I agree, that not we can not display each and every attribute, but this would allow catching caches you are nearby which you might not remember purely by its position on the map.
A feasible option would be at least to use the red flag marker (from the final waypoint) to mark caches that have final coordinates defined (and display them there as well). We could use the same marker for the caches with modified coordinates from gc.com.
Ok, here we go.
Yes, it's possible - we can overlay images in the Live Map. A PoC can be found here: http://www.blafoo.de/Blog/GitHubIssue752.png
The code in CGeoMap is very simple (it's just an working example !):
private CachesOverlayItemImpl getItem(cgCoord cgCoord, int icon, final CacheType cacheType) {
coordinates.add(cgCoord);
CachesOverlayItemImpl item = mapProvider.getCachesOverlayItem(cgCoord, cacheType);
Drawable marker = getResources().getDrawable(R.drawable.marker); // 33x37
Drawable tradi = getResources().getDrawable(R.drawable.type_traditional); // 22x22
tradi.setBounds(0, 0, tradi.getIntrinsicWidth(), tradi.getIntrinsicHeight());
Drawable mystery = getResources().getDrawable(R.drawable.type_mystery); // 22x22
mystery.setBounds(0, 0, mystery.getIntrinsicWidth(), mystery.getIntrinsicHeight());
Drawable star_on = getResources().getDrawable(R.drawable.star_on); // 12x12
star_on.setBounds(0, 0, star_on.getIntrinsicWidth(), star_on.getIntrinsicHeight());
Drawable waypoint = getResources().getDrawable(R.drawable.user_location); // 16x16
waypoint.setBounds(0, 0, waypoint.getIntrinsicWidth(), waypoint.getIntrinsicHeight());
Drawable[] layers = new Drawable[4];
layers[0] = marker;
layers[1] = cacheType == CacheType.TRADITIONAL ? tradi : mystery;
layers[2] = star_on;
layers[3] = waypoint;
LayerDrawable ld = new LayerDrawable(layers);
ld.setBounds(0, 0, ld.getIntrinsicWidth(), ld.getIntrinsicHeight());
ld.setLayerInset(1, 5, 5, 5, 5);
ld.setLayerInset(2, 0, 20, 20, 0);
ld.setLayerInset(3, 16, 20, 0, 0);
item.setMarker(ld);
return item;
}
All we need now is an agreement about what to display exactly.
My suggestion: Background: Marker icon in two different version: white for active cache, grey for temporarily disabled caches Center: cache type (as yet) Upper left corner: smiley for found Upper right corner: star for own caches Bottom left corner: "Piece of paper"(notes available) Bottom right corner: "Pencil"(modified coordinates)
IMHO more icons would be to much information to the user and would make the item unreadable.
Can someone help me with the icons ?
Regarding the icons: Upper left and Upper right do for my opinion not really need to be separate because own and found are XOR :-) So the own and found could stay as they are right now or occupy only one corner and save the other corner for future use. Bottom left and Bottom right sound good.
I agree, that with this visualization the maximum for the UI is reached. Nevertheless I think its a very good approach.
Aehm, own and found is not mutally exclusive ,-) Think about an event that you have organized (and visited, too) or about a cache that you have found and later adopted.
If we divide the marker into a 3x3 field we could display 9 additional informations at maximum. I think that is to much. So the question is: what is the most important additional information needed by the user ?
I've not been active here for a while, but want to add some comments:
As I wanted to be able to clearly see solved mysteries on the map I started with this as well, but from the graphical side. I created a disabled marker and overlays for found, own and 'final coordinates'. I thought it would be easiest to have them all the same size allowing the overlays to happen similar.
@rsudev Wunderful ! Just two pleas:
It would be nice if one could add visible markers/labels to a cache for showing in the map. There are already markers for found cache (smiley) and own caches (star). These new markers could be displayed on the right of the cache icon in the map, same size as smiley or star.
Concept:
In cache details one can choose one of several markers. This markers don't have an explanation, they are just images for tagging. The user can interpret and use them as he/she likes.
The marker is shown on the live map and somewhere in the cache details.