Categories
Development Life Technology

WWDC 2021 – Day 5

Writing this a bit late, but Day 5 was the best day so far for me. Why? Because I applied for a SwiftUI lab session and was lucky enough to get one! But before we get to that…

I’m a person that struggles a lot with anxiety. Mostly around social situations, my anxiety has been a darkness in my life for as long as I can remember. I have learned to live with it, even when that “living with it” is to shut myself away from the world as much as possible. If you’re wondering if the recent pandemic was a “good thing” for me, then to some extent it was amazing. Let me clarify that though; it made me realise just how bad my anxiety was when the vast majority of it was suddenly removed. When I thought lockdown was going to be eased I realised how scared I was of seemingly everything and I realised it was again time to seek help. I won’t go into the details of that, but if I say CBT then you’ll get the idea.

Fast-forward to now, to WWDC week, to me being able to do some things that a year ago I wouldn’t have realistically considered. Attending group chats and SwiftUI Lounge sessions. All virtual, yes, but still very much a victory for me. And this all culminated in me not only applying for a lab slot – applying in itself was a big thing – but actually being one of the lucky people to get one.

On Friday night at 21:30 UK time I logged on to the WebEx call and was joined by two fantastic Apple engineers who worked on the SwiftUI team. As part of the application I had submitted my questions, and Matt summarised the first one to ensure he understood what I wanted to know and the conversation began – it was awesome! They listened to me and answered everything with real clarity, expertise, and patience. They reassured me that the road I was going down was the correct one, offered suggestions for when that road may not be suitable, and offered up a couple of diversions for me to checkout ways to improve my code and use of SwiftUI. It was brilliant and I was absolutely buzzing afterwards.

Now, this may not sound like such a big deal, but to me it was. The questions I asked were things that I have been too anxious and scared to ask of the community, because I am inherently fearful of looking stupid. That can lead to a decline in my mental health and me stopping doing the things I love. Anyone who has suffered with depression and anxiety will know what I am talking about. The irony here is that instead of asking random people on the Internet for help, I ended up asked literally the most knowledgeable SwiftUI people on the planet – if anyone could make me feel stupid… Of course, they didn’t do that. They communicated with me so clearly and kindly that I was left feeling more motivated than I have for a long time.

This, then, was my highlight of WWDC. I have loved WWDC this week. Being part of it all feels right to me. My mental health has prevented me from accomplishing so much, and yet I am still here battling away and more determined than ever to release my app and once again be an iOS app developer.

Thank you to everyone at Apple for all the work in bringing us WWDC and bringing us all the new toys. Maybe one day soon I will add my own new toy to the App Store – I certainly now feel like it’s possible.

Categories
Development Technology

WWDC 2021 – Day 4

Categories
Development Technology

WWDC 2021 – Day 3

Today has been all about SwiftUI as I watched the excellent Demystifying SwiftUI session, and then hung out in the SwiftUI lounge as Apple engineers answered questions about what was in the session.

And right now I am back in the SwiftUI lounge where a couple of engineers are answering questions about building SwiftUI itself. It’s great to get answers from the people that built it, it really helps put the achievement into perspective.

That’s it for today as working during the day then spending hours catching up with WWDC in the evening is taking its toll! I need to set Focus mode to Sleep soon. Hopefully tomorrow I will get to try out the new Xcode beta and some of the new SwiftUI features!

Categories
Development Technology

WWDC 2021 – Day 2

We got the first recap video today and Serenity Caldwell knocked it out of the (Apple) park. Watching the brief-yet-info-dense recap got me excited all over again about what’s in store for this week and beyond.

Already the Apple dev community is cranking out content. My personal favourite so far is tuning into Paul Hudson’s fantastic live streams on YouTube. He’s already demoed a load of new SwiftUI code, and he’s currently live streaming all about new stuff in Swift 5.5. If you want to know about Swift’s new concurrency model then this is the place to go. You can watch the videos back after they live stream, so no rush.

I’m also partial to a bit of content from John Sundell & Friends on the WWDC by Sundell web site. John is a fantastic communicator about all things to do with Apple development, and he’s joined by Gui Rambo and perhaps others throughout the week.

I watched the Apple session “What’s new in SwiftUI” today and there is a lot of new functionality that is very impressive. Swipe actions for Lists look awesome and will be such a time-saver both in code terms and UI terms. There were a number of other great things that will help simplify development with SwiftUI – buttons, refreshable API, searchable API and so on – and I can’t wait to get started with the new Xcode beta.

Perhaps the biggest takeaway so far is the number of times that async await appears in sample code. Makes me think all code looks like this now:

@State private await var async myVar: String = await "My Value"

It’s great that concurrency is being so heavily involved in the code demos. It’s an area of programming that I’ve not dabbled in before, so I am excited to try it out.

That’s it for day 2 – the week is going by so fast!

Categories
Development Technology

WWDC 2021 – Day 1

And just like that the Keynote and Platforms State of the Union are over for another year. Although last year had the big Apple Silicon announcement, I felt they spent too long on it, so this year’s focus on the software and APIs was more interesting for me.

I particularly liked the Maps enhancements around directions (both on foot and in a car). The new Weather app, which I believe has been developed in SwiftUI, looks lovely and offers some new data points from what I could tell. Definitely looking forward to trying out.

On the Home front I love everything around home automation and HomeKit. Even if I’m not personally interested in a specific feature or device, I am always interested in seeing the use cases. I find the idea of “keys in iOS wallet” to be pretty compelling and will definitely look into how that could work for me. Even if it’s just a lock on the shed while I decide whether I trust the tech or not! And I’m also thinking about HomePod Mini in the lounge, both as audio output for the TV and also so I can “Hey, Dingus!” to get it to control the TV to some extent.

I think the most interesting developer things for me where coding SwiftUI apps on iPad in the new Playgrounds app and Xcode Cloud. Finally we get to see the fruits of the BuddyBuild acquisition and I think it sounds fantastic. Anything that can help make the process of development easier for me is welcome and I think this will do just that.

Lastly, the concurrency story for Swift and the introduction of the AAA (async, await, actors) was another interesting area. Concurrency in programming is new for me and I haven’t quite got my head round it yet, but I am looking forward to trying out the new features of Swift to see if they can help me with ExerPlan.

Overall, a good start to WWDC 2021 with plenty to pique my interest and no doubt plenty of detail still to come out over the next few days and weeks. My new SSD arrives tomorrow so I will finally have enough space to install new stuff without the fear that my Mac Mini will run out of space. Can’t wait!

Categories
Development Featured

WWDC 2021 – Pre-Conference Thoughts

WWDC 2021 is due to start tomorrow and once again it’s online only. It seems strange now that last year we were wondering whether an in-person event would be doable, and of course with hindsight the right decision was made. But not just because of the global pandemic – Apple touts inclusiveness as one of its core beliefs and the online nature of WWDC meant that it was the best “attended” WWDC in history (citation needed obvs).

This year I am once again very excited about WWDC week, last year’s event was brilliant and I was able to participate like never before. I’ve already taken part in the WWDC Trivia Party, and it was good fun again despite the technical gremlins that made it a text-only event for me this year! I’ve also signed up to a few other things during the week, which given the time difference I may not always be able to attend, but hopefully I can make some of them. There is a real buzz around the iOS dev community at this time of year and I love being part of it. One of my aims for the next 12 months is that by WWDC 2022 I can play a bigger part in it, whatever that turns out to be.

Next week I am mostly looking forward to the Keynote and Platforms State of the Union, desperate as I am for any news of SwiftUI updates and a possible sighting of SwiftData (if it even exists, which it surely must?). That takes care of Monday evening for me, and then it will be on to consuming everything I can about whatever is announced. Be that the Apple developer videos that were so brilliant last year, to all the various blogs and podcasts and videos that the wider community produces. With so much planned by so many, it’s going to be a busy week. I’m on UK time so I get to work all day and then around 18:00 the new videos will drop from the Apple developers and that’s another night gone!

My most important goal for this year is to finally release my app, ExerPlan, onto the App Store – it’s an app based around creating your own exercise plans. I have struggled for 2 years to get the app released, and it was only with 2019’s introduction of SwiftUI that I finally thought I would ever release it – yet two years later I still haven’t done it. I care less now about the completeness of the initial launch version as I do about the goal of launching – I need to prove that I can do it and move on from there.

To sum up; I am hoping that WWDC 2021 gives me the excitement and impetus to get back on track with ExerPlan and ultimately to help me towards my over-arching goal of transitioning to being a full-time app developer. And, er, SwiftData – I really want them to announce SwiftData please and thank you!

Categories
Development Featured Technology

WWDC 2021 Wish List

WWDC 2021 kicks off next week and there are a few things I am hoping to hear about. Here’s my wish list for WWDC 2020 for comparison.

  • SwiftData! The mythical beast of persistence, the talk of which persists. I am hoping for something that merges the functionality of the magnificent GRBD SQLite library with native Swift. Give me all out SQL control along with ORM-like technology for those times when something more Swifty is preferred. This post by Drew McCormack has some great ideas and more realistic expectations about how SwiftData will be to CoreData as SwiftUI is to UIKit. Whatever happens, I hope we get a top quality, SQL-based, Swifty new data framework that can handle syncing across all a user’s devices.
  • eyeOS! Come on, it’s the greatest name ever in Apple OS history and it’s not even been announced yet. This is something I hope to hear more about. Apple has been showing AR stuff for a few years now, but all the demos leave me underwhelmed. Someone holding an iPad while building virtual Lego is not where it’s at for me. I want to see some stuff that points to Apple’s wearables future, along with some of the indie AR demos that have been so captivating.
  • Continuous Integration! Will this be the year that the BuddyBuild acquisition starts to make sense to the developers? I’d really like to see Apple introduce a streamlined CI solution that enabled us to easily write-test-commit-deploy – the deploy should be straight to the App Store and take care of…well…everything from screenshots to certificates.
  • Home Automation! Recent oopsies with job adverts aside, I would love to see Apple take HomeKit and hardware on a level. I think some sort of HomePad is on its way, but perhaps a better move would be for Apple to open up HomeKit so that more devices start to support it. When looking for HomeKit plugs, for example, I can always find about 18 million Alexa/Google ones and 2 for HomeKit. I want to see fantastic developers like Aaron Pearce let loose on HomeKit to build us whole home automation apps that can run on either Apple or third-party HomeKit hardware.
  • SwiftUI! No question, SwiftUI is the best software release Apple has made since I started developing for their platforms. It is SwiftUI’s second birthday next week and I want to see it really living up to its potential. Let’s have an end to the annoying bugs and let’s get something that handles the basics of iOS apps superbly and simply. Sort out the issues with navigation, try not to introduce too many new Property Wrappers, and build on that with new controls that enable swift prototyping and development like only SwiftUI can. And integration with SwiftData would be amazing obvs. To clarify: I 100% love SwiftUI – thank you to everyone that has worked on it and made it what it is.

I am excited for the upcoming WWDC and have already registered for a couple of events over the next week or so. And maybe this year my post-WWDC buzz will last long enough to power me through to releasing my app – we can but dream!

Categories
Development Technology

Decoupling Code

I’ve written before about my use of SQLite and the GRDB framework in my new app ExerPlan. After spending more time coding and getting to grips with the approach I detailed here, I’ve made the decision to alter the approach again.

While GRDB is an excellent framework, it’s not part of the Swift standard library and as such there may come a time when it’s no longer supported or actively developed. I decided I didn’t want my code so tied to the framework that replacing it could be an issue. The solution? To make a small alteration that would decouple me from GRDB, while still letting me use the power of GRDB as I was before.

I split my data code across two objects; one is a Struct that is basically a 1-to-1 mapping of a database table. However, it has no knowledge of how it will be persisted as I’ve removed all references to GRDB. The second type is a class that does reference GRDB, and is where all the persistence methods have been moved to.

The persistence class contains one “save” method per table, and takes a value of the Struct as a parameter.

struct Plan
{
   var planID: Int64?
   var planName: String

   func save()
   {
      Persist.save(self)
   }

}

class Persist
{
   func save(plan: Plan)
   {
       // Create a GRDB version of the Plan object
       // Then we can use GRDB to persist
   }

   func save(activity: Activity)
   {

   }
}

Having split the code like this, my persistence layer is now decoupled from the objects it is persisting. If I decide to stop using GRDB, I only need to re-write the save methods in the Persist class and the rest of the code will carry on working in the same way.

I have also created a Fetch class, which works in a similar way to Persist, but is for returning data that my app requires. Again, this means I only need replace code in Fetch if I were to use a new data access framework in place of GRDB.

It’s been a long journey getting to this point with Swift, GRBD, and iOS coding in general. I’m happy with where I’m at now and I’ll be moving on to the next stage, learning how to do UI programming with Swift and iOS.

Categories
Development Technology

Swifty SQL With GRDB

In my previous post I explained why I chose to use SQLite and GRDB for my app ExerPlan, and in this post I’m going to share implementation details with some Swift code.

I wanted to use Structs to map to database tables. This way I could do things like:

var activity = Activity(activityID: nil, activityType: 1, activityDate: Date() )

activity.save()

I also wanted to be able to have my structs encapsulate functionality to provide data validation. Although I will use some protection at the database level to enforce certain things (primary keys, constraints, triggers) I also like to take action at the UI level before it even hits the database.

To facilitate this I chose to create two structs per database table; one struct would be a “pure” GRDB-focussed struct that would give me the persistence code for free, and the second struct would be more like the public-facing API that I would use throughout my code for actually interacting with the data in the database. The first struct would become a property of the second.

struct ActivityDB: Codable, MutablePersistableRecord, TableRecord
{

   // Let GRDB know the name of the database table, otherwise it will assume it is the same as the struct’s name
   static let databaseTableName = “Activity”

   // This is the primary key, but it’s optional
   // because until a row is Inserted there is no value
   var activityID: Int64?

   var activityType: Int64
   var activityDate: Date

   mutating func save()
   {
      // Save record here
      // GRDB handles Insert/Update for new/modified row
      // and returns the auto-generated ID if there is one
   }

   // This is where the auto-generated ID can be used
   mutating func didInsert(with rowID: Int64, for column: String?)
   {
      activityTypeID = rowID
   }
}

My second struct would have ActivityDB as a property, but allow for data validation that I didn’t want to have on the GRDB-focussed struct.

struct Activity
{
   var dataStore: ActivityDB

   var activityID: Int64?
   {
       get
       {
           return dataStore.activityID
       }
   }

   var activityType: Int64
   {
      get
      {
         return dataStore.activityType
      }

      set(newValue)
      {
         // Perform some validation logic here
         dataStore.activityType = newValue
      }
   }

   var activityDate: Date
   {
      get
      {
         return dataStore.activityDate
      }

      set(newValue)
      {
         // Perform some validation logic here
         dataStore.activityDate = newValue
      }
   }

   mutating func save()
   {
      dataStore.save()
   }
}

There are a few kinks to work out with this approach, notably I’m not sure if I need the two structs and could just use one. At this stage it’s working as I want so I’ll continue with it until/unless I hit any major issues.

The next step was to create some code that would allow the easy retrieving of rows. GRDB provides a number of methods to do this, but I wrap those up inside a big Data Access Layer or DAL class. The class consists of a number of static methods that return arrays of structs, or whatever else is needed from the database. The following code shows the basic structure of how I return an array of one type.

class DAL
{
   private static func returnArray<T>(fromRows rows: [Row], ofType: DatabaseTypeEnum) -> Array<T>
   {
      var list = [T]()

      for row in rows
      {
         switch ofType
         {
         case .ActivityTableView:
            list.append(ActivityTableView(dbRow: row) as! T)

         case .PlanTableView:
            list.append(PlanTableView(dbRow: row) as! T)

         }
      }

      return list

   }

   private static func doFetchAll(withSQL sql: String, returnType: DatabaseTypeEnum) -> Array<T>
   {
      let rows = try! dbQueue.read
      { db in
         try Row.fetchAll(dB , sql)
      }

      returnArray(fromRows: rows, ofType: returnType)
   }

   static func fetchAllActivities() -> [ActivityTableView]
   {
      let sql = “””
Select src.ActivityID, src.ActivityType, src.ActivityDate
From Activity src
Order By
   src.ActivityDate desc
“””

   return doFetchAll(withSQL: sql, returningType: .ActivityTableView)

   }

}

The DAL can easily be extended with new methods for retrieving data, and also for the retrieval of single values/rows rather than an array. It’s still a work in progress design and as I get further into the UI development and have to start using these methods I may end up making new design decisions.

Writing this article has been a useful exercise as it has forced me to consider my choices again, and even led to some refactoring as I wrote it. The next step is to progress with the UI prototype which will give all this code a really good workout.

Categories
Development Technology

Swift SQLite With GRDB

Any app like ExerPlan needs a good data model and data store, and given my SQL skills and the fact that SQLite is part of iOS there was only ever one choice for me.

I work with Microsoft SQL Server in my day job and I am very comfortable with writing SQL code to handle inserts, updates, and deletes. I come into contact with lots of different systems at work, and as such I witness many crimes against data. These range from column names making as much sense as Brexit, to seemingly well-designed schemas that lack the database constraints to enforce that design. I wanted to ensure that I created a database that didn’t suffer from these problems.

Swift and SQLite don’t necessarily play well together because it’s not as though SQLite is part of the Swift standard library. But Swift is open source and so maybe there’d be an open source solution for me?

Enter GRDB a “SQLite databases toolkit with a focus on application development”.

I’ve looked at a few such toolkits for SQLite and Swift, but GRDB is by far my favourite. The main reason is that SQL code is front and centre in GRDB if you want it to be, and with my background I very much do. GRDB has some really nice abstractions away from SQL if you want to use them, but as the docs say “your SQL skills are welcome”.

I’ll address how I’m using GRDB more fully in a later post, but for now it’s enough to say that GRDB and Swift play very nicely together. I’ve now got a solid base to work with, and GRDB feels as much like Swift as the standard library.

Select “Happy” As MyFeelingAboutGRDBAndSwift