Storage Chapter Feedback. Keychain, iCloud, and SomethingInterface postfix naming convention for protocols
An update on the storage chapter feedback I've got + some miscellaneous things in The iOS Interview Guide 2nd edition.
Last week I posted a request for feedback on the storage chapter of my upcoming book update:
Thank you everyone who had read through the draft and submitted your feedback. I really appreciate it! I know not all of you have finished reviewing it yet, and that’s ok! I will incorporate your feedback as well later.
As a result of the feedback that I’ve received so far, here are some of the notable changes I’ll add and some commentary on some of the input I received:
Add a table comparing different storage options
In one of the first questions (the whole book is structured in a form of interview questions and answers) in this chapter I outline different storage options available to iOS developers. I’ll add a table briefly comparing them to each other, things like:
persistent: yes/no
secure: yes/no
cloud sync: yes/no
etc.
Hope it will make it a better summary at a glance.
Add clarification on what storage on mobile is vs what cache is
Seems like there is a lot of confusion around what storage is vs persistence vs caching. Unfortunately, partially, it’s due to the storage chapter being taken out of the context of an entire book. But also, partially, it’s on me to make it clearer what the storage layer of a mobile application covered in the chapter is.
To clarify briefly here - the storage layer of a mobile app is anything that stores data and state of an application besides the presentation layer or business logic layer. Let’s say you need to keep track of user selection between multiple screens, or persist some preferences between application launches, that all would constitute the storage layer.
Cache on the other hand is a little more ad hoc - it’s temporarily stored data in the presentation or business or networking layer that helps you save on compute or request time. It can be implemented by utilizing the storage but doesn’t have to. A simple in-memory array or dictionary of a cached result of a network response in an Interactor or a ViewModel wouldn’t be a part of storage layer, it would just be an ad hoc cache. But, an in-memory array or a dictionary or a database that is used by a purposeful “Storage” object to persist data between parts of the app or between launches would belong in the storage layer.
It’s a bit semantic but for the purposes of The iOS Interview Guide I define those layers and distinguish them as such. More details on it will be in the “Big Picture”/”Architecture” chapters of the book.
Keychain Data Sharing
Some of my reviewers asked to cover keychain data sharing across multiple apps (with similar bundle id).
IMO this is a niche question that is not asked often on mobile interviews. Let me know if this is something you have to implement often:
iCloud Sync
Several reviewers asked about iCloud sync relating to storage. It is more of a networking layer concern, and I most likely will add a question about it in the networking chapter. But, from my experience, the majority of iOS applications out there do not use iCloud and instead have their own API backends. It’s more of a niche thing not commonly asked on iOS interviews.
Nevertheless, let me know in a poll below if you encountered iCloud much in your iOS projects:
I am not apologizing for my Interface postfix in protocol declarations. Sorry not sorry.
It’s about all protocols in my code samples looking like SomethingInterface with the Interface postfix.
At some point I need to write up a proper post about it explaining my reasoning but I’ll try to do my best with a short summary here.
It has kind of become a "signature style” of mine over the years. Jumping between various languages like Objective-C, Swift, Kotlin, TypeScript, etc. with each having their own style, conventions, preferences and all that, I noticed a common theme - no one uses interfaces (protocols)!
Of course, not "no one”, but you know what I mean, it feels like it when you open your average codebase (mobile, web, or any other) there is just an allergic reaction to abstracting things out via interfaces.
So, years ago, working with a legacy codebase that doesn’t have interfaces (protocols), I started to introduce them with the base name of `Something` being the interface (protocol) and the implementation of that interface being `SomethingImp`.
It was fine at first but quickly things got muddied because the old classes that didn’t have any interfaces (protocols) were named `Something` just like the new interfaces were named `Something`. And as the code refactoring progressed, it was hard to tell at a glance which one of the classes was migrated to using interfaces and which one wasn’t.
So, I made a decision to explicitly, on purpose, perhaps obnoxiously, name every interface `SomethingInterface` to speed up refactoring and code review by helping to identify what was migrated to use interfaces and what was not.
Since then, the convention stuck with me.
You might ask - “but Alex, why do you not call it SomethingProtocol? It’s called protocols in Swift, not interfaces!”. My answer to you would be - I’ve been jumping between different languages like Swift, Kotlin, TypeScript, and Ruby too much over my career to care! It’s all an interface at the end of the day, in every language it serves the same purpose and behaves the same way (mostly). I do not care for Swift trying to be “special” and “unique”. (I also understand it’s Objective-C legacy that Swift inherited, but I also do not care for the same reason.)
Hope it makes sense.
Other Minor Fixes
There were other minor fixes and adjustments reported that I will work on. Thanks everyone for finding them!
Conclusion
I appreciate everyone’s feedback, thank you for helping me make the book better! I’ll keep you all posted on the next chapter drafts as I have them available.