Customer wants to know why some drawables are commented out in TiFileHelper.java, there are:
if (systemIcons == null) {
systemIcons = new HashMap<String, Integer>();
systemIcons.put("ic_menu_camera", android.R.drawable.ic_menu_camera);
//systemIcons.put("ic_menu_compose", android.R.drawable.ic_menu_compose);
systemIcons.put("ic_menu_search", android.R.drawable.ic_menu_search);
systemIcons.put("ic_menu_add", android.R.drawable.ic_menu_add);
systemIcons.put("ic_menu_delete", android.R.drawable.ic_menu_delete);
//systemIcons.put("ic_menu_archive", android.R.drawable.ic_menu_archive);
//systemIcons.put("ic_menu_stop", android.R.drawable.ic_menu_stop);
//systemIcons.put("ic_menu_refresh", android.R.drawable.ic_menu_refresh);
systemIcons.put("ic_media_play", android.R.drawable.ic_media_play);
systemIcons.put("ic_media_ff", android.R.drawable.ic_media_ff);
systemIcons.put("ic_media_pause", android.R.drawable.ic_media_pause);
systemIcons.put("ic_media_rew", android.R.drawable.ic_media_rew);
systemIcons.put("ic_menu_edit", android.R.drawable.ic_menu_edit);
systemIcons.put("ic_menu_close_clear_cancel", android.R.drawable.ic_menu_close_clear_cancel);
systemIcons.put("ic_menu_save", android.R.drawable.ic_menu_save);
//systemIcons.put("ic_menu_mark", android.R.drawable.ic_menu_mark);
//systemIcons.put("ic_menu_back", android.R.drawable.ic_menu_back);
//systemIcons.put("ic_menu_forward", android.R.drawable.ic_menu_forward);
systemIcons.put("ic_menu_help", android.R.drawable.ic_menu_help);
//systemIcons.put("ic_menu_home", android.R.drawable.ic_menu_home);
systemIcons.put("ic_media_next", android.R.drawable.ic_media_next);
systemIcons.put("ic_menu_preferences", android.R.drawable.ic_menu_preferences);
systemIcons.put("ic_media_previous", android.R.drawable.ic_media_previous);
systemIcons.put("ic_menu_revert", android.R.drawable.ic_menu_revert);
systemIcons.put("ic_menu_send", android.R.drawable.ic_menu_send);
systemIcons.put("ic_menu_share", android.R.drawable.ic_menu_share);
systemIcons.put("ic_menu_view", android.R.drawable.ic_menu_view);
systemIcons.put("ic_menu_zoom", android.R.drawable.ic_menu_zoom);
}
Any news on this? Or there is any way to overcome this from javascript or a module without recompiling the sdk? Thank you.
The Customer needs this feature within two weeks.
Seems reasonable. Scheduled it for 3.4.0. If it's easy, we could move it into 3.3.0.
I've asked [~jhaynie] since GitHub says he's to blame ;) https://github.com/appcelerator/titanium_mobile/commit/a90cd6dd0b5c124b7a6f0157522e93e659c06527#commitcomment-11155327
Just more information on this. Google has cool new design icons with material look and feel. https://www.google.com/design/icons/ I don't think it should be built into the Titanium SDK and the user should instead download what they need from there and use it.
I'll be marking this as 'won't fix' if Ash's proposal makes more sense. Please let me know before end of sprint if anyone feels otherwise.
It's not that these icons are built into the Ti SDK. These constants refer to system icons, built into the Android OS and typically themed by the handset manufacturer (to match their skin, i.e. TouchWiz). They provide a common set of icons to use across devices without the need for the app developer to create icon files in multiple resolutions, bundle those assets into his/her app (increasing APK size), and have to worry about skinning issues (default system colors, which might make an external icon poorly visible in some manufacturer's skin theme). What is in the Ti SDK is a set of constants that map to the Android constants which point to the actual resources installed on the user's device. All that needs to change here is to update (un-comment) that list of constants to be sure the Ti SDK maps 1-1 to the Android constants. I believe this is a separate matter than downloading and using Google's new icon set. Now, if you really wanted to make things convenient for the Ti developer, you would include these new Google icons in the Ti tooling but not bundle them into the APK automatically unless the developer used one of them via some new constant or mechanism you create. That would be _in addition_ to exposing all of the drawables constants, though.
[~skypanther] is right that these icons exist on the user's device anyway and all we do is expose the constants, so it doesn't bloat the sdk/api in any way. We should just change the logic here: https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/util/TiFileHelper.java#L169-L175 https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/util/TiFileHelper.java#L409-L416 To do a dynamic lookup with
android.R.drawableinstead of the static map here: https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/util/TiFileHelper.java#L95-L125 Then we never have to worry about it again.Just checked on the commented out variables. They don't exists in the Android sdk. https://developer.android.com/reference/android/R.drawable.html That's why they were commented out.
Ah, sorry, I didn't do such a comparison. In the end, Ti should have constants for all the drawables that do exist for the Ti-supported Android API levels. See http://androiddrawables.com/ for a visual list. If what it has already is the full list, that would make this ticket invalid.
It does not have the full list (https://developer.android.com/reference/android/R.drawable.html) and because of the constants changes Android does I suggest we map them dynamically somehow.
I agree that dynamically might be the best way, since, as Fokke mentioned, the drawables change based on the Android version.
The set of icons disabled across Android releases is *intentional*. Read this https://groups.google.com/forum/#!topic/android-developers/2rvmKqG1TBM So Google actually recommends copying the icons to the app and use them (they don't seem concerned if the apk gets a little fatty). The real problem I see here is how do you maintain this across future releases? For example, ic_menu_refresh is completely removed from Android 23 SDK resources. If we dynamically add these icons, then we are bound to support it for future releases and in some case there is no icon to copy from (and we cannot copy icons from older Android resources since they have different look and feel). Commenting out these icons is in accordance to platform behaviour. If developer wants they can copy over to res and use them. So lets relook if we should really support these icons in a unrecommended way.
Mmm, makes sense. But then we might even consider deprecating (without any intention to ever remove)
Ti.Android.R.drawableand add a note that this is considered a bad practice by Google.I see your point on this change and agree the ticket as originally written should not be implemented. But, how about at least making it easy and reliable to use density-specific image assets on Android? The current documentation is a jumbled and confusing mess. Cripe, I wrote 90% of what's in those docs and I still find that it's nearly random luck that I get the images into the right folder in the right spot to get them to actually work! Developers need to decipher whether images go in platform/android/res, or app/assets/android, or app/assets/android/images, and are those folders named res-high or res-hdpi or res-drawable-hdpi etc. Not to mention needing to know what dimensions and dpi each of those resolutions should be. The explanations for all that are spread all over, and somewhat contradictorily covered in the docs. Clear documentation and a good example would help a lot. But how about a tool in Studio that puts the graphics in the right spot for you. Even better, a generator that you feed some high resolution version which then generates all the correct down-res'd versions you need. For icons, how about some import tool that lets you go out to Google's icon repository, select the icons you want, and then downloads them and puts them in the right folders. There are lots of things that could be done to make this process easier.
Come on [~timpoulsen], you can do better! That's not a rant, that's a bunch of good ideas! :D I must say I've never gotten confused with the place or folder-name of images. I always just use
app/assets/android/images/res-<dpi>unless I'm told otherwise (launch image, icon...)Marking ticket as won't fix, and creating a new one to address deprecation documentation. Thanks [~skypanther], will definitely look into your comments as a separate ticket.
Closing ticket as Won't Fix with reference to the above comments.