James Montemagno: Xamarin Studio: Obliterate Output Paths (bin/obj)

Recently, I have fallen in love with Xamarin Studio add-ins and in my last blog post I took a look at how to edit markdown files easily. I was at Google I/O last week with Jérémie Laval and Jon Dick and he was working on binding the new awesome support libraries from Google and Jérémie and I saw Jon do something interesting…. Obliterate Output Paths from inside of Xamarin Studio’s context menus. 

Immediately, we wanted to know exactly what Jon just did and how do we get this?!?!? Jon told us that he often has to ensure that the bin/obj folders are deleted completely and it was tedious to go through and delete them, so he wrote an add-in to do it for him! 

To add the add-in simply follow my previous posts instructions pull up the Xamarin Studio Add-in Manager. Then you will want to install Redth’s Addins under IDE Extensions.

Now, from any single project or at a solution level you will see a new “Obliterate Output Paths”. #MindBlowing  Simple and elegant and I hope you enjoy.

Greg Shackles: FloatLabeledEntry: Renamed Project, Now Available on NuGet

Back in 2013 I blogged about a library I published called JVFloatSharp that provides a slick floating placeholder on iOS after you start typing into a text input:

the pattern in action

Outside of a few small bugfixes and upgrading to the unified API a few months back I really haven’t needed to mess with it much, and have been successfully using it in many apps in the meantime. I’d always intended to make it available on NuGet, but I never got around to that…until now. You can now grab both the standard version and the MonoTouch.Dialog version on NuGet:

I kept them as separate binaries so that you don’t need to take a dependency on MonoTouch.Dialog if you aren’t actually using it. I also took this opportunity to rename the project and restructure things to make way for adding an Android version. The GitHub repository has been renamed to FloatLabeledEntry as well. Let me know if you’d prefer to see a Xamarin Component in addition to the NuGet package.

Using the library is just as easy as before:

var titleField = new FloatLabeledTextField(CGRect.Empty)  
{
    Placeholder = "Title",
    FloatingLabelFont = UIFont.BoldSystemFontOfSize(12),
    FloatingLabelTextColor = UIColor.Gray,
    FloatingLabelActiveTextColor = UIColor.Blue
};

or if you’re using MonoTouch.Dialog:

new Section  
{
    new FloatLabeledEntryElement("Title")
}

Kerry W. Lothrop: Building secure apps: Need help from app store operators

Communicating securely between a mobile app and a the corresponding backend is not a trivial task. Sure, nowadays we can write https and almost be certain our app is actually having encrypted communication with the right backend. However, just recently, I decided to do a communications check of apps on my iPhone using Fiddler as … Continue reading Building secure apps: Need help from app store operators

Frank Krueger: Coding in Your Head

I’m terrible at coding interviews – some busy bee dusts off a tricky algorithm that they studied in college and asks you to (1) originate it from a poorly stated problem and (2) live code it in front of them.

This isn’t how I work. Like most programmers who survive more than a few years in this business faced with a novel or difficult problem, I do the majority of my design work in my head – slowly.

Realm of Endless Possibilities

The problem gets repeated endlessly: “The user wants to accomplish X, Y, and Z – I will need to talk to data sources I, J, K – I will use algorithms A, B, C – they are connected in this configuration or that – information will be on a screen that looks like…”

I try out all the permutations of data structures, objects, their relationships to one another, algorithms that I already know, and algorithms that I note to seek out. I think through the user interface – attempting to limit the number of choices the user has to make to do repetitive tasks while still trying to giving them a new power.

Steeped in years of OOP programming, all this design work culminates in an object schema in my head. Known classes and their relationships to other classes are built and toyed with. I refine this graph by running many algorithms across it to see how nasty my layers of abstraction and encapsulation make moving data around (remember, in the end, the most important thing to your program is the data – not how you represent it). I look at it to see how easy it will be to extend or flat out replace in the future.

This is a slow process. It’s why I have a list of 100 “potential next apps”. They’re up in my head (or at least a few top candidates) while I toss them around and poke and prod at their code.

Coding It

Once a design is deemed robust, useful, and interesting enough, it’s time to sit down and code it. At this point you are basically limited by your programming language. This is why I’m a programming language nerd and relentless critic.

I don’t care about powerful programming languages because they save me from typing. I care about them because they allow me to get closer to my mental design than less powerful languages.

Designs of the mind are necessarily abstract – unconcerned with particulars of language. My “head design language” is just objects, interfaces, methods, properties, and events. Call this OOP 1.0. (As I learn functional programming, my language is slowly turning to records, abstract data types, interfaces, and functions.)

When I sit down to write these, any boilerplate that the language forces on me becomes an annoyance. C++ and Objective-C that require designing a memory strategy are profoundly annoying (I can barely get my own designs right, and now the fracking computer needs help too?). C#’s lack of metaprogramming and first class events is another annoyance. F#’s single-pass compiler that makes you order every declaration and even your source files (seriously, what decade is this?) is, you guessed it, annoying. Even trivial syntax gets annoying at this point – why do I have to write all those silly characters? { ; } oh my.

The tools we use also become obstacles. Intelligent IDEs that are intended to make coding easier become enemies with every spinning beach ball – with every hidden setting – with every error message. Imagine trying to create an intricate sand castle on the beach during a hurricane. No wonder text editors such as Sublime are such hits.

So your beautiful mental design gets compromised into some language or another. This is why we call it coding – we are encoding a design into some barbaric text format that only highly paid professionals and intelligent 13 year olds can understand. Anyway…

That’s all to say that it’s best to burn through all the bad designs in your head so that only the decent ones have to suffer this transition to code.

Some More Thoughts

It’s a slow process but it can’t be sped up. No, test driven development is not an answer. TDD causes you to hash out a design – but one that’s biased to one consumer – the tests. It neglects the most important consumer – the end user. Also I am happy to throw out a design that I’ve been mulling over for a week. I have never once seen a TDD advocate throw away a week’s worth of Asserts – no they just get painfully “refactored” into the next design option.

It’s not a perfect process because your initial designs are never right. Certainly it saves you from writing endless numbers of throw away prototypes before you settle on a good design – but it won’t be a perfect design. It will have to be changed once you’ve implemented the app and learned what the app really is and how people really use it.

Frank Krueger: Many Levels of Rejection

Submitting apps to the App Store is filled with many wonderful opportunities to be rejected. Let’s count them!

1. Compiling/Building your app is the first possible level of rejection. It’s usually your fault, but some days…

2. Signing your app is also an adventure in rejection with the added joy of creating multitudes of profiles and app IDs than you really don’t know what to do with but are too afraid to delete.

3. Sometimes the phone itself will reject you next. Maybe Springboard is having a bad day, or maybe you really have made a mess of those profiles…

4. Hey look at me! The watch wants in on this game too! It likes to reject you for a variety of reasons but doesn’t like to tell you which. You’ll have to dig into the logs to find its secret motives.

5. Time to submit that puppy and get rejected by the iTunes Connect! iTunes is actually pretty good at this whole rejection thing and does its best at helping you through the difficult times.

6. Well now that you’re uploaded, surely the app… whoops. Nope. Time for the little Prerelease Binaries to reject you. Oh you didn’t know about that esoteric requirement? You read every guide, right? Right?

7. Time to submit for review and let the humans… nope, wrong again. Another computer can reject you now before a human ever sees it. Watch your inbox cause iTunes Connect has no idea what that computer is doing.

8-1,000. Finally after all that, you can be rejected by a human. This rejection process is long, filled with unspoken truths, false assumptions, and bitter quibbles. But at least it’s a human…

1,001-1,024. It was all worth it, your app is in the store and is running gr… oh, it crashes on iPad 2s when you rotate the screen during the 5th moon of the year. 

So close.