Raptor Lining the Whole Vehicle

Back in the early 90’s, there was a Bronco parked near my house that had a textured paint finish that looked like flexstone. Since then, it’s been something floating around in the back of my mind. Having a black FJ and having taken it off-road a bit, I had quite a few scratches. Add to that the typical parking lot dooring, and that was my paint’s state. Correctable but inevitable. I’ve also really despised the silver/gray bumper wings, mirrors, and door handles on the FJ.

I did a lot of research over the past year or so. A number of people have posted pictures or video of their process. This is great but I didn’t find a lot of detail and, after talking to another guy who had one of the same issues as me, I wanted to document as much as I could here.

Materials

Here’s the break down of materials with source and price.

• 8L Raptor liner, hardener, and gun (Amazon) 
• U-Pol Grip#4 adhesion promoter (Amazon)
• Xylene (Ace) $8.99
• Degreaser (Ace) $8.59
• 120 grit Sanding discs (Ace)
• 120 grit Sanding Sponges (Ace) $6.99 and $4.79
• Scotch scouring pads (Ace) $5.99
• 6pk Gloves (Ace) $2.99
• 6pk Tack cloths (Ace) $8.99
• 3pk Masking tape (Ace) $12.99
• Paper for masking (used paper Amazon includes in packages mostly and other left overs)
• You’ll also need an air compressor.

I ended up with 2 extra liters of the Raptor but I did not do my roof so 8L probably covers an FJ about perfectly.

Why Raptor Liner?

I went for Raptor because it reportedly holds up in the sun due to its UV resistance. I live in Arizona and the difference between a generic brand shade sail and a Coolaroo is one summer vs. about a decade. I’ve repeatedly learned this lesson. Here, I don’t have to worry about rust but the sun destroys everything eventually.

A word about the finish: satin. I would’ve preferred the more matte appearance of other bed liners where Raptor has more of a satin sheen but, again, the sun… .

Prep

As with painting, the time is mostly in the prep. I spent the first day cleaning, degreasing, and then sanding the clear coat. Most of the second day was spent on cleaning again, masking, and spraying the adhesion promoter.

 

Spraying

There is not much overspray and the wind seemed to have little to no effect. I sprayed from about 18” with some exception getting behind things.

Issues

Clogging

The first issue was one I had read about in Amazon reviews mostly. The gun can get clogged up and I found I had to run Xylene through the gun between each coat. For this, I used my first spent bottle of liner, put a little Xylene in it, and sprayed it through the gun. Then, after attaching the next fresh bottle of liner, I sprayed a little on some pallets to be sure I got the Xylene out.

Missed a Spot

In the end, I missed a spot where you can still see some of the effects of the sanding. I intend to either use some touchup paint or ignore it completely—it’s very hard to see.

Too Heavy

I’m not sure if it was getting too close or just hitting the same area too many times but, to get behind the door handles and mirrors, it got too thick which is noticeable. I might’ve rather have had some lack of finish behind the handles.

Leaves and Debris

It got windy right before I started spraying so some mesquite ended up landing on the wet liner. My advice is to leave it. The pieces I pulled off seemed to take some liner with it. The pieces I decided to wait on seemed to float to the surface. My guess is this is due to the off-gassing. After about an hour, I was able to just blow the pieces off.

Unmasking

Opinions vary over whether it’s better to unmask shortly (an hour) after spraying or after it’s more dry. I sprayed in the evening and unmasked the next morning (it was cold for AZ: in the 30’s F). The tape came off pretty easily but I did use a razor in a few spots—most often where the liner was thicker.

I forgot to unmask the bumper reflectors for a few days and they required some serious razoring. That was clearly too long.

Curing

It takes 5-7 days to fully cure. Even in the dryness of AZ, I avoided using the vehicle for the full 7 days although I did make a couple trips.

Final Finish

The final product is reportedly durable, flexible, and sound-deadening. I can’t say I’ve noticed the latter but I’ve made an effort to brush up against mesquite, palo verde, and creosote with no noticeable affect.

I met someone the other day who said he could attest to the ding resistance; however, apparently the dirtiness is constant. We will see.

 

 

With Rain

 

Questions?

No problem. I’ll do my best to answer or update the post.

Visual Studio 2017 hangs when stopping the debugger

I’m using Xamarin Forms and, when debugging on UWP, everything was fine; however, when debugging iOS in the simulator, Visual Studio would hang every time I stopped the debugger.

This problem was progressive. It originally manifested as no break points working and the app exiting when launched from the debugger but, at it’s worst, I had to kill Visual Studio every time a debugging session ended.

Somehow, though, debugging the Windows (UWP) version of my app worked fine.

I did a lot of searching and tried a lot of things but it just kept happening. Finally, after reading how someone thought it was related to break points and remembering how this started, I decided to delete the .suo file. Years ago, in some past Visual Studio version, this was the solution to not being able to delete break points. As it turns out, this fixed all the issues at the minor loss of some user options like which project was set to start up--well worth it.

The .suo (I read it Solution User Options) file used to sit next to the .sln file. Now-a-days, the .suo file simply has that name, is in a sub folder, and is marked as hidden. Look in this folder:

{YourSolutionFolder}\.vs\{YourSolutionName}\v15

where v15 is the major version of Visual Studio--not the marketing version (e.g., 2017).

Remember, it’s marked as hidden so you may have to change your Explorer options or delete it from a command prompt at your preference.

Transitioning from Xamarin Simulator Builds to TestFlight

Xamarin Forms gets you up and running with the Simulator or LivePlayer in no time and that’s great. Transitioning to the next step of doing builds for TestFlight, however, can be a grand and tedious leap.

I won’t try to lead anyone through this process but I will show you the walls I hit and how I got around them. This took pretty much all day today with only a bit of a break to have lunch with my daughters and build a DIY cat litter box.

Null Reference Exception in Properties of iOS Project

The first befuddlement was while going through the tutorial for reconfiguring the iOS project to use the correct profiles. Clicking on the iOS Bundle Signing item in the Project Properties resulted in a Null Reference exception in the IDE. The resolution for this one was to simply exit Visual Studio and [re]connect to the Mac.

Codesign Password

This was probably really a brain fart on my part but I could not figure out what password was being requested here. Apple Developer account? iTunes? Apple ID? A password I didn’t remember specifying when creating the certificate? The answer is simply none of these. It just wanted the password associated with the account used to sign into the Mac. This seemed silly to me because I was already, well, signed in but there you go.

Do yourself a favor and click “Always Allow” or you might find yourself staring at a build that will never complete while this dialog hovers in the background.

codesign wants to sign using key “certificate name” in your keychain.

Getting Files onto your Mac

If you’re like me and prefer editing and building on the PC, you’ll need to transfer your bundles (IPA files) to the Mac for uploading. I used iCloud and the process was very smooth. I dragged the files into an iCloud browser window on the PC and they showed up in the iCloud folder in the Application Loader’s file browse dialog. There are obviously plenty of other ways from network shares to e-mail but this seemed easiest to me since I’d only have to do it once or twice (HA!).

Application Uploader Error #1

The Application Uploader does a preliminary check on the bundle and my first problem was this:

description length: 236593
ERROR ITMS-90161: “Invalid Provisioning Profile. The provisioning profile included in the bundle name [Payload/filename] is invalid. [Missing code signing certificate]. A Distribution Provisioning profile should be used when submitting apps to the App Store. For more information, visit the iOS Developer Portal."”

Well, this is what I get for following the tutorial without thinking. At first glance, this would seem to have to do with a lack of a certificate but that is really a red herring. The “Test Flight” instructions I was reading linked to "Publishing to the App Store” which said “For detailed instructions, please see the Creating a Distribution Profile” which links to a section titled “Creating a Development Provisioning Profile”. Note the difference here: Distribution vs. Development.

The second sentence of the second error is the crux of the issue: I used a Development profile which was linked with a Development certificate which explains the first part. The solution is go back and create a Distribution certificate and an associated Distribution profile and go through the process selecting it in the various places along the way. Hopefully, you’re reading this before having done any of that.

Success (oh if only it was that easy)

Application survived the preliminary tests and uploaded to the Apple Store. Hooray for..oh wait. I just got an e-mail which said:

Missing Info.plist value - A value for the Info.plist key 'CFBundleIconName' is missing in the bundle 'net.digitalmason.time'. Apps built with iOS 11 or later SDK must supply app icons in an asset catalog and must also provide a value for this Info.plist key.

Now this is actually awesome. This is a very descriptive tidbit and was very useful in finding a fix to the problem. If you get this error, you may have to move your Media.xcassets folder to under your Resources folder. Please see the post by DavidSkowronski here.

Application Uploader Error #2

Alright. Rebuild, move to Mac, run the Uploader and…son of a…I thought I had gotten through this part.

ERROR ITMS-4238: “Redundant Binary Upload. You’ve already uploaded a build with build number ‘1.0’ for version number ‘1.0’. Make sure you increment the build string before you upload your app to iTunes Connect.

Again, this is a pretty explanatory error.  Edit your Info.plist and update the build number every time you’re ready to upload. Note this seems like a good opportunity to dig into msbuild and autoincrement this number whenever you do a AppStore Configuration build. Perhaps next weekend.

Missing Info.plist key

So…build, move to Mac, run the Uploader, and voila! What’s that? I think I just got an e-mail:

Missing Info.plist key - This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data.

And, again, thank you, Apple. This error gets you the basic info you need. If you get this error, depending on which key is referenced, you’re going to be adding a key/value something like this to your Info.plist:

<key>NSCalendarsUsageDescription</key>
<string>$(PRODUCT_NAME) uses your calendar.</string>

See here for details.

So, again, build, move to Mac, run the Uploader, and…dammit..I forgot to increment the Build Number again!

Success? Just About…

Finally, build, move to Mac, run the Uploader, success, and..waiting for e-mail..ah..(roll eyes)..there it is:

Dear Digitalmason.net, LLC,

The following build has completed processing:

Platform: iOS
App Name: Jack of Time
Build Number: 3
Version Number: 0.5
App SKU: XXXXX
App Apple ID: XXXXXX

You can now use this build for TestFlight testing or submit it to the App Store.

Hooray! Seriously, though, there was one more thing…

Missing Compliance

I’m configuring my TestFlight and seeing this daunting status that I know is going to get me:

Well, it turns out, this one, in particular, is rather nicely done. You can add the following key/value pair to your Info.plist but wait—don’t start a new build just yet!

<key>ITSAppUsesNonExemptEncryption</key>
<string>NO</string>

Now this is assuming you don’t actually use any non-exempt encryption. For more details, please see here.

As I said, you do not have to go through the whole process again.

You can choose the “Provide Export Compliance Information” and answer the questions to have your Info.plist updated in your current upload.

Success. Really.

At this point, TestFlight went smoothly and I got my early version app on some devices and, thankfully, other than one (rather serious) framework issue, it’s working nicely.

I hope this rehash of my tedious day helps some of you all get through this much more quickly.

MacinCloud for Xamarin

Resistance is well… you know… futile.

I used a Mac Mini for my Xamarin builds. It was slow and eventually crashed hard. I had to reinstall the OS, and upgrade, and upgrade, and upgrade, and upgrade. Did I mention how slow it was?

While I was waiting for the pictured reinstall and many other upgrades, I read about MacinCloud. It sounded promising but I hate adding to the monthly burn. I resisted and upgraded and upgraded and built slowly and crashed again and finally decided I’d try MacinCloud’s trial.

The Signup

The signup is quick, easy, and painless with the exception of one thing: I chose the wrong subscription for simply remote building using Xamarin. So here’s my key point: if you want to just build from Visual Studio using Xamarin on Windows, you need the Managed Server ($20/mo) but you also need the “SSH add-on” ($2.50/mo) so make sure you check that box. It is my understanding that, under this plan, you’ll be sharing the Mac with others (they’ll have their own log in of course so it shouldn’t be a problem). This plan includes the latest OS with Xcode and Visual Studio installed.

The Signin

You must be signed into the Mac in order to use the remote building capability of Xamarin. You can use Remote Desktop Connection (RDP) to connect to your Mac. They’ll send you an e-mail with a .ZIP containing some .RDP files to simply connect or you can just type in the info they send you in the e-mail. You can configure RDP to remember this info so it’s always just one click away.

The connection

Once you’re signed in, from your Visual Studio on the PC, choose Connect from the Xamarin toolbar and enter the fully qualified host name or IP address of your Mac. You’ll also have to enter that user name and password again from the e-mail. Once you’ve done this, though, you can just choose the connection again and don’t have to retype all that info next time.

Now you can build and debug using the iPhone simulator or Xamarin’s Live Player which is very cool but might warrant a separate post in its current state (beta).

Usage—Sign Out

One last thing about signing in. You need to Sign Out when you’re done building for the day and/or before you take a dinner break. You need to actually Sign Out. Don’t just close the RDP window. That may leave you signed in. The Managed Server plan has a daily time limit of 3 hours.

Exceeding Your Plan’s Usage

According to MacinCloud support:

“We have an algorithm to track user usage pattern, once the user's usage exceeds 3 hours every day, they are automatically upgraded to the tier that better reflecting their usage pattern. If user use more than 3 hours but less than 5 hours daily, they will be in the 5-Hour daily limit tier.”

To me, this seems like a very reasonable way to do things.

Amazon Alexa Doesn’t Work in iOS 11.2

Or, “My Pet Peeve About OS Version Checking”.

So, after the iOS update, Amazon Music users using Alexa found that it would just sit there seemingly not hearing them dramatically over enunciating their musical requests. At least it took me a couple tries to understand that “she” was not hearing me. It turned out that Alexa was broken (or iOS—who knows for sure?) but these things happen. I’ve had the same problem with a couple of my apps after OS updates—especially those that use hardware.

I immediately checked for an update to Amazon Music and there was one. Unfortunately, as soon as I saw the “fix” I suspected what I was in for: it appears Amazon merely replaced the Alexa function with a grammatically disturbing message. It is not the grammar that upsets me.

"We're Sorry, Alexa is temporarily broken on iOS 11.2. We are working on a fix."

So now it appears that Amazon Music is checking the iOS version and, if greater than or equal to 11.2, displaying a message. So what happens if Apple fixes the problem? The Amazon Music app would still be coded to display this message instead of trying to perform the desired function. Now, I can’t say for sure that they are not checking in some other way but this is precisely the kind of fix to a problem that just further complicates the problem. Given the poor (presumably hastily created) message, I feel more confident this is that kind of fix.

I’d rather they just left the app alone and let it try to work. If they needed to let customers know they were working on it due to the volume of complaints, throw in a message but, again, still try the Alexa functionality.

UPDATE: And, moments after finishing this rant,

my phone asks me if I want to update to 11.2.2. With great hopes, I am performing the update.

Why am I so excited about Alexa in Amazon Music? Mostly because Siri keeps saying “I’m sorry. I don’t think I should do that while you’re driving.” Alexa, up until recently, would happily play my musical requests in the car—the only place I use the Alexa feature of Amazon Music.

Okay. Update complete. The message is still there with no Alexa functionality and there’s not yet an Amazon Music update. I am mildly satisfied that my suspicions were correct but more moderately upset by the situation.

"We're Sorry, Alexa is temporarily broken on iOS 11.2. We are working on a fix."

So I’m forced to emit a first world sigh and do what I should have done to begin with: create a playlist. Oh, the humanity!

UPDATE (01/25/2018): Another update is available

So another update for Amazon Music is available.

After the update, because I’m still on iOS 11.2.2, we get the same message.

After installing iOS 11.2.5 (which required uninstalling many apps—I only have 16GB), we finally have Alexa in Amazon Music again.

Hoorah!