Categories
Uncategorized

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="http://xamarin.com/schemas/2014/forms"
        xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
        xmlns:views="clr-namespace:GalleryApp.Views"
        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}}"
        x:Class="GalleryApp.AppShell">

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}" />
</Style>

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.

Categories
Uncategorized

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.

Categories
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.

Categories
Uncategorized

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 192.168.0.30 to your phones IP address.

@echo off
echo starting
::ENTER YOUR CODE BELOW::
echo Android bits
cd C:\Program Files (x86)\Android\android-sdk\platform-tools
adb -s 227bef7922047ece tcpip 5555
adb -s 227bef7922047ece connect 192.168.0.30:5555
::END OF YOUR CODE::
echo Finished
pause

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.