Comments

There are some useful defaults we could have for app icons. Place an icon in /assets/icon.png, and it gets used.

But it turns out there are many icons. Android has an arbitrary number of potential sizes, depending on the DPI of the screen. iOS has a series of fixed sizes. Both also have much larger store icons (1024x1024 and 512x512).

Given the large number of android combinations, automatic scaling might make sense. However users may need the ability to provide multiple icons, as small images often require artistic adjustment to the number of pixels. One possibility is /assets/iconUxV.png.

hyangah
changed the title
mobile: icon support in gomobilex/mobile/cmd/gomobile: icon support in gomobileMay 7, 2015

This comment has been minimized.

edited

There's so many ways to go about this. As a lowest common denominator, simply having an assets/icon.png would perhaps, unsurprisingly, make the majority of people happy. This could require an asset at 1024x1024 and scale.

As an addition to this, it may be reasonable to allow someone to tweak how scaling is done with a name modifier, e.g. assets/icon_bilinear.png or assets/icon_lanczos3.png. Sometimes a different algorithm is enough to produce suitable results.

With regards to platform specifics, things may get a little crazy when trying to remain platform agnostic. For example, Android defines the mipmap resource directory specifically for defining icons where assets provided may be displayed larger than what is normally provided in a drawable qualifier (mdpi, hdpi, etc) for cases where something like a home screen may display icons larger than what was intended by the system.

With things like this in mind, I don't think it would be unreasonable to allow finite control over defining icon resources to assure the app is presentable for it's intended audience, but this does push against the grain of platform agnostic behavior with gomobile.

With regards to Android, I'm unaware if simply packing the icons in the apk is enough (that'd be great). I suspect that a resources.arsc will need to be generated to identify the drawables for their intended configurations, such as with internal/binres.

Provides support for resources.arsc generation enabling
the setting of an application icon.
If an asset/icon.png is encountered during build, then
the resources.arsc is generated to identify a single
xxxhdpi resource and the manifest will be updated to
reference resource as app icon.
References golang/go#9985
Change-Id: I9ef59fff45dcd612a41c479b2c679d22c094ab36
Reviewed-on: https://go-review.googlesource.com/30019
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

This comment has been minimized.

This comment has been minimized.

@rucuriousyet this push added the ability to generate resource tables for apks which is then used for the simplest form of icon support, picking up on an assets/icon.png file and packing it into the android apk as an xxxhdpi mipmap. From there, the android system provides scaling for different densities.

It's desirable to support specifying the icon for each density and this pushed removed technical hurdles related.

It's also desirable to support iOS but I don't have the requisite hardware to test an implementation. From what I read a year ago, my impression is iOS support would be comparatively trivial.