Support custom fonts in Host Config on Android

[matthidinger]

If an app has a custom font packaged within their app, the Renderers needs a way to load that custom font from the host config.

iOS already supports custom fonts, but Android doesn't and would need a new API for hosts to register their custom font.

[andrewleader]

Closing as inactive and no customer requests

[patgoley]

As a user of Adaptive Cards, this feature is crucial to me. Fonts are an essential part of consistent branding and styling. The behavior here is currently inconsistent between platforms. On iOS, custom fonts are registered by the app and from there, they are loaded the same way as system fonts. So the iOS renderer does in fact support custom fonts by default. On Android, however, a font assets that is bundled in the .apk must be loaded via Typeface.createFromAsset rather than Typeface.create, which is used by the TextRendererUtils class. So custom font assets don't work on Android. Unfortunately, this is a deal breaker for my design team, and if affordances won't be made in this repo for custom fonts, I'll have to fork.

Please consider the following change to TextRendererUtil.java to add custom font support. This would allow clients to register a custom Typeface under a given name. When getting the typeface for a particular font family, we check against the registered typefaces before falling back to system fonts.

    private static Map<String, Typeface> customTypefaces = new HashMap<>();

    public static void registerCustomTypeface(String name, Typeface typeface) {

        customTypefaces.put(name, typeface);
    }

    
    static Typeface getTextFormat(HostConfig hostConfig, FontType type)
    {
        String fontFamily = hostConfig.GetFontFamily(type);

        Typeface typeface;
        if (fontFamily.isEmpty() && type == FontType.Monospace)
        {
            typeface = Typeface.MONOSPACE;
        }
        // check against custom registered typefaces
        else if (customTypefaces.containsKey(fontFamily)) {
            typeface = customTypefaces.get(fontFamily);
        }
        else
        {

            typeface = Typeface.create(fontFamily, Typeface.NORMAL);
        }

        return typeface;
    }

Would the Adaptive Card maintainers consider adding something like this to the SDK? Thanks for your time.

[andrewleader]

Thanks @patgoley, that seems like an excellent addition, @shalinijoshi19 and @almedina-ms can we look at adding this to Android? Seems like an easy fix :)

@patgoley, when would you need this support by to avoid forking? Also just out of curiosity, do you mind sharing how you're using adaptive cards? Sounds like you're rendering them in your own apps? :)

[patgoley]

Wow, thanks for the positive feedback! Honestly, I've already forked and made these changes. I'm happy to submit a PR (it's basically what I've pasted above, haven't updated the test suite). I would've already shipped it by now, but I'm having trouble building the forked repo using Jitpack (https://stackoverflow.com/questions/56859420/fork-a-monorepo-and-build-a-subdirectory-using-jitpack/56859614#56859614). Separate issue, I think the answer there may be a good temporary solution.

The company I work for is building a chat bot centered application. We have developed quite a few custom card types ourselves, but each one has a static layout and other limitations. We're integrating Adaptive Cards to hopefully use as our singular card type which should be flexible enough to handle all of our use cases. It's been working great so far, this font issue is the last hold up on shipping this feature!

[andrewleader]

I think a PR would be awesome, but I'll leave that decision up to @shalinijoshi19 and @almedina-ms (our dev lead and Android dev) for the final call :)

We also might be able to help with the jitpack issues, I don't know how much Alberto knows about jitpack, but maybe there's something we can do if you don't get anything working!

That's so cool to hear about your company's chat bot app! One off-topic question while I have you - what have you done for supporting actions? Did you use Action.Submit and you're handling actions with inputs through that? We've been looking into how we can unify actions so that an author can write a single action that works everywhere. The most likely candidate is an Action.Http which the author specifies a URL callback and when clicked, the card does a HTTP POST, including the input values, to the URL, and then the author's server can respond back with new content. Would that universal action model be helpful to you? Or no need for your scenarios?

[patgoley]

Thanks for the feedback! I've opened a PR with my changes so you can have a look and make a decision about how to proceed, if at all.

Regarding jitpack, if you can provide any assistance that'd be amazing. If not, I think I can work around it by building my fork into a .jar and including that in my host application. I'd posted the wrong link to my SO question, I've edited my previous comment with the right link. It's here: https://stackoverflow.com/questions/56859420/fork-a-monorepo-and-build-a-subdirectory-using-jitpack/56859614#56859614

Regarding actions, Submit and OpenUrl are enough to cover our use cases. For OpenUrl, we just open the content in a web browser. For Submit, we pass the button title as a message to our bot and the bot engine does whatever it needs to from there. I could see how an HTTP post might be useful to other applications, but I wonder about endpoints that required an auth header or similar that I'd need to inject into your POST request.

[andrewleader]

Awesome, one last question, are you using Bot Framework or is the "bot engine" your own bot engine you've built?

[patgoley]

It is our own bot engine.

[shalinijoshi19]

@almedina-ms can you work with @patgoley to get this looked at? Thanks!

[almedina-ms]

This fix was merged by @patgoley and a sample was recently merged