Totally missed that an excellent AOE2: Definitive Edition macOS port came out last month. Deleting Parallels / Windows from my Mac feels so good
\nBeing signed into the App Store with my US account (but still signed into my main / Irish account in settings) is enough to get Siri AI in the EU, on the developer beta at least
\nI didn’t plan to watch 2 1997 volcano thrillers in one day, but it happened.
\n Dante’s Peak: ⭐️ ⭐️ ⭐️ ⭐️
\n Volcano: ⭐️ ⭐️
Resizable iPhone mirroring, an Origami demo app, shirts so new you can still see the creases … are you getting it?
\nI get distracted watching WWDC videos for the same reason I get distracted watching Shrinking, thinking about how none of these clothes have ever been worn before
\nRelatedly, my enthusiasm for the technology and the products I've worked on has always been something I've used to my advantage as a manager, but it turns out forcing it when it just isn't there can be exhausting and isn't always worth it
\n \nAfter 2 years as a certified AWS cloud practitioner, I'm no longer a certified AWS cloud practitioner
\n![\"Nic](\"https://mbehan.com/assets/posts/20260608160751691-20260608160751691-1.jpeg\")
![\"light](\"https://mbehan.com/assets/posts/20260608130044949-20260608130044949-1.jpeg\")
All done with my AC chemo. I started weekly Paclitaxel yesterday and I'm really hoping the stories of if it being easier turn out to be true.
\nCycles 3 and 4 were progressively more awful - the pattern was the same as earlier cycles but the side effects generally ramped up. I was fairly melted onto my bed for a good 10 days in round 4 with no interest in doing anything on the computer or even watching anything.
\nI was really banking on having a few good days at the end but they never quite arrived, by the time I had some energy the terrible taste and mouth sores were making me feel just as bad. There were a few days during the cycle that were definitely the most depressing and negative-thinking days I've ever had.
\nI never found a perfect response to the mouth issues, but regular salt/bicarb rinses for the ulcers and chewing gum to mask the taste helped. The one food I could reliably enjoy was McCambridge stone ground whole wheat bread with butter, the texture of the bread feels good on my weirdly smooth tongue but without being crispy/crunchy enough to bother my gums and butter is the one taste that seems to break through without much change. I was prescribed \"Magic Mouth Wash - BMX\": for the mouth ulcer pain but the pain had mostly gone by the time I got it.
\nThere were 2 new side effects for cycle 4. Severe gassiness for a week or so that thankfully for me, but perhaps unthankfully for the family was not at all trapped. I also developed a bad looking rash all over my face, but it didn't actually cause any pain, I just look diseased.
\nMy hair is still clinging on to most of my body besides the head. Not having to shave is definitely the one upside, my neck has never been happier. Chest has thinned out quite a bit but no budge at all on my shoulder hair, I might still have to give them their annual summer shave!
\nJust one day into 12 weeks of Taxol now but I feel better than I did yesterday so thats helping me feel a bit more hopeful.
\n![\"Homer](\"https://mbehan.com/assets/posts/20260605092031093-20260605092031093-1.jpeg\")
A massive care package arrived from work, lots of great stuff inside from the great people at SiriusXM
\n![\"Huge](\"https://mbehan.com/assets/posts/20260528083823150-20260528083823150-1.jpeg\")
Screenshot of my step count from Pedometer++ captures how my current chemo cycle is going, hopefully back in the green tomorrow
\n![\"\"](\"https://mbehan.com/assets/posts/20260515210721206-20260515210721206-1.jpeg\")
A lot of best / favourite Apple product lists going around during Apple's 50th anniversary year, here's my faves:
\n5. The iPhone 5C. The best material to make a phone from remains unapologetic plastic, I would love them see them have another go at it. If Crocs can have a comeback, so can those holey cases!
\n4. The Original Smart Cover, for iPad 2. Magnets and cloth have never combined so well, every subsequent iteration has been frustratingly worse. Was a big part of why the iPad 2 seemed so much cooler the original iPad for me.
\n3. The original Mac mini. It hasn't always been the case but the original base model was an actually cheap (even in Ireland, even for a student) way to get into the Mac with a decent spec. I plugged it into my Dell monitor, keyboard and mouse and never looked back!
\n2. iPhone X. Back when I used to get a new iPhone every year the ten lived up to the name by feeling three better than the seven it replaced! Still the best looking phone there's been.
\n1. M4 MacBook Air (or any of the current M2-M5 design). Best computer I've owned by a mile, including the better-spec-wise current MacBook Pros. Can throw it around the place, use it on the arm of the couch, never runs out of battery, crazy powerful.
\nHonorable mention: iPod Socks. My iPhones 3G to 4 lived in them, better than various more recent strap and case efforts.
\nThe Goldeneye 007 nightclub on Wii captures my favourite part of being a programmer - finding creative ways to make the computer do more than you think it should be able to. Also, probably my fave Any Austin video so far.
\n \nBalbriggan beach shots from the weekend
\n![\"A](\"https://mbehan.com/assets/posts/20260507181403052-20260507181403052-1.jpeg\")
![\"Seagulls](\"https://mbehan.com/assets/posts/20260507181403052-20260507181403052-2.jpeg\")
![\"Seagulls](\"https://mbehan.com/assets/posts/20260507181403052-20260507181403052-3.jpeg\")
![\"Seaweed](\"https://mbehan.com/assets/posts/20260507181403052-20260507181403052-4.jpeg\")
![\"Rockabill](\"https://mbehan.com/assets/posts/20260507181403052-20260507181403052-5.jpeg\")
I loved Sierra adventure games as a kid, this is a neat project.
\n \nDone with cycle 2 of AC. It followed a very similar path to the first, maybe slightly worse side effects overall but no ambulance ride this time so I'm calling it a win.
\nI mostly wanted to (and did) stay in bed for the first whole 9 or 10 days. First time around I made an effort to get out for a 30 minute walk on those days but I didn't this time. Any spells of feeling a bit better was given to messing around on the computer instead. I was still able to go sit with the family for dinner or maybe a bit of TV time most of those days too (Brooklyn 99 has been our go to if I'm up for it).
\nFor the first 5 or so of these days nausea was the worst complaint, I needed to reach for the antiemetics more often than the first time around but they did their job again. For the rest it was more the tiredness and the on-edge / jittery / out of it feeling I reported last time. Perhaps-related, my Apple Watch informed me that my average resting heart rate has increased from low 50s to low 70s since I started the chemo (I told one of the oncology nurses and he said that was still an ok number).
\nI don't think it varied much through the cycle but my taste is significantly reduced now, water tastes and feels gross, most everything else is muted. I had a sore on the inside of my mouth that got bad for a couple of days, but I added salt and bicarb rinses a few times a day and kept away from anything crunchy or spicy and thankfully it didn't become a big problem. I've lost some weight, but I'm probably eating exactly what I should be, I'm avoiding the free office snacks and late night stress eating that is my usual routine when I'm working.
\nThe hair was the biggest difference this time - it's gone! Started shedding 2 days into the cycle, it all went dry/stiff and it hurt to wash or touch. Came out slowly at first but after a couple of days it was coming out in big clumps anytime I touched it. When it started looking like a bad haircut I buzzed the rest off. Still hair remaining elsewhere on my body, curious to see what remains after the next cycle. The full hair status is:
\n👨🦲 ........ Head
\n 🐻 ........ Shoulders
\n 🐻 ........ Chest
\n 🐻 ........ Back
\n 👨🦲👨🦲 ... Downstairs
Things gradually improved from there and for the last couple of days (day 13 & 14) I felt back to myself again. I was lucky it coincided with a bank-holiday weekend and some nice weather so I got to enjoy some time with the family.
\n![\"Homer](\"https://mbehan.com/assets/posts/ac-chemo-second-cycle-shine-o-ball-o-png.webp\")
Finally got around to watching Elio, loved it! ⭐️⭐️⭐️⭐️⭐️
\nI've reached side-project enlightenment (or, what I find fun has changed)
\n![\"The](\"https://mbehan.com/assets/posts/side-project-enlightenment-side-projects.png\")
I keep coming back to this scene of Geordi in the holodeck working a problem with the computer. With the latest Codex and Claude Code it feels like we're almost there.
\n \nStarting to notice the hair coming out now, Tim Peeks here I come
\n \nSigned up for Bullet Memo. Fits my way of organising tasks but mostly I'm there for the insipiration boost I get using nice, thoughtful, opinionated software interfaces when I'm working on my own.
\n \nTIL / remembered you get billed €100 for visiting the emergency department. I think it's to encourage people to go to their GP first but feels like they could carve out an exception for folks that have been ambulanced in after collapsing.
\nI used OpenMoji for all the emoji and icons here. Style is just what I wanted + Creative Commons license = can't go wrong.
\n \nBuilt this new website today. Wanted something that looked like a social feed but just for my posts and none of that following and retooting business. I like it!
\nI've been leaning into my middle initial more lately
\n![\"Michael,](\"https://mbehan.com/assets/posts/major-league-behan.jpg\")
Rewrote a couple of my old Objective-C tools / sample projects as Swift packages. Gave them snazzy new names while I was at it.
\n \nGitHub - mbehan/Luminator: Simple dynamic lighting effects for iOS image views.
\nI'm just about at the end of my first 2-week cycle on AC (doxorubicin / cyclophosphamide) chemotherapy. I've read a lot of people's experiences with it on r/breastcancer but they're mostly women, and most seem to have handled it really well, so I wanted to share a different perspective.
\nI've felt really rough the majority of the time. Thankfully I had already decided to take the entire 8 weeks of this treatment off. I had been hoping I might be able to return to work during the 12 weeks of Taxol (paclitaxel) chemotherapy that will follow, but I can't imagine working until I'm completely done and recovered now. Most stories say Taxol isn't as bad, but the tiredness is cumulative and I'm already so tired.
\nThe best way I can describe my baseline feeling is that it's like back in college if I'd been up all night coding and downing red bulls, a sort of shaky, on-edge feeling. On top of that it's like somebody turned up the gravity, my arms and legs feel heavier than they should, getting out of bed is a chore. I feel kinda detached from reality, like I'm watching a video of life going by rather than being in it. Nausea has been present much of the time, but only once or twice did it feel like I might barf, thankfully I didn't. I took all the recommended meds (Emend, Dexamethasone and Olanzapine) and only felt the need to reach for the additional antiemetics (Maxalon and Valoid) a couple of times.
\nMy mouth feels crap and I can barely taste most foods. No full on sores or bleeding but theres a general unpleasantness. I'm swishing (as best one can swish 1ml of anything) Mycostatin 4 times a day and using Corsodyl's chlorohexidine mouthwash. The Corsodyl was making my toungue sting so I've started diluting it, which helps a lot.
\nI'm on the 2 week dose-dense schedule so I'm injecting Neulasta to boost my white-cell count but thankfully I've avoided the bone pain that is a common side effect of that.
\nOn day 6 I fainted. My wife called an ambulance but I was conscious and feeling ok by the time they arrived. ECG, bloods, and vitals were all OK in the emergency department so they sent me home. Followed up at the oncology ward the next day with a CT scan of the brain which was clear and they had me wear a heart monitor for 48 hours which showed nothing, so the consensus is let's not worry about it unless it happens again. It was scary, for my wife more so than me (\"you looked dead\").
\nMaybe I overdid it that day, I had been going for a 30 minute walk each day and I was feeling better that morning so went a bit farther, I hadn't eaten much either, maybe that contributed. I've resolved to take it easier for the first week of cycle 2, now that I know there is a point where it starts to feel much better.
\nThat point was around day 9, I've been gradually feeling more myself since then, it's day 13 now and I feel pretty much back to myself (taste aside), able to stay out of bed all day and have been doing some work on some coding projects.
\nNo idea how the next cycle will go, but if it's about the same minus the fainting, I'll take it. No sign of my hair going yet, I've heard it should be any day now, I keep running my hands through it, looking at my empty hand, weirdly disappointed, waiting on that movie \"guy with cancer notices hair falling out\" moment!
\n![\"Screen](\"https://mbehan.com/assets/posts/walter-white-chemo.png\")
Adding it to the backlog
\n![\"Chief](\"https://mbehan.com/assets/posts/chief-wiggum-invisible-typewriter.gif\")
Blush Neo next to the midnight Air
\n![\"Blush](\"https://mbehan.com/assets/posts/IMG_7824.jpeg\")
Turns out I'm one of about 20 or 30 men who will be diagnosed with breast cancer in Ireland this year. I haven't found many men's stories, so I thought I'd share how it's gone for me so far. From finding a lump to diagnosis, surgery, and chemo within a couple of months.
\nI found a lump by chance during the first week of January, awkwardly taking off my oversized fleece hoodie that I was wearing with my hands inside more like a blanket. I noticed a hard lump under the surface next to my left nipple. I knew it wasn't good right away. A hard, round mass, about the size of one of those little rubber bouncy balls we always seem to end up with from kids' birthday party bags. Feeling around some more, I could tell it wasn't smooth like one of those, it had a rough texture, maybe more like a golf ball. It was late Saturday evening and I was up by myself. I decided I'd go to bed and make a plan in the morning.
\nThe next morning I checked the lump was still there. I could feel its presence without touching it, and it was just about visible now that I knew it was there. I also noticed the nipple was slightly inverted. I didn't tell my wife right away. I planned to go to the GP during work the next day, hoping they'd say it was nothing, but the possibility of cancer was already top of my mind.
\nThe next day was the first day back at work after Christmas. I split the morning between onboarding a new hire and calling around to get a GP appointment nearby. I was relieved when I got one who could squeeze me in at the end of their day on short notice. I gather I got a good one, given how seriously they took my concern and got things in motion. The GP had a look and feel around the lump, the nipple, and under my arm and said it needed to be checked out immediately. I was referred to the Triple Assessment Clinic at the Mater Private Hospital, and they called the next day with an appointment two days later.
\nThe triple refers to having a mammogram, ultrasound, and a consultation with a surgeon in the same appointment. First up was the mammogram. I've always had enough man boob to be self-conscious at a swimming pool, but still it seemed like not quite enough to easily manipulate into the specialist X-ray machine, but we got there in the end. Several scans were taken on both sides and the technician was happy with the quality. That inverted nipple warranted an extra set of high-res shots.
\nNext up was the ultrasound. They were very thorough, really pushing the scanner deep into the tissue, especially in the underarm area. Later I'd realise this was because they were already seeing strong indications of malignancy and were looking for spread to the lymph nodes. I was told a biopsy was needed and they were going to proceed right there and then. I was given local anaesthetic and a large needle-like device emerged, which, with two loud thunks, took two samples through the core of the lump. They patched me up and sent me across the road to see the surgeon.
\nThe surgeon described what they had seen in the imaging: a 23mm lump that needed further investigation by biopsy. It would take about two weeks for results, but he laid out the three possibilities clearly. The first was that the sample was normal tissue. He said if this was the result he'd order a new biopsy because something had clearly gone wrong. The second was atypical or benign. If so, he'd likely do an excision biopsy to confirm. The third was where the bets were being placed: that it was cancer, which would require mastectomy surgery, a lymph node biopsy, and potentially chemotherapy. Radiation looked unlikely. He set the appointment for the biopsy results and recommended that my wife come with me.
\nWaiting for the results was no fun. Some sleepless nights and consultations with Dr GPT went alongside pain and bruising from the biopsy, but work and kids and everything else carried on as normal. It was a bit less than two weeks later that we got the results, and option three was confirmed: invasive ductal carcinoma. Surgery was scheduled for two weeks' time. They would take the lump, the nipple, and the breast tissue from the left side, along with two sentinel nodes to test, as they'd be the first place the cancer would likely spread. They said three weeks after surgery we'd meet again to go over the findings and decide the rest of the treatment plan, but endocrine treatment was already likely given my tumour was oestrogen-receptor positive. After talking it through with the surgeon, the breast care nurse took us to another room to give us more time to ask questions and provide more info. It was funny that it was clear she was used to the man being there for moral support rather than being the patient. We were given a pink breast cancer booklet, but I'd already read up on everything in the weeks before, so there wasn't much to learn. It was all just actually happening for real now.
\nSurgery was a little scary. It was my first time under general anaesthetic, but everything went according to plan and I was able to go home the next morning. I emerged with a plastic tube coming from below the incision, with a bulb attached collecting fluid from where the breast tissue had been. Looking after the drain was probably the worst part of recovery. There was some pain, but it was easily managed with painkillers. There were restrictions in moving my left arm, but the physio exercises did the job and within a few weeks everything felt fairly back to normal. The drain could come out when it was draining less than 30ml a day, which took just over a week. I was back to work after two weeks. I'd have taken longer, but two weeks was all that was going to be paid.
\nThe three-week wait after surgery was easier than the two after the biopsy. I had a lot more information now. From what I'd read, my cancer was very standard and the path ahead fairly well understood. If there was spread to the nodes that would be different, but everything so far indicated there wasn't. My appointment for the results was moved up. I got a call in work asking if I was free that day, so I headed over to the surgeon's office on my own. They said it was good news and didn't want to keep me waiting. Margins were clear, nodes were negative, and the tumour measured closer to 3cm than the original 23mm from imaging, but that wasn't a concern. There was one test left before we'd know what was next: the Oncotype test. That was ordered, my tumour sent to a lab in America, and I had another two weeks of waiting before seeing the oncologist once the results were in. This is the test that decides whether chemotherapy is needed, and in about 25% of cases like mine it is, so it means a lot of people can avoid it unnecessarily.
\nI didn't get warned to bring someone to the next appointment, so I went alone, but I could tell from the greeting at the door that it was probably bad news. The news was that my Oncotype score means chemotherapy should be effective at reducing my chance of recurrence. So it's not bad per se, but I haven't been able to avoid chemo. I'm dreading it more than having cancer. The cancer is gone for the most part, but now I have five months of treatment planned to clear up the stragglers. The oncologist explained everything clearly and I had the same extra time with the nurse as with the original diagnosis. They're well practiced at explaining how everything is going to go. Two months of AC followed by three months of Paclitaxel. The AC is usually harder. My hair will go. I should take off the entire time from work if possible and cancel my summer holidays. The only other prep the oncologist recommended was to tell the kids.
\nLovely morning on Balbriggan beach
\n![\"Bright](\"https://mbehan.com/assets/posts/IMG_7830.jpeg\")
After much deliberation on gaming busses and party venues, our newly-9 year old went for an old school house party
\n![\"Musical](\"https://mbehan.com/assets/posts/IMG_7922.JPG\")
![\"Whacking](\"https://mbehan.com/assets/posts/IMG_7923.JPG\")
The Irish Sea at Balbriggan harbour giving Atlantic coast vibes today
\n \nGot a new record in my morning work carpark challenge
\n![\"Car](\"https://mbehan.com/assets/posts/IMG_7602.jpeg\")
At the rugger with the fam
\n![\"Sitting](\"https://mbehan.com/assets/posts/IMG_7400.jpeg\")
Defused a bomb / replaced the fan oven heating element
\n![\"Back](\"https://mbehan.com/assets/posts/IMG_7387.jpeg\")
![\"My](\"https://mbehan.com/assets/posts/IMG_6609.jpeg\")
Always love to see a in the wild
\n![\"An](\"https://mbehan.com/assets/posts/IMG_5741.gif\")
I’m self-isolating with Covid. I don’t have the energy to complete any of my half-done side projects, but I have just enough to start some news ones!
\n![\"A](\"https://mbehan.com/assets/posts/futureproof.png\")
I've long had the notion that it would be fun to have an app to quickly generate and share hashes of predictions, so you could publicly declare a prediction that can be proven later without contaminating the timeline, so I started putting together that app today.
\nSelected Xcode versions and their download size
\n 4.6: 1.59GB
\n 5.1: 2.11GB
\n 6.4: 2.61GB
\n 7.3: 4.7GB
\n 8.3: 4.20GB
\n 9.4: 4.91GB
\n 10.3: 5.6GB
\n 11.7: 7.59GB
\n 12.5: 10.98GB
\n 13.0: 9.98GB
Incorporating SwiftUI Views in a UIKit Layout
\nMixing some SwiftUI in with your UIKit app is a great way to start using it for real without having to commit to fundamentally changing how you build your app. Doing so requires some boilerplate and when what you want to start with is a single view that only makes up a small part of a screen it might seem overly onerous.
\nThis almost put me off, but I saw it through and turned the boilerplate into an extension on UIViewController which will add your SwiftUI View on top of a placeholder UIView that has been laid out with constraints (in my use case, from a storyboard).
\nextension UIViewController {\n\t\tfunc addSwiftUIView<Content>(_ swiftUIView: Content, for placeholder: UIView) where Content: View {\n\t\t\t\tlet swiftUIController = UIHostingController(rootView: swiftUIView)\n\t\t\t\tself.addChild(swiftUIController)\n\n\t\t\t\tguard let swiftUIView = swiftUIController.view else { return }\n\t\t\t\tswiftUIView.translatesAutoresizingMaskIntoConstraints = false\n\t\t\t\tplaceholder.addSubview(swiftUIView)\n\t\t\t\tswiftUIController.didMove(toParent: self)\n\t\t\t\tswiftUIView.constrain(to: placeholder)\n\t\t}\n}My Swift Extension Pattern
\nI’ve become aware of how frequently I create extensions in Swift. I previously viewed them as something to use sparingly, like when there was something missing from a built-in type that was needed frequently - but now I regularly write them for once-off use.
\nThis is the example that got me thinking about it today:
\nextension UInt8 {\n\t\tstatic func entireRange() -> ClosedRange<UInt8> {\n\t\t\t\treturn UInt8.min...UInt8.max\n\t\t}\n}Which exists only to be used in this other extension:
\nextension Data {\n\t\tstatic func randomBytes(size: Int) -> Data {\n\t\t\t\tvar byteArray = [UInt8]()\n\n\t\t\t\tfor _ in 0..<size {\n\t\t\t\t\t\tbyteArray.append(UInt8.random(in: UInt8.entireRange()))\n\t\t\t\t}\n\n\t\t\t\treturn Data(byteArray)\n\t\t}\n}Which exists to be called once in some test code that will eventually be replaced when working with the actual data.
\nI leave the extensions in context in the files where they’re being used rather than in a specific file for the extension, or a collection of helpers and I find the resulting code reads wonderfully.
\nEvery authenticator app I’ve used has annoyed me in some way so I’ve started making my own.
\nThe first annoyance I’m working on removing is having to wait around to get the next code when the timer’s running down.
\n![\"Screen](\"https://mbehan.com/assets/posts/thisonetime.gif\")
You'd Be Surprised What People Don't Know
\nHave you ever thought about trying to explain something, but it's so obvious that you assume everyone already knows?
\nHave you ever thought that maybe there are lots of things you've never even though about explaining, because, well they're even more obvious than that?
\nI've been thinking about this lately and I know for sure I can answer yes to the first question, and almost certainly even more so to the second. I've avoided unnecessary explanations - success! Except I've come to realise that a great many of the explanations I avoided, code comments I didn't leave, blog posts I didn't write, were missed opportunities.
\nAs Daniel Jalkut put it in a recent episode of Core Intuition, sometimes we know Rome too well. In his metaphor a lifelong resident of a city is less suited to writing a guide for visitors than a more recent arrival whose freshly acquired knowledge is less ingrained. He was talking about marketing his product, but it immediately resonated with me for a slightly different reason: bringing new developers on to an old codebase. The one or two people who've been working on the app for the last 5 years won't know what a new developer is going to struggle with, they may not spot that the fact that you have to do x,y and z before you call some particular function is non obvious.
\nWith recent events there has been lots of sharing and explaining about a couple of things that I thought were pretty obvious. Hand washing, and exponential growth. It turns out a lot of people don't know that soap is the thing that cleans your hands and that you don't have to double things very many times before the numbers get huge. I'm really glad that people have been sharing because it wasn't until I really thought about it that it made sense that not everyone knows this already and that I just happened to know them too well. It turns out my obsession with computers and taking chemistry in secondary school with a teacher that now that I think about it was way too excited about soap than is normal made me uncommonly equipped for current events.
\nI've learned that it's important to examine how we've come to know something, and to consider if it's reasonable to assume others will have had similar opportunity to come by this knowledge when deciding if something is worth explaining, commenting on or sharing. I've resolved to document earlier, comment better, and in general share more. I'm also planning to make newcomers central to my efforts to fill in documentation deficits and improve developer onboarding on older apps.
\nHopefully you didn't already know all this.
\nDetecting When Your App Gets Backgrounded using Combine
\nThe introduction of the Combine Framework provides a new (reactive) way to respond to system events such as your app entering the background.
\nIn this example I have a CALayer subclass running some CABasicAnimations that need to be paused when the app gets backgrounded and resumed when the app becomes active again. In the layer's init we attach a subscriber to the default notification centre's publisher for the particualr events that we're interested in. When attaching the subscriber we provide a closure that will be executed every time a new event arrives.
let bgSubscriber = NotificationCenter.default\n .publisher(for: UIApplication.willResignActiveNotification)\n .sink {\n _ in\n\n self.pauseAnimation()\n }\n\nlet foregroundSubscriber = NotificationCenter.default\n .publisher(for: UIApplication.didBecomeActiveNotification)\n .sink {\n _ in\n\n self.resumeAnimation()\n }\n}Let's dig in a little to what's going on here because it may not be obvious if you're not familiar with Combine or NotificationCenter.
\nNotificationCenter predates Combine as a mechanism for broadcasting information (notifications) to interested observers. Every app gets a default notification centre which is used to broadcast system events such as those in the example here. Without Combine you can register to observe notifications and provide a selector to define what function to call when a notification is received.
\nWith the introduction of Combine however, NotificationCenter added the publisher(for:object:) method which returns a Publisher that will emit values when notifications are broadcast.
A Publisher is how Combine represents a sequence of values over time that can be subscribed to. By calling sink(receiveValue:) we create a subscriber that will receive every value from the publisher.
The true power and utility of Combine isn't seen in this example, but even still I don't think it's overkill to use Combine to provide a modern Swifty replacement for old fashioned notification observers and selectors.
\nTo complete this specific example there's a little more work to do. In my app I create many of these custom CALayer instances and at various points they get removed and new ones created in their place. With the code above as it is we're preventing the layers from being deallocated when they're no longer being used (because we captured self in the closure passed in to the sink call). To fix this problem we can keep a reference to the subscribers
\nprivate var appEventSubscribers = [AnyCancellable]()\n\ninit(){\n\t\n ...\n\t\n appEventSubscribers = [foregroundSubscriber, bgSubscriber]\n\n}so that we can cancel them when the layer gets removed from its parent.
\noverride func removeFromSuperlayer() {\n appEventSubscribers.forEach {\n $0.cancel()\n }\n\n super.removeFromSuperlayer()\n }\n}iPad OS or, Names Are Important
\nWhen I attended WWDC for the first time in 2010 the iPad was still brand new and not yet available in Ireland. Many had dismissed it as just a big iPhone, others (me, at least) had hyped it as A BIG IPHONE.
\nIt ran iPhone OS version 3.2.
\nAs we queued up before the Monday morning keynote we were all expecting the next iPhone and the next version of iPhone OS and we speculated about what new features we'd see. There was one seemingly minor announcement though, that nobody was expecting: the next version of the operating system would be called iOS 4, dropping the 'iPhone' to accommodate iPad. It made sense at the time and initially my only reaction was delight at how they managed to do it mid presentation, with nobody slipping up and using the new name before the announcement and nobody using the old one afterwards. In the years that followed though, as the 'just a big iPhone' opinions persisted and many developers put forth minimal effort in making their iPhone apps work on iPad, I came to think that not creating a separate identity for the iPad's operating system was a missed opportunity, one that they finally rectified this year by renaming iPad's operating system to iPad OS.
\nPerhaps making it incredibly clear that iPhone developers could make iPad apps made the previous OS naming scheme worthwhile up to a point but I believe making it clearer that iPad has its own OS, with its own interface, its own set of interactions and idioms that are distinct from iPhone will be a bigger benefit to software on the platform. OS naming is now consistent across all of Apple's mobile devices - they are all based off iOS but Apple Watch runs watch OS, Apple TV runs tv OS and iPad runs iPad OS. These operating systems are not distinct in terms of technology or how we develop for them or who can develop for them, the distinction rather is in how the user interacts with them. Hopefully (and I believe it will) for iPad, this will result in more differentiated iPad software that takes advantage of its unique and powerful features.
\nPassing a closure to a UIButton
\nI'm tired of @objc #selector (nonsense: ) muddying up my Swift code. This most commonly rears its ugly head when dealing with buttons. Why can't we just provide a button with a closure to execute when someone taps it? *
// 😩\nbutton.addTarget(self, action: #selector(myButtonHandler), for: .touchUpInside)\n\n// 😍\nbutton.on(.touchUpInside){\n ...\n}Well now you can! I made a small UIButton subclass that provides a swifty facade for adding target/actions for events and otherwise behaves exactly like a regular old UIButton (to be clear, selectors are still doing the business under the hood.)
\n \n* The reasons are simple and boring and because we're still working with Objective-C frameworks from the 1890s (that for the record, I still love), but that wasn't the point of this post.
\nNo, Apple Does Not Share Your FaceID Data
\nThe notch full of sensors on iPhone X enables Face ID to capture
\naccurate face data by projecting and analyzing over 30,000 invisible dots to create a depth map of your face and also captures an infrared image of your face. A portion of the A11 Bionic chip's neural engine — protected within the Secure Enclave — transforms the depth map and infrared image into a mathematical representation and compares that representation to the enrolled facial data.\n
Meanwhile, from the same notch, third party developers can access
\na coarse 3D mesh geometry matching the size, shape, topology, and current facial expression of the user’s face.\n
These are 2 different things.
\nFor more see Apple's support article on Face ID and their developer documentation on ARKit Face Tracking.
\nThe Apple Watch's Platform Problem
\nI've a phone in my pocket most of the time, Alexa is always waiting for me in the kitchen and I spend hours every day in front of an old fashioned PC but my watch is with me all day long wherever I go. Sometimes it's the only computation available and almost always it's the least intrusive.
\n![\"Apple](\"https://mbehan.com/assets/posts/AppleWatch.png\")
As good as Apple Watch is though, it has so far failed as an app platform. Apple Watch is built on the same technology that runs iPhone, and the same tools that developers use to make iPhone apps are used to make Apple Watch apps, so why are there so few Apple Watch apps, and why are so many really bad?
\nThe original watch hardware was very limited, and app support even more so. Apps actually ran on your phone and were sort of beamed onto the watch's screen. If you managed to find the apps on the terrible honeycomb grid they loaded really slowly and performed terribly. A lot of developers and users were instantly turned off of third party apps, but the watch got by with the excellent built in notifications and fitness tracking functionality.
\nEach release of watchOS and every hardware revision has seen incremental improvements to third party app support: apps actually running natively on the watch, custom watch face complications, new capabilities, better performance, and a better way of launching apps (a list!). But the great new app platform imagined when the watch was first announced has still to arrive and many apps on your Apple Watch today likely still date back to the original release.
\nI don't know what it will take for the Apple Watch platform to become as successful as the Apple Watch but I don't think the capability of the device or the OS is holding it back at this stage (though WatchKit does leave a lot to be desired.) I'd like to see watch apps completely decoupled from iPhone apps (they run on the watch now, but are still delivered as extensions of iPhone apps) and they need to have more ways to integrate with or at least appear on the watch face. At least then we might finally be able to rule out finding, installing and launching watch apps as the reason for there not being very many good ones.
\nWhy Can't We Just Pay for Free Unlimited iCloud Storage?
\nOver the past few years Apple has proven that they're willing to try charging higher prices for iPhone. Just a couple of years ago the 6S plus was priced from $749, a year later the 7 plus was available from $769 and now the 8 plus is on sale from $799. Meanwhile, the market has shown it's happy to pay those prices and I suspect it will prove so once more with the impending $999 iPhone X.
\nWhat I'd like to see next year is for Apple to charge us even more money for phones that don't cost them anything extra to produce, and here's why:
\nThe experience of figuring out that you might need an iCloud subscription, figuring out how much space you might need, paying for it, dealing with the inevitable failures to renew when your card expires or your balance is low, and getting warnings about backups failing is awful. I'd love to see Apple try to figure out the cost of providing all new iPhone users with unlimited (with an asterisk that says there's actually some limits) iCloud storage and build it into the price of the phone.
\nI pay Apple $35.88 for iCloud storage each year, I'd happily pay $99 more for the phone instead.
\nAudio Degapinator - The Poor Dev’s Smart Speed
\nI've been listening to podcasts with Overcast's Smart Speed feature turned on for long enough to have saved 55 hours of not listening to the silences between every podcast host's thoughts.
\nI decided to spend 1 of those hours today making my own simple, but surprisingly effective AVAudioPlayer version of that feature. I'll explain below how it works, but you can check out the full Swift iOS source (there's not much to it) on GitHub: Audio Degapinator on GitHub.
\nAVAudioPlayer offers features for audio level metering:
\n/* metering */\n \nopen var isMeteringEnabled: Bool /* turns level metering on or off. default is off. */\n\nopen func updateMeters() /* call to refresh meter values */\n\nopen func peakPower(forChannel channelNumber: Int) -> Float /* returns peak power in decibels for a given channel */\n\nopen func averagePower(forChannel channelNumber: Int) -> Float /* returns average power in decibels for a given channel */And for adjusting playback, including:
\nopen var rate: Float /* See enableRate. The playback rate for the sound. 1.0 is normal, 0.5 is half speed, 2.0 is double speed. */My code then:
\n• turns metering on
\n • updates meters with a timer
\n • checks if there is currently silence playing using averagePower
\n • increases the playback rate 2x until the silence ends
I tested using the latest episode of ATP and Debug episode 49. In both cases the silences were noticeably reduced and, to my ear, sounded completely natural. I listened to the entire episode of Debug and it had shaved off a little over 3 minutes by the end.
\nThis was a fun little project, it's the first time I've looked at anything related to audio playback on iOS in quite a while and it was super interesting ... I fear I may just have to write my own podcast app now.
\nSimulating Universal Gravitation with SpriteKit
\nGravity in SpriteKit is a single planet sort of gravity. By that I mean that it applies a single force to all bodies in the simulation - basically everything falls down. But what if you wanted a mutliple planet sort of gravity, can that be achieved in SpriteKit?
\nThe answer is yes, and it turns out it's it doesn't take a whole lot of code to get some fun and quite realistic results.
\n![\"Screen](\"https://mbehan.com/assets/posts/fgmmr.gif\")
In this SpriteKit app, dragging on the screen creates a new 'planet'.
\nFirst we turn off gravity as it normally applies in a SpriteKit scene and then on every tick we apply Newton's law of universal gravitation to all the nodes in the physics simulation.
\n![\"F=G](\"https://upload.wikimedia.org/wikipedia/commons/0/0e/NewtonsLawOfUniversalGravitation.svg\")
That is for every pair of nodes, apply a force to each one that is equal to the product of their masses (and the universal gravitational constant), divided by the distance between them, squared.
\nThere are some tweaks to the above formula to make the numbers a bit easier to deal with (i.e. smaller) and to make creating stable systems a bit easier, but sticking exactly to the formula above and plugging in some realistic numbers things work pretty much as you'd expect.
\nIn addition to simulating gravity, I'm also combining planets that pass close to each other and adding trails to trace their paths and giving new planets random colour. It all results in a surprisingly fun and addictive little toy so even if you're not interested in the code just build and run it on your iPhone (or watch, or Mac) and enjoy!
\nGet the code at github.com/mbehan/fgmmr.
\nDetecting Which Complication Launched Your WatchKit App
\nOne of the joys of working with watchOS, much like it was working with iPhone OS many years ago, is the enforced simplicity. Free from worrying about about the unending device combinations and configurations and the unlistible features and extension points of modern iOS the constraints of a limited SDK focus your creativity. Simple, robust, yet still delightful interfaces flow from your fingertips, designers designs are readily translated to working product.
\nSadly though, we're not content for long. Just like in the early days of iPhone OS, you soon find yourself wanting to do just a tiny bit more than Apple has made available, and so focus and delight makes way to our more common friend, the ugly hack. Today's feature that just couldn't wait for a proper API is: detecting which watch face complication launched my app.
\nWhen your app is launched in response to the user tapping a complication, the handleUserActivity method of your WKExtensionDelegate is called. You're given a userInfo dictionary, and this is where we'd hope to find the details of which complication had launched us. Sadly though there's no CLKComplicationFamilyKey to let you know the user tapped the circular small rather than the utilitarian large to launch the app, but there is something we can use, the CLKLaunchedTimelineEntryDateKey. This gives us the exact date and time that the complication was created at. By remembering exactly when we created which complication then we can figure out which complication resulted in the app being launched and acting accordingly.
// 1.\nclass ComplicationTimeKeeper{\n \n static let shared = ComplicationTimeKeeper()\n \n var utilitarianLarge : Date?\n var utilitarianSmall : Date?\n var circularSmall : Date?\n var modularLarge : Date?\n var modularSmall : Date?\n}\n\n// 2. in your CLKComplicationDataSource\nfunc getCurrentTimelineEntry(for complication: CLKComplication, withHandler handler: @escaping ((CLKComplicationTimelineEntry?) -> Void)) { \n \n // Call the handler with the current timeline entry\n switch complication.family {\n case .utilitarianLarge:\n \n let date = Date()\n ComplicationTimeKeeper.shared.utilitarianLarge = date\n \n let template = CLKComplicationTemplateUtilitarianLargeFlat()\n template.textProvider = CLKSimpleTextProvider(text:\"Something\")\n \n let timelineEntry = CLKComplicationTimelineEntry(date: date, complicationTemplate: template)\n handler(timelineEntry)\n \n default: handler(nil)\n }\n}\n\n// 3. in your WKExtensionDelegate\nfunc handleUserActivity(_ userInfo: [AnyHashable : Any]?) {\n \n guard let userInfo = userInfo, let timelineDate = userInfo[CLKLaunchedTimelineEntryDateKey] as? Date else{\n return\n }\n \n if let utilLarge = ComplicationTimeKeeper.shared.utilitarianLarge, timelineDate.compare(utilLarge) == .orderedSame {\n WKExtension.shared().rootInterfaceController?.pushController(withName: \"SomeController\", context: nil)\n }\n}In 1, we create a singleton (no shameful hack is complete wihtout one) to track when our various complications were made.
\nIn 2, we setup the utilitarian large complication and store the creation date, just add more cases to the switch statement for other complication families that you are supporting.
\nFinally in 3 we check what time the complication that launched the app was created and check which one it was and launch the relavant interface controller.
\nThe code above has a couple of limitations that you may need to work around. First it doesn't take Time Travel into account so if your app supports that each complication may have more than one corresponding datetime. Secondly (though in practice I haven't seen this be an issue) I don't see why two complications couldn't have clashing datetimes, for that you could add a method to ComplicationTimeKeeper that returns the next unique date.
It's Time For Complications
\nApple made much of the value of complications at this years WWDC. Having originally not allowed you to make your own in watchOS 1, to allowing you but telling you its only if you really have something super important that gets updates throughout the day in watchOS 2, now this year they told us we really need to have a complication even if its just an icon to launch your app. It seems they've noticed, as anyone who has worn Apple Watch for any reasonable amount of time will tell you, that complications are the best way to access the functionality of an app. But everything they talked about at WWDC was about having a complication, singular. You can support multiple complication families, but you can only have one of each and they are treated as different views of a single feature, showing more data when you've the room, but not really doing anything different.
\nIdeally, we'd have the ability to provide multiple complications for each complication family. If that was the case you could have a watch face with each complication slot filled by the same application, each showing something else (the built in world clock complication can already do this, but nothing else) and crucially each performing a different function of your app when they're tapped. I wouldn't be surprised if this is something that is eventually supported in WatchKit, but for now at least we can ugly hack our way to using different complication families to provide different functionality.
\nShould Apple Deprecate UILongPressGestureRecognizer?
\nThe answer is yes.
\n• For anywhere you currently require a long press, move to 3D touch.
\n • For anywhere you have different actions for both, make the long press action an option when 3D touching. (For example organising icons on the home screen.)
\n • Make an accessibility preference that makes a long press behave as a progressively more forcefull 3D touch.
Cheating on Swift Substrings
\nIf you found yourself needing to get a substring of a String in Swift before you got around to the relavant chapter of the book you were probably left scratching your head for a bit. How could something so conceptually simple be so akward to perform?
\nHere's a great article explaining how to find a substring in Swift, from Natasha The Robot.
\nIt turns out that Swift's strings are much cooler than your old fashioned strings from other languages, and Swift Ranges are even cooler still. But unless you're using them frequently, I find that
\nstr.substringWithRange(Range(start: (advance(str.endIndex, -1)), end: str.endIndex))doesn't exactly roll off the tongue.
\nSo here's my cheat, which is to not use String at all. Arrays in Swift can be chopped up using plain integer ranges, and a String is just an Array. Swift even lets you iterate over the contents of a String and access each Character in turn, but it doesnt give you string subscripting.
So theres a couple of cheat options, implement subscript on String yourself, or what I preferred, extend String to give you quick access to an Array representation of the string.
extension String {\n func asArray() -> [Character] {\n \n var array : [Character] = []\n for char in self {\n array.append(char)\n }\n return array\n }\n}You can then do fun stuff like this, which for me, reads very nicely.
\nlet str = \"Coma inducing corporate bollocks\"\nstr.asArray().last // \"s\"\nstr.asArray()[10] // \"i\"\nString(str.asArray()[2..<7]) // \"ma in\"You don't need to break out the big O notation to see this isn't going to perform great, you're iterating over the entire string everytime you want to get a piece of it, then the array methods are going to go do it again, so use with caution!
\nDeath By Date Format String
\nRecently I learned that you probably always want \"yyyy\" and not \"YYYY\".
\nlet dateFormatter = NSDateFormatter()\ndateFormatter.dateFormat = \"YYYY-MM-dd\"\n\nprintln(dateFormatter.stringFromDate(\n dateFormatter.dateFromString(\"2015-12-26\")!))This prints 2015-12-26. Obviously. So what about
\nprintln(dateFormatter.stringFromDate(\n dateFormatter.dateFromString(\"2015-12-27\")!))It prints 2016-12-27.
\nNote that the year is 2016.
\nI was fortunte enough to get assinged a production crash bug this week that after a long day of head scratching, turned out to be caused by this.
\nInterestingly, the NSDate created with the format is the date I expected, it represents 27 December 2015 and it's only getting a string from the date with that format that gives you the 'wrong' year. Similarly an NSDate constructed in any other way that represents 27 December 2015 will behave the same.
The NSDateFormatter docs point you at Unicode Technical Standard Number 35 for the definitions of date format strings. I've looked at this before and I expect I'm not alone in having paid more attention to the day and month parts of the format. They're usually what we're interested in because the year is always the year, at most we might prefer 2 or 4 digits but thats about as interesting as it gets. I suspect what happens fairly often (and what probably happened with our bug) was that the developer guessed at YYYY as the year format, and when it appeared to work just fine, assumed it was correct.
The relavant part of that standard states that y is the year, but Y is
\nYear (in \"Week of Year\" based calendars) ... May not always be the same value as calendar year.\n
And the problem is that, as far as I can tell, it almost always is the same as the calendar year. The last few days of the year are the only ones I've seen causing problems. If it was more different, it would be spotted easier and perhaps I would have already known that YYYY was wrong and spotted that as the error right away.
\nOptional Optionals
\nSo here's a confusing sentence.
\nWith Swift functions you can have optional parameters, you can also have parameters that are optionals, and you can have optional parameters that are optionals.
\n![\"A](\"https://mbehan.com/assets/posts/donald-rumsfeld.png\")
Not taking the time to think about the 3 different levels of optionality in function parameters had me scratching my head for a few minutes today, but all the options (sorry) are useful and it's not all that confusing once you remember them.
\nMy scenario was that I created a function that does some stuff and then executes a closure supplied by the caller. Something like
\nfunc doSomeStuff(thenDoThis:()->())Which a caller would call like
\ndoSomeStuff {\n\t// and then do this stuff\n}But I want to let the caller decide whether they want to supply the closure or not, so if they like they could just call the function and be done.
\ndoSomeStuff()So let's make the closure optional. Easy, as with any type in Swift, we can mark it optional by including a ?
\nfunc doSomeStuff(thenDoThis:(()->())?)So then if we go ahead and call
\ndoSomeStuff() // Error: Missing argument for parameter #1 in callBut it was optional, so why the error? Well it wasn't optional in the sense that I could leave it out, it's just that it was an optional type which we are still expected to provide every time. As our type is an optional closure with no parameters and no return, we have to supply a closure with no parameters and no return or nil. So we'd actually have to call
\ndoSomeStuff(nil) // this works fine but isn't what we wantSo how do you create an optional parameter, one that a caller can decide to leave out? To do that you provide a default value to be used for that parameter, right in the function declaration.
\nfunc doSomeStuff(thenDoThis:()->() = defaultClosure)This means that if the caller doesn't supply a value for thenDoThis we'll use defaultClosure instead (assuming defaultClosure is defined elsewhere as a ()->().) We can now happily call the following if we don't want to supply a closure.
\ndoSomeStuff() // yay!The behaviour I was interested in though was that if I didn't supply a closure, that there would be no closure executed at all, not that some other one I had to define would be called instead. Well, I could just make defaultClosure do nothing, or just have the default value be {} like
\nfunc doSomeStuff(thenDoThis:()->() = {})Which is fine, and maybe even the preferred way, but you can also have an optional optional parameter, and have it's default value be nil.
\nfunc doSomeStuff(thenDoThis:(()->())? = nil)Now if the caller omits the closure, thenDoThis will be nil, which makes more sense to me in this situation.
\nBasic ORM on top of FMDB and SQLite with Objective-C
\nThe FMDB wrapper simplifies using SQLite it from Objective-C. A typical scenario is that you'll execute a query and get back a lovely FMResultSet object and you can extract values from that using your database column names - nice.
What would be slightly nicer thought is automatically mapping that result set onto a model object. So lets make that a thing.
\nExample
\nWe have a table in our database called People with the following fields:
\n• personId
\n • firstName
\n • lastName
\n • address
\n • favouriteSimpsonsReference
And it makes sense for us to have a Person class in our app because maybe we'll want to maintain a table of people and be able view the detail of a person by passing a Person from the table view to the detail view. The Person class will be defined something like this:
\n@interface Person : NSObject\n\n@property(nonatomic) NSInteger personId;\n@property(nonatomic, copy) NSString *firstName;\n@property(nonatomic, copy) NSString *lastName;\n@property(nonatomic, copy) NSString *address;\n@property(nonatomic, copy) NSString *favouriteSimpsonsReference;\n\n@endSo to create some Person objects we could alloc init a bunch of them and set their properties based on what we get back from the database, alternatively we could create a custom initialiser method to take a FMResultSet and set them all that way. All of which is perfectly fine until you find yourself repeating it over and over again.
![\"Homer](\"https://mbehan.com/assets/posts/homer-making-oj.png\")
For simple situations like this though, there is a better way.
\nHere's the class that I use as a base class for all my model objects, it provides an initialiser that takes a result set as a parameter and looks for columns in that result set with the same name as its properties.
\n@interface MBSimpleDBMappedObject : NSObject\n\n-(instancetype)initWithDatabaseResultSet:(FMResultSet *)resultSet;\n\n@end-(instancetype)initWithDatabaseResultSet:(FMResultSet *)resultSet\n{\n self = [super init];\n if(self)\n {\n unsigned int propertyCount = 0;\n objc_property_t * properties = class_copyPropertyList([self class], &propertyCount);\n \n for (unsigned int i = 0; i < propertyCount; ++i)\n {\n objc_property_t property = properties[i];\n NSString *propertyName = [NSString stringWithUTF8String:property_getName(property)];\n \n [self setValue:[resultSet objectForColumnName:propertyName] forKey:propertyName];\n }\n free(properties);\n }\n \n return self;\n}\n\n@endWhat we're doing here is quite simple, but it's enabled by a couple of powerful Objective C features. Firstly, at runtime we can dynamically retrieve the names of a loaded classes properties, then we can simply set the values of properties using key value coding.
\nThose are the only 2 things happening here, get a list of the properties, then for each property set its value to the one from the result set with a matching column name.
\nThis means all our model subclasses have to do is declare a bunch of properties, so all there is to those classes is the interface I described before, just subclassing MBSimpleDBMappedObject instead of NSObject like so.
\n@interface Person : MBSimpleDBMappedObject\n\n@property(nonatomic, readonly) NSInteger personId;\n@property(nonatomic, readonly, copy) NSString *firstName;\n@property(nonatomic, readonly, copy) NSString *lastName;\n@property(nonatomic, readonly, copy) NSString *address;\n@property(nonatomic, readonly, copy) NSString *favouriteSimpsonsReference;\n\n@endI've marked the properties read only, because all I'm interested in is a copy of what's in the database, changing the values of those properties won't update the database, though I do plan to add that functionality in the future. If this is all you need then you're done, your Person implementation can be left blank.
\nIf you're familiar with SQLite and FMDB you'll know they don't really do dates, but you'll probably find yourself wanting to keep track of some dates in the database. FMResultSet's objectForColumnName will gladly give you a number or a string, but it doesn't do NSDate's. Here's how I deal with that.
\nLet's change our People table a bit to make it a bit more useful, so our list of fields looks like:
\n• personId
\n • firstName
\n • lastName
\n • address
\n • dateOfBirthTimestamp
and update our Person interface too
\n@interface Person : MBSimpleDBMappedObject\n\n@property(nonatomic, readonly) NSInteger personId;\n@property(nonatomic, readonly, copy) NSString *firstName;\n@property(nonatomic, readonly, copy) NSString *lastName;\n@property(nonatomic, readonly, copy) NSString *address;\n@property(nonatomic, readonly)NSTimeInterval dateOfBirthTimestamp;\n@property(nonatomic, readonly, strong)NSDate *dateOfBirth;\n\n@endWith no other changes the dateOfBirthTimestamp property will be set correctly which may be enough, but you'd probably have to make an NSDate with it anytime you wanted to do anything useful with it. We've added an NSDate property, but as there is no corresponding column name, it will remain nil. That is until we override the initialiser as follows.
\n-(instancetype)initWithDatabaseResultSet:(FMResultSet *)resultSet\n {\n self = [super initWithDatabaseResultSet:resultSet];\n if(self)\n {\n _dateOfBirth = [NSDate dateWithTimeIntervalSince1970:self.dateOfBirthTimestamp];\n }\n return self;\n\n}\n\n@endThe base class will still map all the other properties, we just construct the NSDate.
\nUploading Xcode Bot Builds to Testflight, with launchd
\nContinuous integration with Xcode is super easy to set up and does the basics of continuous integration really well. With almost no effort you'll have nightly builds, test suites doing there thing, email alerts to committers, lovely graphs and even a cool dashboard thing for your big screen. I won't go through setting that all up here, the Apple docs are excellent and there are plenty of other people who've already explained it better than I will.
\nWhere things are less than straightforward is when you want to use the IPA file produced–to send it to your testers via TestFlights, or to your remote teammates, your client or whoever.
\nThe server executes an Xcode scheme, which defines your targets, build configuration, and tests. In the scheme there's an opportunity to include custom scripts that run at various points, pre and post each of the schemes actions, so you can run a script pre-build or post-archive etc.
\nThis post-archive step is the last place we can do some work, so it's the obvious place to go upload our build to TestFlight, right? Well it would be except the IPA file never exists at this point. The IPA file is generated some time after this. The process is:
\n• Archive
\n • Post archive scripts
\n • ???
\n • Generate IPA file
So if you want to upload to TestFlight what can you do? Well the solution offered by anyone I've seen blogging about it is to go make your own IPA using xcrun. That doesn't sound so bad until you end up with code signing and keychain issues and it's all to do something that is about to happen as soon as you're done anyway.
\nMy solution was to just wait until the IPA file was made. My initial naive attempts were to schedule the upload from the post-archive script using at or simply adding a delay for some amount of time while the IPA file didn't exist. What I should have realised though is that the Bot will wait as long as I'm waiting and only when my script finishes will it continue and make the IPA file.
\nlaunchd to the rescue.
\nWhat I've ended up with, and which is working nicely for us, is a scheduled job on the build server which will notice any IPA files built by an Xcode bot, and upload them. I wasn't familiar with launchd prior to this and was excepting to use cron, but it turns out this is the modern OSX way for scheduling jobs. There's a great site showing you how to use launchd but I'll show you what I have anyway.
\nWhat I have:
\n1. A plist for launchd 2. Plists for each project that explain where to send the build 3. A shell script that looks for IPA files and sends them to TestFlight or FTP using the information from 2.
\n2. The launchd plist
\nThis is placed in /Library/LaunchDaemons and simply tells launchd that we want to run our script every 600 seconds. You could schedule it to run once a day or any other interval, I left it at 10 minutes so any bots that are run on commit or are started manually will have their builds uploaded right away rather than at the end of the day.
\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<plist version=\"1.0\">\n<dict>\n\t<key>Label</key>\n\t<string>com.mbehan.upload-builds</string>\n\t<key>ProgramArguments</key>\n\t<array>\n\t\t<string>/ci_scripts/build-uploader.sh\n\t\t\t<key>StartInterval</key>\n\t\t\t<integer>600</integer>\n\t\t\t<key>StandardOutPath</key>\n\t\t\t<string>/tmp/build-uploads.log</string>\n\t\t\t<key>StandardErrorPath</key>\n\t\t\t<string>/tmp/build-uploads.log</string>\n\t\t</dict>\n\t</plist>\n</key>3. Per project plist
\nIf we want the build to be uploaded automatically, it needs a plist telling it where to go. We share builds with one of our clients via FTP so there is a method key for that and a different set of keys are required if it's value is to FTP rather than TestFlight. I keep these plists in the same directory as the script.
\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<plist version=\"1.0\">\n<dict>\n\t<key>Method\n\t\t<string>TestFlight</string>\n\t\t<key>ProductName</key>\n\t\t<string>Some App.ipa\n\t\t\t<key>APIToken</key>\n\t\t\t<string>GET THIS FROM TESTFLIGHT\n\t\t\t\t<key>TeamToken</key>\n\t\t\t\t<string>AND THIS</string>\n\t\t\t</dict>\n\t\t</plist>\n\t</key>\n</key>4. Checking for IPA files, uploading
\nWe're using find with the -mtime option here to find recently created files with the name specified in the plist. If we find a file we then either use curl to upload to TestFlight or we send it via FTP depending on the method indicated in the plist.
\nYou can remove the stuff for FTP if you only care about TestFlight, and you might want to add extra detail to the plist such as distribution lists.
\n#!/bin/bash\n\nfiles=/ci_scripts/*.plist\n\nfor f in $files\ndo\n\techo Processing $f \"...\"\n\tproductName=\"$(/usr/libexec/plistbuddy -c Print:ProductName: \"$f\")\"\n\t\n\techo $productName\n\tipaPath=$(find /Library/Server/Xcode/Data/BotRuns/*/output/\"$productName\" -mtime -15m | head -1)\n\t\n\tif [ ${#ipaPath} -gt 0 ]; then\n\t\techo \"Have IPA FILE: \" $ipaPath\n\t\t\n\t\tmethod=\"$(/usr/libexec/plistbuddy -c Print:Method: \"$f\")\"\n\t\t\n\t\tif [ $method == \"FTP\" ]; then\n\t\t\techo \"Attempting FTP ...\"\n\t\t\t\n\t\t\thost=\"$(/usr/libexec/plistbuddy -c Print:FTPHost: \"$f\")\"\n\t\t\tuser=\"$(/usr/libexec/plistbuddy -c Print:UserName: \"$f\")\"\n\t\t\tpass=\"$(/usr/libexec/plistbuddy -c Print:Password: \"$f\")\"\n\t\t\tfilename=\"$(/usr/libexec/plistbuddy -c Print:FileNameOnServer: \"$f\")\"\n\t\t\thostDir=\"$(/usr/libexec/plistbuddy -c Print:DirectoryOnServer: \"$f\")\"\n\n\t\t\tdate=`date +%y-%m-%d`\n\n\t\t\tftp -inv $host <<-ENDFTP\n\t\t\tuser $user $pass\n\t\t\tcd $hostDir\n\t\t\tmkdir $date\n\t\t\tcd $date\n\t\t\tbinary\n\t\t\tput \"$ipaPath\" \"$filename\"\n\t\t\tbye\n\t\t\tENDFTP\n\t\t\t\n\t\telif [ $method == \"TestFlight\" ]; then\n\t\t\techo \"Attempting TestFlight ...\"\n\t\t\t\n\t\t\tapiToken=\"$(/usr/libexec/plistbuddy -c Print:APIToken: \"$f\")\"\n\t\t\tteamToken=\"$(/usr/libexec/plistbuddy -c Print:TeamToken: \"$f\")\"\n\t\t\t\n\t\t\t/usr/bin/curl \"http://testflightapp.com/api/builds.json\" \\\n\t\t\t -F file=@\"$ipaPath\" \\\n\t\t\t -F api_token=\"$apiToken\" \\\n\t\t\t -F team_token=\"$teamToken\" \\\n\t\t\t -F notes=\"Automated Build\"\n\t\tfi\n\tfi\ndoneThis all assumes you've set your provisioning profile and code signing identity up correctly for the build configuration used by your Xcode scheme. Make sure the configuration used in the archive step (Release by default) will make a build the people you want to share builds with will be able to install.
\nDynamic Image Lighting with CoreImage
\nWith the kind of apps I usually make, I often end up doing a lot of gamey looking things right inside of UIKit. The addition of UIDynamics made one of those jobs, gravity, super easy. I wanted the same kind of simplicity for lights.
\n![\"Animated](\"https://mbehan.com/assets/posts/luminator-demo.gif\")
It only works on image views for now, but it works well and frame rates are good (much better than the gif lets on) for all but very large images on older devices. You can get all the code on github and using it should be pretty simple.
\nYou just create a lighting controller, add some light fixtures and image views you want to be lit to the controller, and let it know when you need to update the lighting (when we're moving the lights in the example above). Here's the interface for the MBLightingController:
\n@interface MBLightingController : NSObject\n\n@property(nonatomic) BOOL lightsConstantlyUpdating;\n\n-(void)addLightFixture:(id<MBLightFixture>)light;\n-(void)addLitView:(MBLitAnimationView *)litView;\n-(void)setNeedsLightingUpdate;\n\n@endOnly set lightsConstantlyUpdating if the lighting is always changing (this came about because I was playing around with adding a light to a rope with UIDynamics, which you can see in the project on github.)
So, there are a couple of things there that you won't know what they are, the MBLightFixture protocol, and MBLitAnimationView.
Anything can be a light, so long as it implements the protocol, which means it needs a position, intensity, range and color. I've just been using a UIView subclass but maybe your light will be a CAEmitterLayer or something.
MBLitAnimationView can be used everywhere you'd use a UIImageView, it just adds the ability to be lit, and makes working with animation easier.
Your view controller's viewDidLoad might include something like this:
\n//create the ligthing controller\nself.lightingController = [[MBLightingController alloc] init];\n \n//add an image to be lit\nMBLitAnimationView *bg = [[MBLitAnimationView alloc] initWithFrame:self.view.bounds];\nbg.ambientLightLevel = 0.1; // very dark\n[bg setImage:[UIImage imageNamed:@\"wall\"]];\n[self.view addSubview:bg];\n[_lightingController addLitView:bg];\n \n//add a light\nSimpleLightView *lightView = [[SimpleLightView alloc] initWithFrame:CGRectMake(200, 200, 25, 25)];\nlightView.intensity = @0.8;\nlightView.tintColor = [UIColor whiteColor];\nlightView.range = @250.0;\n \n[self.view addSubview:lightView];\n[_lightingController addLightFixture:lightView];The light effect is achieved using CoreImage filters and everything happens in the applyLights method of MBLitAnimationView.
I experimented with a bunch of different filters trying to get the right effect, and there were several that worked so just try switching out the filters if you want something a little different.
\nMultiple filters are chained together, first up we need to darken the image using CIColorControls:
CIFilter *darkenFilter = [CIFilter filterWithName:@\"CIColorControls\"\n keysAndValues:\n @\"inputImage\", currentFrameStartImage,\n @\"inputSaturation\", @1.0,\n @\"inputContrast\", @1.0,\n @\"inputBrightness\", @(0-(1-_ambientLightLevel)), nil];Then, for every light that we have, we create a CIRadialGradient:
CIFilter *gradientFilter = [CIFilter filterWithName:@\"CIRadialGradient\"\n keysAndValues:\n @\"inputRadius0\", [light constantIntensityOverRange] ? [light range] : @0.0,\n @\"inputRadius1\", [light range],\n @\"inputCenter\", [CIVector vectorWithCGPoint:inputPoint0],\n @\"inputColor0\", color0,\n @\"inputColor1\", color1, nil];Then we composite the gradients with the darkened image using CIAdditionCompositing:
lightFilter = [CIFilter filterWithName:@\"CIAdditionCompositing\"\n keysAndValues:\n @\"inputImage\", gradients[i],\n @\"inputBackgroundImage\",[lightFilter outputImage],nil];Finally, we mask the image to the shape of the original image:
\nCIFilter *maskFilter = [CIFilter filterWithName:@\"CISourceInCompositing\"\n keysAndValues:\n @\"inputImage\", [lightFilter outputImage],\n @\"inputBackgroundImage\",currentFrameStartImage,nil];Just set the image view's image property to a UIImage created from the final filter's output and we're done!
\nCGImageRef cgimg = [coreImageContext createCGImage:[maskFilter outputImage]\n fromRect:[currentFrameStartImage extent]];\n \nUIImage *newImage = [UIImage imageWithCGImage:cgimg];\nimageView.image = newImage;\n \nCGImageRelease(cgimg);Playing with CoreImage was fun so I think I'll revisit the code at some point in the future, I'd like to try it out with SpriteKit's SKEffectNode where it really makes more sense for using with games. Or I might keep working with UIKit and get it working for any view–shiny / shadowy interfaces might be interesting.
Higher Performance UIImageView Animation
\nAnimation with UIImageView is super simple and for basic animations it is just what you need. Just throw an array of images at your image view and tell it to go, and it will go. For animations of more than a few frames though its simplicity is also its failing–an array of UIImage s is handy to put together but if you want large images or a reasonable number of frames then that array could take up a serious chunk of memory. If you've tried any large animations with UIImageView you'll know things get crashy very quickly.
There are also a few features, like being able to know what frame is currently being displayed and setting a completion block that you regularly find yourself wanting when dealing with animations, so I've created MBAnimationView to provide those, and to overcome the crash inducing memory problems.
\nThe premise for the memory improvements is the fact that image data is compressed, and loading it into a UIImage decompresses it. So, instead of having an array of UIImage objects (the decompressed image data), we're going to work with an array of NSData objects (the compressed image data). Of course, in order to ever see the image, it will have to be decompressed at some point, but what we're going to do is create a UIImage on demand for the frame we want to display next, and let it go away when we're done displaying it.
So the MBAniamtionView has a UIImageView, it creates an array of NSData objects and then on a timer creates the frame images from the data, and sets the image view's image to it, it's that simple.
Check out MBAnimationView on github
\nCreating a Rope with UIDynamics
\nI've made rope simulations for games with Box2D before but I wanted to see if I could make a rope that could be used easily with UIKit elements, and without having to use Box2D directly. Below is the result, a highly practical user interface, I'm sure you'll agree!
\n![\"A](\"https://mbehan.com/assets/posts/rope.gif\")
There are 2 distinct problems to consider when create a rope:
\n1. The physics joint that connects two elements together as though they were connected with a rope 2. Drawing the rope
\nBox2D has a bunch of different joints for connecting physics bodies and b2RopeJoint is just what you need to solve problem 1. UIDynamics though, only exposes 1 joint for us to join dynamic bodies through UIAttachmentBehavior. Fortunately the joint it appears to be using under the hood is b2DistanceJoint which, with the right amount of parameter fiddling, can be made into a b2RopeJoint.
\nSo thats problem 1 sorted, right? Just draw the rope with the help of some verlet integration and you're done? Well I could be done, but I wanted to try something different and a bit more light weight, something that didn't involve wikipedia pages full of equations to understand fully.
\nMore Chain Than Rope
\nBy simply connecting a series of small views by their ends with UIAttachmentBehavior you get a chain, with enough links in that chain, and with the right attachment parameters you can get something that behaves pretty rope like. You can attach one view to another like so:
\nUIAttachmentBehavior *chainAttachment = [[UIAttachmentBehavior alloc] initWithItem:view1 attachedToItem:view2];I just do this in a loop, joining together a whole bunch of views. It ends up looking like this not very ropey looking thing.
\n![\"Connected](\"https://mbehan.com/assets/posts/rope-2.png\")
But there's no reason why, just because we're using the views to create the rope like joint, that we have to look at the views. Instead I draw a path connecting their centres
\n[path moveToPoint:[links[0] center]];\nfor(int i = 1; i < links.count; i++)\n{\n [path addLineToPoint:[links[i]center]];\n}and we end up with what you see up top.
\nAll the code is on github. It still needs a bit of work but you can get a simple rope up and running with just a couple of lines of code. Import the header and do something like this:
\nMBRope *rope = [[MBRope alloc] initWithFrame:CGRectMake(350, 180, 5, 200) numSegments:15];\n[self.view addSubview:rope];\n[rope addRopeToAnimator:animator];To attach something, like the button in the example, you can get the last view by calling attachmentView on the rope and attach your other view with your own UIAttachmentBehavior. The top of your rope will be fixed to the origin of the rect supplied when you init the rope, but it wouldn't take much to change it so you can attach your own stuff to both ends.
\nStoryboards, Multiple Developers and Git.
\nStoryboards are great. You can get the flow of your app set up in a few minutes without writing a line of code, you can initialise your navigation controllers and tabs ridiculously easily and zoom out a bit and you get a lovely picture of your entire app on a single screen, with lines and boxes and everything.
\nBut storyboards can be cruel if you're not careful. Git pulls become nervy affairs, a slip merging by hand can render your storyboard unreadable by Xcode and not knowing when to stop using them can turn your lovely lines and boxes into a maintenance nightmare.
\n![\"John](\"https://mbehan.com/assets/posts/mcclane-before.jpg\")
\"Come to the coast, we'll get together, have a few segues\"
\nI've worked on a bunch of apps of all shapes and sizes using storyboards over the last year or so as part of a team and we've been working on perfecting our use of them. I've been investigating and testing storyboard best practice and this is what I've learned so far.
\nThe Precap
\n \n• Everyone on the same build of Xcode
\n • Multiple storyboards
\n • Use Nibs for custom views
\n • One person owns the storyboard setup / decides granularity
\n • Think about which storyboards are involved when assigning tasks
\n • Merge storyboards often
\n • Xcode is your git client
Xcode
\nWe've had hassle sharing storyboards across even minor versions of Xcode, storyboards created in one will do crazy stuff in another, or just plain won't work. Don't let anyone sneak ahead to the latest developer preview unless they're doing a separate installation.
\nMultiple storyboards
\nBut what about the lovely whole app view, all those lovely lines and boxes all perfectly arranged? That was never what storyboards were about, and you've still got your whiteboard for that. Divide and conquer is your mantra for everything else you do so it should be for storyboards too. It's easier to reason about storyboards with a single purpose and devs are less likely to trip each other up if they're not working on the same storyboards at the same time.
\nSo how do you break it up?
\nPer user story is a decent approach, but that can be too granular at times. A separate storyboard for login and one for viewing an account makes sense, but maybe you should keep the lost password flow in with your login - If all you've got in each storyboard is a single view controller you might as well be using Nibs, the beauty of storyboards is making connections between view controllers.
\nBut you said to keep using Nibs?
\nYep, for custom views, table view cells and the like. A view can't exist outside a view controller in a storyboard so if you don't need a view controller for it you really shouldn't be adding it to a storyboard.
\nSo what about single view controllers in Nibs then?
\nWe've a project in which we've used some Nibs from an existing project in conjunction with a storyboard and it hasn't been a problem, but if I was making those components again now they'd be in a storyboard. Having a single view controller in a storyboard will make sense at times, and when you end up wanting to add additional screens to your account details say and all you have to do is drag a new view controller in beside the existing one and hook up a segue you'll be happy.
\nMultiple devs
\nEven with all your concerns perfectly separated, and making sure everyone's on the same page you're going to end up working on the same storyboard as someone else at the same time. Having to wait for someone to give you their changes before you can do something is no fun so I wanted to see just how careful you really have to be.
\nI created a simple Xcode project with a single storyboard and set out with my new git friend to put together a few screens.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-1.png\")
Test 1: Adding to the same empty view controller
\nI started off simply adding a label and having Testy add an empty Image View.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-2.png\")
We're working on the same view controller right away so I expected there to be a conflict to sort out and indeed there was.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-3.png\")
The XML is clearly not intended to be parsed by human eyes but this looks straight forward enough, I can see two separate additions so accepting one followed by the other should work fine. This looks just like the kind of conflict that comes up on .xcodeproj files when two devs are adding files.
\nIt worked, I had to look at some XML but nothing blew up, for extremely simple changes to the same view controller we don't have to worry too much.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-4.png\")
Test 2: Editing different view controllers
\nI added a lovely purple view to one view controller and had Testy add a view to a different view controller. We really shouldn't have any problems here
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-5.png\")
And we don't. It seems editing the same storyboard is fine so long as we keep to different view controllers. But, sometimes we might edit another view controller without meaning to, so I looked at some more scenarios …
\nTest 3: Rearranging parts of the storyboard that someone else changed
\nHere Testy has changed one of my purple boxes to green, and I've just been fiddling with the layout a bit, swapping the order of the 2 view controllers to the right.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-6.png\")
This auto merged and left us looking good, it chose my layout.
\nTest 4: Adding modified views to a Navigation Controller
\nWhen you're inferring screen elements such as the nav bar adding a navigation controller can affect a bunch of view controllers that someone else might have been working on. Here I've added a navigation controller while Testy's been changing some colours.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-7.png\")
To my surprise this auto merged just fine, the views that Testy was working on got the nav bar. It makes sense if you take a look at the XML, no nav bar is added as a child of the view controllers, the inferred setting is in there and Xcode knows what to do with that.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-8.png\")
Test 5: Making changes to a slightly more filled out view controller
\nThings have gone ok so far, so lets revisit editing the same view controller, this time making it a bit more realistic.
\nWe both started off with this
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-9.png\")
All I did was enclose the label in a scroll view, Testy had a few more bits and pieces to do, he changed that label from an attributed label to a regular label, moved it, changed its text and changed the background colour of the view for good measure. We know we're going to be looking at XML here but that wasn't a problem before.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-10.png\")
And some of the XML here isn't so bad either.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-11.png\")
But it's clear that as soon as you make more than 1 simple change you've got a problem, and you could easily waste a lot of time dealing with it.
\n![\"\"](\"https://mbehan.com/assets/posts/storyboards-git-12.png\")
The order of of XML has changed between the versions significantly, and it doesn't seem to be too smart at highlighting which parts are the same. For example I didn't touch the table view in either revision but Xcode highlighted it being removed on one side and added in again in the middle of a bunch of other stuff later on.
\nIt ended up only taking a few minutes to figure this example out and getting to a version that made sense including both sets of changes but I was hand editing the XML and that is dangerous. It's clear that if you make more than a few changes and keep them for yourself for too long, you could end up in a bad way pretty quickly.
\nXcode as git client you say?
\nThis might be more of a personal preference, and if you want to rebase rather than merge this is a not an option (for now at least) but it seems screwing up the storyboard XML is likely to happen less frequently if you don't let anything other than Xcode touch it.
\nA conclusion, for now
\nAfter experimenting a little with this test project I'm happy that we can edit our storyboards simultaneously when we absolutely have to, but that shouldn't stop us planning things out so that it doesn't happen, and we'll be sticking to this list, same one as above:
\n• Everyone on the same build of Xcode
\n • Multiple storyboards
\n • Use Nibs for custom views
\n • One person owns the storyboard setup / decides granularity
\n • Think about which storyboards are involved when assigning tasks
\n • Merge storyboards often
![\"Who](\"https://mbehan.com/assets/posts/mcclane-after.jpg\")
Drawing Physics with SpriteKit
\nThere are plenty of games out there with this basic mechanic already but I wanted to see if it could be done easily using SpriteKit, spoiler alert: it can.
\n![\"Shapes](\"https://mbehan.com/assets/posts/spritekit-physics.gif\"){kind=icon}
The code is on github, knock yourself out
\nI make use of some handy dandy categories on UIBezierPath made by other people, they are:
\n• Creating a UIImage from a path, taken from this stackoverflow answer
\n • A couple from the iOS6 cookbook that make dealing with the points that make up a path much easier
We’re combining UIKit and SpriteKit here so we’re layering a transparent UIView on top of an SKView.
The SKView presents a single scene, it will contain our shapes and has a bounding static physics body to stop them escaping. The view controller sets up the scene in standard fashion.
- (void)viewWillLayoutSubviews\n{\n scene = [[DropShapeScene alloc] initWithSize:self.view.bounds.size];\n scene.scaleMode = SKSceneScaleModeAspectFill;\n SKView *spriteView = (SKView *) self.view;\n [spriteView presentScene: scene];\n}We have a very simple UIView subclass that sits on top providing very basic drawing functionality - it will handle drawing a single path, once the drawing ends it passes the path to it’s delegate and forgets about it. The drawing is done similar to my previous post, here’s the delegate protocol.
@protocol SimplePathDrawingDelegate <nsobject>\n-(void)drawingViewCreatedPath:(UIBezierPath *)path;\n@endWe’ll let the view controller be the delegate, and thats where we do the interesting stuff, once it gets the drawn path.
\n-(void)drawingViewCreatedPath:(UIBezierPath *)path\n{\n CGRect pathBounds = CGPathGetPathBoundingBox(path.CGPath);\n \n UIImage *image = [path strokeImageWithColor:[UIColor greenColor]];\n SKTexture *shapeTexture = [SKTexture textureWithImage:image];\n SKSpriteNode *shapeSprite = [SKSpriteNode spriteNodeWithTexture:shapeTexture size:pathBounds.size];\n \n shapeSprite.position = CGPointMake(pathBounds.origin.x + (pathBounds.size.width/2.0), scene.frame.size.height - pathBounds.origin.y - (pathBounds.size.height/2.0));\n \n shapeSprite.physicsBody = [SKPhysicsBody bodyWithConvexHullFromPath:path];\n shapeSprite.physicsBody.dynamic = YES;\n [scene addChild:shapeSprite];\n}We take the drawn line on a journey from path, to image, to a texture that is applied to a sprite. That part is pretty straightforward, more tricky is using that path to create a physics body.
\nSKPhysicsBody gives us a number of options for creating physics bodies, they are:
\n+ bodyWithCircleOfRadius:\n+ bodyWithRectangleOfSize:\n+ bodyWithPolygonFromPath:\n+ bodyWithEdgeLoopFromRect:\n+ bodyWithEdgeFromPoint:toPoint:\n+ bodyWithEdgeLoopFromPath:\n+ bodyWithEdgeChainFromPath:There are a few there that will take a path and give us a body, perfect, right? Except on closer inspection only 1 of them will create a path that can be dynamic, and that one bodyWithPolygonFromPath: has the caveat
A convex polygonal path with counterclockwise winding and no self intersections.\n
Sadly any realistic user isn’t going to like having to draw nothing but convex polygonal counterclockwise paths with no intersections.
\nAdditionally, SpriteKit only lets us have bodies with 12 or fewer sides!
\nThere are a few approaches we could take for getting by these restrictions: multiple joined physics bodies, using Box2D directly to get around the limit on body vertices, but we’ll use a convex hull from the points that make up the path and make an SKPhysicsBody category to do it for us.
I won’t list the code here, you can download the project to have a look but here’s what it does. (I use some existing categories on UIBezierPath to help out here and got a convex hull implementation online too, they’re all included in the project.)
\n• Get the points from the path
\n • Order the points for the convex hull algorithm
\n • Get the convex hull
\n • While there are too many points in the hull, smooth it using increasing tolerance (removing points that make the smallest angles).
And that's all there is to it. The results are pretty nice for most shapes, if you wanted to get started on a physics drawing game you wouldn’t need much more than the SKPhysicsBody (ConvexHull) category.
Fun with UIBezierPath and CAShapeLayer
\nThis is a quick prototype for a fun drawing tool - as you drag your finger across the canvas the line grows branches which sprout leaves. The branches are randomly generated within certain parameters and animate on while you draw the main line.
\n![\"A](\"https://mbehan.com/assets/posts/vine-line.gif\")
Yes, the leaves are very realistic looking, thank you.
\nThe code is all on on GitHub, feel free to use and improve!
\nIt’s not about the line drawing
\nThe line drawing is very basic - simply adding points to a UIBezierPath. I keep an array of the curves and draw them all in drawRect:. I don’t care about smooth curves or different textures or performance but I’m sure this will work with more sophisticated drawing code too. Most of the drawing code I’ve shipped has been OpenGL based, so it was nice to see how good the results are when keeping things super simple with UIKit / CoreGraphics.
How it Works
\nLet’s start with the basic line and layer on the other bits. It starts with a pan gesture recogniser in our UIView subclass.
\nUIPanGestureRecognizer *pgr = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(handlePan:)];\n\n[self addGestureRecognizer:pgr];Now in the action selector we create new paths when a pan begins, and add to the current path when a pan changes.
\n-(void)handlePan:(UIPanGestureRecognizer *)gestureRecognizer\n{\n if(gestureRecognizer.state == UIGestureRecognizerStateBegan)\n {\n UIBezierPath *newVineLine = [[UIBezierPath alloc] init];\n [newVineLine moveToPoint:[gestureRecognizer locationInView:self]];\n [vineLines addObject:newVineLine];\n }\n else if(gestureRecognizer.state == UIGestureRecognizerStateChanged)\n {\n UIBezierPath *currentLine = [vineLines lastObject];\n [currentLine addLineToPoint:[gestureRecognizer locationInView:self]];\n }\n\n [self setNeedsDisplay];\n}You can see we’ve a mutable array called vineLines that we’re holding our paths in. This means to draw our paths we can simply iterate over that like so:
- (void)drawRect:(CGRect)rect\n{\n for(VineLine *vineLine in vineLines)\n {\n [vineLine stroke];\n }\n}That’s the basic line drawing done, now let’s add some branches. Again they’re UIBezierPaths. Every so often we want to generate a random path, the branch, and add it to the user drawn path, the vine. There are a couple of options for this, we could let the view / view controller keep track of the branches and when to draw them but let’s encapsulate all that in a VineLine, a subclass of UIBezierPath. (In the snippet above just swap out UIBezierPath with our new subclass.
@interface VineLine : UIBezierPath\n\n@property(nonatomic, retain, readonly)NSMutableArray *branchLines;\n\n@endRather than just subclassing NSObject and having a property for our path we’re subclassing UIBezierPath and overriding addLineToPoint:, adding functionality to the existing method to decide when to create our branch and add it to the branchLines array. Note that VineBranch is just another UIBezierPath subclass that can create random paths with leaves on the end. All we’re doing here is checking if the point we’re adding is far enough away from the last branch (or beginning of the line) to create a branch and if it is, creating a new random branch and storing it in an array of branches.
-(void)addLineToPoint:(CGPoint)point\n{\n [super addLineToPoint:point];\n \n float distanceFromPrevious;\n \n if([_branchLines count] == 0)\n {\n distanceFromPrevious = hypotf(point.x - firstPoint.x, point.y - firstPoint.y);\n }\n else\n {\n distanceFromPrevious = hypotf(point.x - lastBranchPosition.x, point.y - lastBranchPosition.y);\n }\n \n if(distanceFromPrevious > _minBranchSeperation)\n {\n VineBranch *newBranch = [[VineBranch alloc] initWithRandomPathFromPoint:point maxLength:_maxBranchLength leafSize:_leafSize];\n newBranch.lineWidth = self.lineWidth / 2.0;\n \n [_branchLines addObject:newBranch];\n lastBranchPosition = point;\n }\n}If we modify our drawRect: from before we can now draw the branches and leaves as well as the main line.
- (void)drawRect:(CGRect)rect\n{\n [vineColor setStroke];\n \n for(VineLine *vineLine in vineLines)\n {\n [vineLine stroke];\n\n for(UIBezierPath *branchLine in vineLine.branchLines)\n {\n [branchLine stroke];\n }\n }\n}And we’re done!
\nAnimating The Branches
\nThat's where CAShapeLayer comes in. CAShapeLayer has a number of animatable properties, and animating strokeEnd is great for drawing a path to the screen. So we can remove the code to iterate through the list of branches and stroke them instead, every time a branch is created we create a layer for it and animate the stroke.
-(void)vineLineDidCreateBranch:(VineBranch *)branchPath\n{\n CAShapeLayer *branchShape = [CAShapeLayer layer];\n branchShape.path = branchPath.CGPath;\n branchShape.fillColor = [UIColor clearColor].CGColor;\n branchShape.strokeColor = vineColor.CGColor;\n branchShape.lineWidth = branchPath.lineWidth;\n \n [self.layer addSublayer:branchShape];\n \n CABasicAnimation *branchGrowAnimation = [CABasicAnimation animationWithKeyPath:@\"strokeEnd\"];\n branchGrowAnimation.duration = 1.0;\n branchGrowAnimation.fromValue = [NSNumber numberWithFloat:0.0];\n branchGrowAnimation.toValue = [NSNumber numberWithFloat:1.0];\n [branchShape addAnimation:branchGrowAnimation forKey:@\"strokeEnd\"];\n}We can make our view the VineLine’s delegate and add a call to the delegate notifying it of a new branch in our addLineToPoint: method from above.
Random Paths
\nInitially I tried to be clever and see what way the line was curving and attach curves that seemed natural but that wasn’t looking too good. Eventually I just started throwing random numbers at it and things started looking better (this probably should have been obvious to me). So what we’re doing here is getting a random point close to the main line (as defined by _maxLength) and adding a curve to that point, control points are picked near that end point so we don’t end up with curves that are too crazy. Finally, we add the leaf, which for now is just a circle.
-(id)initWithRandomPathFromPoint:(CGPoint)startPoint maxLength:(float)maxLength leafSize:(float)leafSize\n{\n self = [super init];\n if(self)\n {\n [self moveToPoint:startPoint];\n \n CGPoint branchEnd = CGPointMake(startPoint.x + arc4random_uniform(maxLength * 2) - maxLength,startPoint.y + arc4random_uniform(maxLength * 2) - maxLength);\n CGPoint brachControl1 = CGPointMake(branchEnd.x + arc4random_uniform(maxLength) - maxLength / 2,branchEnd.y + arc4random_uniform(maxLength) - maxLength / 2);\n CGPoint branchControl2 = CGPointMake(branchEnd.x + arc4random_uniform(maxLength / 2) - maxLength / 4,branchEnd.y + arc4random_uniform(maxLength / 2) - maxLength / 4);\n \n [self addCurveToPoint:branchEnd controlPoint1:brachControl1 controlPoint2:branchControl2];\n \n UIBezierPath* leafPath = [UIBezierPath bezierPathWithOvalInRect: CGRectMake(branchEnd.x - leafSize/2.0, branchEnd.y - leafSize/2.0, leafSize, leafSize)];\n \n [self appendPath:leafPath];\n }\n return self;\n}