I released my first iOS app! 🎉🥂👏🏽 It’s called WurstWetter check it out:
“Why did you make this?” you’re asking. I wanted a portfolio piece and I saw many others making weather and calculator apps as their first portfolio pieces, but I needed my own spin on it. So why not only show the worst weather across the US!? ⛈
The idea made this app a bit more of an undertaking than your regular weather app because I knew early on I would need a backend. That’s what this post is about, the WurstWetter backend.
I knew I needed a backend because I didn’t want individual clients making hundreds of weather requests at once when the app was opened. As the user base would grow, I would get in trouble with weather data providers over how many requests I was making. I also didn’t want to pay for all of this weather data, it gets pricey quick…
Here’s a story about my race against the clock to publish an Alexa Skill, complete with shortcuts, pitfalls, and advice.
On the afternoon of June 26th I stumbled on a promotion Amazon was having: if I published an Alexa Skill before midnight on June 30th I would get a free Echo Dot. (Here’s the link, no guarantee it still works: https://developer.amazon.com/alexa-skills-kit/alexa-developer-skill-promotion.) I thought, I wouldn’t mind a free Echo Dot or learning something in the process, and the race against the clock would be a fun challenge.
I started brainstorming some ideas and remembered I’d been working on an iOS “weather app” for some time now. Now, it’s a “weather app” in quotes because it doesn’t actually tell you the weather where you are, it only tells you the worst weather in America. I call it: WurstWetter 🤣…😐. So, I thought it’d be cool to start thinking about WurstWetter as a “brand/platform” and make another on-ramp into that world, and that’s how I decided to build a WurstWetter Alexa Skill. …
I was recently rewriting my weather app (for the third time) and I decided to fully embrace storyboards and Interface Builder. Why? 🤔 Well, the first version of my app had no storyboards, the second used ASDK, so it felt right that the third use storyboards.
As I was writing the typical
cellForRowAtIndexPath boilerplate, I stumbled across this article:
I used the protocol extension + generics technique to elegantly return a typed subclass
UITableViewCell without repeating code or casting in my table view data sources👌
But after typing out the same code twice to instantiate two different view controllers in two different storyboards I had a 💡 moment. I could use the same technique to return typed subclass