If you are using EF.Core in Xamarin, the Xamarin.iOS linker needs to exclude various BCL classes in order to properly function.
Include this Linker.xml in your Xamarin.iOS head project to ensure the linker doesn’t remove any of the required dependencies!
https://gist.github.com/dylanberry/081ba2ffb55e37d5d05f7588be3178cc
TLDR: Add HttpTracer to your project and pass a new instance to HttpClient for Fiddler-like http audit/debug capabilities.
About a year ago, Daniel John Causer, Chase Florell and I decided that some code that I was using to inspect HTTP traffic in my Xamarin apps should be an open source library.
The code was simple enough, a simple DelegatingHandler that you can pass into your HttpClient instance and it would print your app’s http traffic to your debug output. The output would contain the method, url, headers and content for both requests and responses.
After working through issues with the initial implementation and the learning curve with releasing a library to the general public via nuget (this was a first for Daniel and me), we at last had a solid library that worked as advertised out of the box.
We were aware that the library wasn’t perfect and shipping it in a production app bordered on irresponsible. Logging all http traffic from your app is a heavy operation and a potential security risk. I decided to build out a feature that would fine grain control over what was captured and logged.
I started by building a spec: https://github.com/BSiLabs/HttpTracer/issues/34#issue-421978732
After some excellent suggestions from Allan Ritchie and Chase Florell, I built out the verbosity features and published a package to Myget. From there, I was able to test with several real apps to ensure that the library was functioning properly. I fixed my issues, republished, retested and pushed HttpTracer 2.0 on Nuget!
Working on this project has been an excellent learning experience. Owning and maintaining my first open source application has taught me many things about testing, designing libraries for public consumption, nuget packaging, multi-targeting and more.
We are now discussing some wishlist items, like being able to tie into some of the existing logger interfaces that are a part of .NET (currently you would need an adapter class).
I also took some time to try the framework with Blazor. It was a great learning experience as well, being able to work with .NET Core 3.0 for the first time and WASM too! After some stumbles, I was finally able to get HttpTracer working in a small Blazor app, it’s less useful in the context of WASM since you can just use the network tab in developer tools to inspect requests, but it’s still really cool to see the library working with a cutting edge platform!
Check out the gist for Blazor here: https://gist.github.com/dylanberry/8cf04c591ebf81f46a197855316012fe
Thanks for reading and if you have any feedback on HttpTracer, please let me know!
I was asked to list out the mobile development podcasts I listen to, so here they are!
I’m going to speak from experience here because it’s been a long road. The first 2 years I worked on Xamarin and mobile projects, I used a Windows machine, it was a decent laptop with an Intel Core i7 chip, 16 GB of ram and an SSD, not bad, right? Well, for any other task, yeah, it was perfect, but for Xamarin, it struggled. Loading solutions was slow and deploying/debugging with Android emulators was glacial. Debugging iOS was a huge pain; yes, Visual Studio has the ability to connect to a Mac build agent, but it’s unreliable, buggy and requires an exact version match. Too many moving parts.
I took the plunge about 2 years ago and began using a MacBook Pro full time and let me tell you, it has been a huge improvement. Visual Studio for Mac is fast and lightweight, you can run/debug iOS and Android on one piece of hardware and it’s really fast to deploy to the iOS Simulator. Switching provided a massive boost to my development productivity.
Furthermore, I didn’t even have to turn my back on Windows, I can dual boot with Bootcamp and run Windows inside a VM using Parallels. The best of both worlds!
With almost 3 years of full time macOS use behind me, here are my observations/recommendations to help ease the transition from Windows/PC to Mac.
Hardware – I have a MacBook Pro (Retina, 15-inch, Mid 2015). I ordered this laptop in early 2016 when the newer models were announced. Looking at the benchmarks at the time, any performance benefits from the marginal CPU upgrade in the new models were far outweighed by the cons (lack of connectivity ports, no dedicated power port, bad keyboard). No regrets, this machine is a workhorse, decently fast, good battery life and handles a VM nicely.
Peripherals – In my home office, I use a DisplayLink USB 3.0 dual HD dock to drive twin 24″ 1920×1200 monitors that flank my laptop stand. This dock always worked wonderfully with my Windows machines, but was always a bit finnicky with my Mac and had much higher latency than plugging in the display directly. Since 10.13 “High Sierra” I have abandoned the display capabilities of the dock completely. High Sierra implemented changes which broke the dock’s capabilities. I now plug in both monitors, one to HDMI and one to mini DisplayPort. Frustrating to manage all the cords/connections, but the displays have lower latency with a direct connection.
Networking – macOS has no concept of a metered connection like Windows or Android. If you spend any amount of time using a portable hotspot/tethering/limited wifi, you will want to grab TripMode. If left unchecked, your Mac (and it’s applications) will treat all your connections like an unlimited, high-speed link which will cost you time and money.
Virtual Desktops – “Spaces” work relatively well. There tends to be a few bugs and hiccups, but they’re certainly handy.
Window Management – You’re going to miss Window’s snapping features more than you will ever know. Get a replacement, I recommend Magnet. Windows users will also need to get used to the fact that the “Maximize” doesn’t exist and the green button in the top left of the application title moves the application to a dedicated space/virtual desktop. You can split the screen in full screen spaces similar to snapping, but it’s restrictive and irritating.
Google Drive – the new Google Drive File Stream is generally ok. You will want to close it if you’re on a slow/unstable connection as it tends to start eating CPU.
Office – Microsoft’s Office for Mac is adequate for most tasks. Excel lacks a lot of the features necessary for manipulating large datasets and there is no Visio for Mac (try draw.io for basic diagrams). Outlook has been a trainwreck over the last few releases and I’ve taken to angrily tweeting about it:
The last few @Outlook for Mac updates have made me want to throw it away and find something better. Crashing/hanging/eating CPU+memory, switching from mail to calendar view fails often, can't drag calendar appointments (when I can get to calendar).
— Dylan Berry (@dylbot9000) March 8, 2019
Parallels – Don’t bother with any other VM software, pony up the cash and buy Parallels Desktop
Bootcamp – This is still relevant here are my recommended steps for setting up Windows on your Mac:
Using the tools and techniques described above can help your productivity on a Mac. Overall, the switch will be a bit rocky if you’re unfamiliar, in the end you will move much faster and ship your apps sooner by using a Mac!
More to come next time when we talk about IDEs and development tools.
Here we go, another attempt at blogging!
So much has happened since I last wrote, 3.5 years ago. I have been running a user group, Toronto Mobile .NET Developers Group for the past 18 months and it has been a fantastic experience. Organizing a user group/meetup can be a lot of work and it is very rewarding. I have met so many brilliant and awesome people, learned how to organize and promote the events and picked up some great skills.
As part of the group, I have been presenting regularly at my group and others. Presenting tends to play to my strengths, I can be informal and casual and I get immediate feedback from the community. That being said, text is powerful; it can be skimmed, indexed, quoted and referenced much easier. With that in mind, I am going to give blogging a more serious, earnest effort moving forward.
Now, all that being said, I will be speaking/presenting at the upcoming events:
https://www.meetup.com/TorontoMobileDevelopers/events/xjskmqyzdbzb/
https://www.meetup.com/TorontoMobileDevelopers/events/xjskmqyzfbzb/
https://www.meetup.com/Rochester-Xamarin-Meetup/events/258947374/
Late last week, I had an untimely incident with my phone. Right before my sprint review, a mug fell a mere 3 inches on my OnePlus One cracking the screen causing the digitizer to stop functioning.
This was the first phone which I have ever broken. I don’t use a case and I take good care of my hardware, generally I will use a phone for 2-3 years. Very frustrating, considering I didn’t even drop the thing. Additionally, this was a replacement phone, my first OnePlus One had a defect, this one was only 3 weeks old!
Anyhow, in a panic, I ordered a 3rd gen Moto G, it cost me $260 off contract, delivered to my door. I have been using it since Wednesday and I must say that I am very pleased with the device. Sure, the OnePlus One is a bit snappier and allows you to keep more apps in memory, but for a budget smartphone, I would highly recommend the Moto G.
In my last post, I noted the following:
We are planning on using the master-detail view for the Android version of the app while following the material design guidelines. For iOS the app will use a tabbed bar along the bottom of the screen and a settings icon in the navigation bar.
I had made this decision after I had put together a proof-of-concept app using the master-detail view, slapped a nice coat of material design paint on it and paraded it around to a few people for some feedback. It looked really nice, shiny…at least in Android, but not to worry, I could make some OS specific adjustments for iOS. It seemed like a good direction.
Yesterday, I took my proof-of-concept app, picked out the pieces I needed and rolled them into my actual app. The Android app was to have a navigation drawer (master) which slid over the tab page (detail). I spent the morning pulling everything together, applying the theme, adjusting colours, testing, then finally, I implemented the tabs in the detail page. This is what the result looked like:
Where I expected the master navigation drawer to slide over the toolbar and tabs, it instead only slid over the detail page. This is particularly problematic since not all of the detail pages use tabs.
I found numerous posts of this behaviour and a Xamarin bug report. Apparently it’s expected behaviour and will not be fixed.
I guess it’s back to the drawing board for the navigation…sigh.
We had the sprint retro for our first 2 week iteration and did not have much to show for it. The learning curve of Xamarin, plus time for planning and time stolen by other projects caused the velocity to make a major hit. Only 4 of 8 story points were completed in sprint 1, the remaining 4 story points were pushed into sprint 2. Nevertheless, we did have something to show for it, a working app, themed to meet the client’s needs with login and data retrieval functionality which was integrate with the real life backend.
There is quite a bit of learning left to do. We are working to find a good navigational flow for the app while ensuring it is visibly pleasing and meets the UI guidelines of both iOS and Android. We are planning on using the master-detail view for the Android version of the app while following the material design guidelines. For iOS the app will use a tabbed bar along the bottom of the screen and a settings icon in the navigation bar.
A couple of notes here. I am constantly working between a “test project” and a real project. The test project gives me the opportunity to experiment with various UI changes such as styles, controls, flows without impacting/polluting the real project, a way to make mistakes with little cost. Second, I have ran into this build issue with the default Xamarin.iOS project multiple times and thought it would be a good idea to share it.
Over the past 4 days, I have been working with Xamarin here and there. I’m starting to get the lay of the land, and I may actually have some things of value to share. Here’s a quick braindump:
That’s about it for now, just some quick tips from the trenches.
Since iOS development requires a Mac, I have decided to look at the Hackintosh-on-a-VM route.
Here are the resources I used to get up and running:
Main guide – http://www.macbreaker.com/2015/01/virtualbox-yosemite-zone.html
Troubleshooting – http://givemesome.tips/guide-to-fix-most-common-problems-with-hackintosh-347/
Personally, I encountered a few different issues which the Troubleshooting guide helped me fix. I now have my VM up and running and ready for Xamarin configuration!
