Apps Crypto

Xamarin & Metamask Mobile

NFT Gallery is going from strength to strength. One issue I have with it though is the user having to paste their Ethereum address into the wallet page. As anyone can paste any public wallet address, you can have anyones collection on your phone. So I have been thinking how to integrate Web3 tech into the app.

Web3 means cryptocurrencies, blockchain technology and the one problem is that it mostly lives in web browsers. Most people who use Ethereum access it via the Metamask browser plug in. In the mobile world you can’t really have plug ins and so Metamask exists as its own app, Metamask Mobile (or MMM for short). This lets you manage your accounts and interact with Dapps via the built in browser.

So how do you get two apps to talk to each other? The answer is deeplinks. MMM has a couple of deeplinks that allow you to trigger things in the app. One is to open a Dapp (or a website). The trick is to open a webpage in MMM, get the users Eth address and then trigger a deeplink back into your app. Luckily I know a smattering of Javascript and had played with deeplinks on a previous project.

Deep link communication loop

First of all you create a web page on an https web server. Mine is here. The gist of it is that Metamask injects a javascript object called “ethereum” into the web page and the code interacts with that. Debugging it on the desktop was quite easy but in the app, it worked slightly differently. To debug you need to build your own debug version of MMM and remotely connect from the desktop to view your javascript. I got it working though.

To call MMM and get it to run your code you do something like this in c#.

await Browser.OpenAsync($"" + AppName);

This opens a url on the device, which opens the deeplink into the app, which in turn opens your web page in the browser tab. In this case Web3Metamask.htm. Currently I pass one parameter in which is the start of the url that calls back to my app.

Then it is simply a case of overriding the OnAppLinkRequestReceived in your App class and processing the URI that was passed back into you.

    protected override void OnAppLinkRequestReceived(Uri uri)

        string url = uri.AbsolutePath;

        var bits= url.Split("/",StringSplitOptions.RemoveEmptyEntries);

        switch (bits[0])
            case "address":
                string address = bits[1];
                App.SettingsViewModel.UserAddress = address;




And now you have your eth address. In the next post I will show how to get details of NFTs from OpenSea using their API.


Dark Mode for Xamarin Apps

This week I have mostly been trying to get Dark Mode working with one of my Xamarin Forms Shell apps. This is the new feature available on most mobile OSs where the screen goes white on black (rather then black on white) to reduce glare at night. There is no “out the box” solution but after much googling and a bit of fiddling I found something that works.

There were three main changes I had to make to get it working.

  1. Modify the Shell part of the app.
  2. Modify the content of the various ContentPages.
  3. Modify the splash screen.

Starting with points 1 & 2, I referred to these two posts for their approach. Read them but bear in mind I had the following issues. The general idea is that you have two resource dictionaries, one for the light screen and one for the dark screen. The elements have the same names so you can swap them over at run time and it applies the new colours to the existing controls.

Shell & ContentPages

I am quite new to using StaticResources. Hot Reload is great as you can edit the XAML and see it update on the device. This light/dark approach means that the resources are compiled and switched at runtime. This means Hot Reload doesn’t work as the XAML doesn’t have a direct “live” link to the app. This just means you have to get it all looking nice with the XAML as part of the app or page and then copy it to the light/dark ResourceDictionary when you have finished. You might also want to separate out and DataTemplates into another ResourceDictionary that uses the other two.

I also found that this process didn’t work for the Shell objects themselves. by that I mean the UI that presents itself when the app starts up. Navigation bars and Tab bars, but not modal pages. In these cases I defined the Shell colours like this.

<Shell xmlns=""
        BackgroundColor="{AppThemeBinding Light=SteelBlue, Dark=Black}"
        ForegroundColor="{AppThemeBinding Light=White, Dark=White}"
        TitleColor="{AppThemeBinding Light=White, Dark=White}"
        DisabledColor="{AppThemeBinding Light=Green, Dark=Green}"
        UnselectedColor="{AppThemeBinding Light=LightGray, Dark=DarkGray}"
        FlyoutBackgroundColor="{AppThemeBinding Light=White, Dark={OnPlatform Gray, iOS=Gray, Android=LightGray, UWP=Gray}}"

While in the content pages definitions it was used as

<Style TargetType="NavigationPage">
    <Setter Property="BarBackgroundColor" Value="{StaticResource NavigationPrimary}" />
    <Setter Property="BarTextColor" Value="White" />
    <Setter Property="BackgroundColor" Value="{StaticResource BackgroundColor}" />

Also occasionally I needed a DynamicResource instead of a static one. Half a template would update and half wouldn’t. Also it pays to check ALL of your screens work.

Splash Screens

These aren’t essential but are nice to have. Especially if your existing splash screen is light and bright. For this I mainly used this blog post as a reference. It explains everything you need to know , but as I had done a splashscreen before this was fairly familiar. The only thing I had trouble with was editing the iOS storyboard. I ended up adding the ViewController in XCode rather than in Visual Studio.


Build Discrepancies

I have just released version 1.0.2 of OpenSeaGallery. If you looked you will see the Android version was out about a week before the iOS one. I has them both set up in The AppCentre and when I tried pushing the new versions, iOS gave me some fairly serious errors.

Now you have to upload the first version into the Apple app store via the visual studio uploader. It only really handles updates and not initial releases. I had updated a few nugets and stuff like that but the app store sent me an automated email stating I was using some private APIs and UIWebView was depreciated. None of my changes were that drastic and the first version had gone through fine. I swapped out the Chromecast library for a better one and updated all the nugets again. I re-submitted it about ten times and it still came back with that error.

Then I thought, visual studio uploaded the first version fine, so what about the second? I fiddled about with my profiles and certificates and what do you know? Version two uploaded fine. It is now available on the store. This means there is something about my project that causes the AppCentre to build it differently to visual studio.

Where do you start? I guess it must be something in the project file or the references that is causing the issue. I tried googling it and making changes like this but to no avail. I think my only option is to rebuild the iOS project file again from scratch, comparing it with projects I know that do work.

Apps Uncategorized

All About The App

By the look of it, Comic Chameleon, the only other web comic app out there has called it a day. There has only really been them and WebcomiX and now they are gone.

From what I gather, they took a fairly different approach to comics than we did. They scraped the comics from the artists websites and in return promised a % of revenue. I don’t know how many active users they had but to pay themselves and 100+ comic creators must have been tricky.

One thing that we can learn from them is that if you are in the app market space, then it is ALL about the app. You can have brilliant ideas and the best of intentions but if the app isn’t front and centre then you are lost.

To begin with they started off as an iPhone only app. Not only that but they picked the wrong technology to make their app. There is no excuse for not supporting tablets these days. However when you installed it on an iPad you just got the system 2x blow up of the iPhone version. I am guessing they used one of those iOS/HTML/CSS hybrid systems that were popular in the early 10s. I am also guessing they didn’t have an in house programmer as they only did ten updates in seven years.

Then five years ago they did a Kickstarter to raise money for the Android app. Whatever tech they were using obviously wasn’t cross platform. They now had two apps to maintain and add features to. Even five years ago it would have been possibly to write an app that was both modern and cross platform, rather than a pure android one. they should have bitten the bullet.

Finally their app may have been a bit too high maintenance. Like comixology, it did the thing where you could read a comic one panel at a time. I am guessing someone spent a lot of time counting panels and adding it to the database. This also made the app a bit confusing as different things happened depending on where you swiped or tapped.

I will admit WebcomiX has got a bit lax at times. However there is a new version of iOS and Android every year that usually breaks something. There are new screen sizes and UI paradigms (?) to consider. There are even new things that your development tools add that can be used. The upcoming 3.1 release of WebcomiX builds on a lot of features added to Xamarin.Forms 4. One, it is a new version and you have to move to it at some point. Two, the deep linking means you could launch comics from notifications and the Home search bar. No one asked for it but they are getting it.

Still, it is a shame to see another app bite the dust after all these years. While we did the same thing, I don’t think we were ever competitors.


WiFi Android Debugging

I have a Galaxy S9. It works but the USB-C connector is a bit loose. I have had it replaced once and do most of my charging via a mat. However I still need the connector for deploying and debugging apps.

Well, it turns out you can deploy and debug via wifi. It is dead slow but it works. I got most of the details form here and here. Once you have your batch file correct, you run it and your phone magically appears as a launch option in Visual Studio.

First get the IP address of your phone from

Setting->Connections->Wifi->Current Network->Settings

and your device name from the Stack Overflow link. In my case I had emulators running as well as my phone so it is easier just to hardcode the command to work on your phone. Put the following into a batch file and change 227bef7922047ece to your device name and to your phones IP address.

@echo off
echo starting
echo Android bits
cd C:\Program Files (x86)\Android\android-sdk\platform-tools
adb -s 227bef7922047ece tcpip 5555
adb -s 227bef7922047ece connect
echo Finished

Then connect your phone via USB, run the batch file, unplug the USB and check Visual Studio. As I said earlier, it is dead slow but you can do most of your debugging in the emoulator and just deploy the odd build this way.

More detail here.