DEV Community: ✨ thetealpickle 📱

Getting Schwifty with macros [TALK VIDEO]

✨ thetealpickle 📱 — Wed, 17 Apr 2024 13:01:17 +0000

Live coded a swift macro during the 2023 Geekle iOS Global developer conference. This is the presentation recording.

In this talk, thetealpickle introduces macros and then live codes some macros 🤤 . A Rick and Morty themed multidimensionally used app, Poopybutthole. From exploring and implementing various macros use cases to writing tests for our macros. We will also create custom diagnostics and fix-its to help the future maintainers of Poopybutthole. ✨ It’s time to get schwifty with macros, join the fun 🚀

Grab the full talk on thetealpickle app
Available on the App Store
📱➡️ https://apps.apple.com/us/app/thetealpickle/id1577045108

Getting Schwifty with macros [TALK] - YouTube

Live coded a swift macro during the 2023 Geekle iOS Global developer conference. This is the presentation recording.In this talk, thetealpickle introduces ma...

youtube.com

!! NEW PRODUCT!! 🎉🤗 THETEALPICKLE APP

✨ thetealpickle 📱 — Thu, 02 Apr 2020 16:40:56 +0000

THETEALPICKLE is on the App Store!! Currently available for iOS

v1.0.1

with @thetealpickle content you can [resources like code snippets, view videos, read articles, listen to podcast episodes]

with @thetealpickle projects you can [view projects, get insight, access project links]

ANDDDDDD stay up to date with the latest in @thetealpickle universe. 😬

⠀

🔨 Continuing to build out the experience, adding NEW features, and fixing bugs. Download and follow the journey!!!⁠⠀
Every aspect of this app experience created by @thetealpickle 🥴⁠⠀

[VIDEO]Refactoring Endpoints with Relationships in a Swift API 🌚♥️🌝(Swift 5.1/Vapor 3)

✨ thetealpickle 📱 — Mon, 03 Feb 2020 15:18:03 +0000

PART 2. In this video, I walk through refactoring endpoints to access and create model relationships within a Swift-based API. The Swift API created in this video leverages the Vapor 3 framework. Models naturally interact with other models and in Vapor these model interactions are made possible by creating relationships. There are two types of relationships, one-to-many and many-to-many.

This video is PART 2 of the model relationship videos. Part 1 shows how to create relationships within the models and database.

Code for this video can be found on @thetealpickle’s GitHub at the cheese-api-swift repository 👉🏾 https://github.com/thetealpickle/cheese-api-swift

Want to follow along? Get the starter code at the cheese-api-swift repository on the vapor-relationships-start branch 👉🏾 https://github.com/thetealpickle/cheese-api-swift/tree/vapor-relationships-start

Follow me on social media @thetealpickle to stay connected with the Pickle universe 🌎

https://instagram.com/thetealpickle
https://twitter.com/thetealpickle
https://github.com/thetealpickle

Brought to you by JESSICA JEAN JOSEPH © THETEALPICKLE

[VIDEO] Creating Model Relationships in a Swift API 🌚♥️🌝(Swift 5.1/Vapor 3)

✨ thetealpickle 📱 — Sat, 01 Feb 2020 12:58:13 +0000

In this video, @thetealpickle walks through creating relationships between models within a Swift-based API. The Swift API created in this video leverages the Vapor 3 framework. Models naturally interact with other models and in Vapor these model interactions are made possible by creating relationships. There are two types of relationships, one-to-many and many-to-many.

Code for this video can be found on @thetealpickle’s GitHub at 👉🏾 cheese-api-swift repository

Want to follow along? Get the starter code at the cheese-api-swift repository on the 👉🏾 vapor-relationships-start branch

One 👆🏾 to Many ✋🏾✋🏾✋🏾✋🏾✋🏾

A one-to-many relationship is referred to as a Parent/Child relationship. There is one parent model object which can map to many child objects. For example, a pet owner can have multiple pets, while each individual pet has one owner. In this scenario, the Owner model is the Parent model and the Pet model is the Child model.

Many ✋🏾✋🏾✋🏾✋🏾✋🏾 to Many ✋🏾✋🏾✋🏾✋🏾✋🏾

A many-to-many relationship is referred to as a Sibling relationship. Each sibling model object can map to many objects of the other sibling model, and vice versa. Continuing with the pet example, a pet can play with multiple toys and multiple toys can be played with by multiple pets. In this scenario, the Pet model and Toy model have a sibling relationship. Each model can map to multiple objects of the other model.

Relationships in Vapor

Vapor makes setting up relationships between models relatively straight forward. With Parent/Child relationships, the models are extended to have a computed property which returns the parent/children. With Sibling relationships, the models are linked using a Pivot model which stores the mapping between the sibling object ID’s. The pivot acts as the middle-women between the two models, the Sibling models are then extended to have a computed property based off of the pivot which manages and returns the siblings.

Working with Parent/Child relationships differ from Sibling relationships, as a safe guard must be added in the form of a foreign key constraint. Adding a foreign key constraint prevents the following (1) a child from being added to a nonexistent parent object, (2) the parent model table from being deleted prior to deleting the child model table, (3) the parent model object is not deleted until all children objects are deleted.

@thetealpickle on the internet. Namaste.

Brought to you by JESSICA JEAN JOSEPH © THETEALPICKLE

[VIDEO] Writing CRUD operations for a Swift API 🍭🍦 (Swift 5.1/Vapor 3)

✨ thetealpickle 📱 — Fri, 10 Jan 2020 15:14:10 +0000

HELLO INTERNET.👋🏾
In this video I go into creating CRUD endpoints for a Swift API !! 🖥

CRUD stands for Creating Retrieving Updating Deleting
Let's get CRUDy 😁

CRUD operations are ways to interact with a database and in this video I show you how to create CRUD endpoints within a Swift API.

This API is created using the Vapor framework and leverages the Fluent library for abstracting out our database interactions.

You can download the repository I am working on for this video on my GitHub at my cheese-api-swift repository💪🏾
Check out the other videos in the series! 📺

Stay connected with me on the internet @thetealpickle, leave a response or send me a tweet on twitter. Dont forget to share the ❤️

Namaste. Jessica 🥔

[VIDEO] Getting your Swift API interacting with a MySQL database 💾 (Swift 5.1/Vapor 3)

✨ thetealpickle 📱 — Fri, 03 Jan 2020 06:45:02 +0000

HELLO INTERNET. Continuing our Swift backend takeover 😬 by configuring our API with a popular, powerful database MySQL 🖥

⚡️ Getting our database configured, let's get it! 💪🏾
Check out the other videos in the series! 📺

Stay connected with me on the internet @thetealpickle, leave a response or send me a tweet on twitter. Dont forget to share the ❤️

Namaste. Jessica 🥔

[VIDEO] Creating APIs using Swift?? 🥴 Hi Vapor (Swift 5.1/Vapor 3)

✨ thetealpickle 📱 — Wed, 01 Jan 2020 13:17:23 +0000

NEW VIDEO!!!

Calling all fellow iOS devs to start drinking backend with Swift. Our time is NOW 😈

Stay connected with me on the internet @thetealpickle
Namaste. Jessica.

SwiftUI @Environment and BindableObject

✨ thetealpickle 📱 — Thu, 10 Oct 2019 10:40:17 +0000

The drop of SwiftUI this summer 2019 shook the iOS/Swift dev game. The way views are created and how data flows through apps have become declarative. BindableObject, Environment, State, Binding are new tools to cut through the waves and make it to the other side.

Property Wrapper & Protocols

New in Swift 5.1, property wrappers. Property wrappers wrap property access with additional behavior. @Environment is a property wrapper.

Protocols define a set of requirements which are then implemented by the adopting class, structure, or enumeration. BindableObject is a protocol.

Environment

The Environment property wrapper is part of the new Combine framework and is designed as a general purpose container for all types of data. The Environment data is used for indirect data passing and pushes dependencies down the hierarchy. Environment data has read-only access.

Writing data into the environment is done by using the .environmentObject modifier on the object you would like to go into the environment.

Environment vs Binding

Binding is another data flow tool for SwiftUI views, more information can be found here.

Environment and Binding are two different tools with the same core functionality, passing dependencies through the view hierarchy. If your entire app is a read-only app, the app could be built using entirely one OR the other. The question, how would you like to access your data?

Environment can be leveraged as a work around from passing a model at every view transition point. Environment is like bag full of candy being passed around the group. Whereas with Binding, everyone holds and passes around each individual candy.

Another note, Binding provides read/write access. Environment is read-only. For data which child views need to be able to update, the Binding wrapper should be used instead.

BindableObject

The BindableObject protocol is part of the new Combine framework and is designed to provide an external reference to your custom model and have SwiftUI track attribute changes over time using publishers.

Combine uses a Publisher, Operator, Subscriber model flow. By conforming your custom model to the BindableObject protocol, the model becomes setup to trigger view changes to all subscribers in the view hierarchy.

BindableObject is a way to bring SwiftUI’s declarative data handling to custom models. BindableObject brings us into the beginning dive into the new Combine framework. A new age.

@thetealpickle on the internet. Namaste.

This article was brought to you by JESSICA JEAN JOSEPH © THETEALPICKLE

SwiftUI @State and @Binding

✨ thetealpickle 📱 — Thu, 03 Oct 2019 10:46:19 +0000

Property Wrappers

New in Swift 5.1, property wrappers. Property wrappers wrap property access with additional behavior. State and Binding are property wrappers.

Source of Truth

Source of truth is the biggest change with SwiftUI. Pre-SwiftUI, view controllers were in charge of their own data and if developers wanted a “syncing” effect, they would need to create it themselves. begins reminiscing pre-swiftui data syncing bugs bugs bugs.

Apple said fuck that, use @State

State

With SwiftUI, the emphasis is on your app having one source of truth, which is defined using @State. State lives in this magically bubble outside of your view. Views are volatile. State is persistent storage created by SwiftUI on your view’s behalf.

@State var isPickle: Bool = true

The @State property wrapper tells system, the property is a value that changes over time and the views depends on the value. Any runtime changes to a State wrapped property are recognized and triggers a re-rendering of only the portions of the views which utilize the property’s value #efficient. Since changes flow down to all of the view's children, State wrapped properties should be owned by one view which is the top-most view of the application.

Speaking of children, how the heck does State get passed through to other views if State should be defined in only one view??? Binding 😉

Binding

The @Binding property wrapper tells the system the property has read/write access to the value without ownership. Binding properties have their values passed in from a parent view as a binding, for this reason, providing a default value is not needed.

Creating a binding occurs by passing in a State property with the $ prefix and provides the child view with a reference to the State property.

@State var isPickle: Bool = true

var body : some View {
   ChildView(showPickleEmoji: $isPickle )
}

In the ChildView

@Binding showPickleEmoji: Bool

Binding wrapped properties are provided a reference to the app’s State so any changes to values on Binding wrapped properties trigger changes across the application to whatever view portions are dependent on that State’s value.

Ownership

The biggest difference between State and Binding is ownership. Views with property's marked with State have ownership. The system created storage on that specific views behalf. With property's marked with Binding, the view has read and write access, but not ownership.

Like living with someone and having a pet. The pet is in both individuals lives. Both individuals take care of the pet, give the pet affection, take the pet out. They both have access. BUT, on the day one decides to move, the pet ultimately stays with the owner.

@thetealpickle on the internet. Namaste.

This article was brought to you by JESSICA JEAN JOSEPH © THETEALPICKLE

Choosing a Database Manager. SQL or Nah?

✨ thetealpickle 📱 — Fri, 27 Sep 2019 15:04:21 +0000

Going down the SQL road as a noob, what seemed like a walk in the park quickly turns into a multi headed dragon readying itself to breathe fire down your throat. Here’s your shield bitch.

Database vs Database Manager.

A database is a collection of data. Databases handle data in ways which allow systematic support for data manipulation and storage. Database managers handle databases. Within a project there are multiple considerations for managers: are multiple databases being accessed, does data representation need manipulation before add, what are the restriction levels of database access. Database managers are clutch.

Relational DBMS.

Lol. DBMS.
DBMS stands for Database Management System 🙃

Relational DBMSs define their structure as table relationships. An example: A box of tech shared within a family. The list of tech item data the family owns goes in its own table, the list of family member data go in another table. A relation can be formed between a family member and the tech they are currently in possession of. This structure makes adding a family member and adding tech a relatively easy addition. Insert a row of data, avoiding any database restructuring with previously existing data.

A note to keep in mind, Relational DBMSs work based off of schemas. The schema, predefines the table structure. When you want to add a new column to a table, a new schema must be defined and the preexisting data must be migrated to the new structure. For large databases with constantly changing structures, this can result in frequent downtime.

Relational databases work most effectively by knowing, in advanced, the structure of the table as well as the data points that will be used. Unstructured, unknown-in-advanced data struggles with this type of manager.

Relational Databases include SQLite, MySQL and PostgreSQL.

SQLite.

SQLite, is, light 😬.
As the name suggests, SQLite is a lightweight database for simple local data storage. Part of SQLite’s lightweight nature comes from its server less architecture. SQLite does not need to be installed before using. This zero configuration setup equals no configuration files.

SQLite is a self contained database with minimal support from external libraries or the operating system it’s running on. Embedded devices (phones, handhelds), internet of things, devices which often operate without human support, have environments which are suitable for SQLite.

MySQL.

MySQL was designed for speed and reliability, an ideal database for many use cases. MySQL’s speed and reliability comes at the cost of not being fully SQL compliant, depending on the use case there are some functional limitations. Many large applications such as Facebook have components powered by MySQL databases.

A few things to consider about MySQL, its license and propriety features, slowed development and SQL compliant and function limitation.

PostgreSQL.

PostgreSQL is “the most advanced open-source relational” DBMS, as per PostgreSQL 🙃. PostgreSQL is designed to be highly extensible and standard compliant.

PostgreSQL is relational, with a splash of object databases. Object DBMSs are structured to hold data as objects as opposed to loose pieces of language-independent data.

PostgreSQL is SQL compliant and has an effective way of handling concurrency (multi tasking) without read locks. A main fact to consider with PostgreSQL, memory performance, which quickly builds with each new connection. As read-heavy operations go, PostgreSQL’s structure is less performant than MySQL.

SQL. OR NAH? NoSQL.

If SQL is the fart from last month that permanently stained the couch, NoSQL is the morning fart that’s directly tied to last night’s bucket of sharp cheddar cheese which was washed down by a gallon of whole cow milk 🤮 But you appreciate the stench because of the added variety to the space.

NoSQL.

Not only SQL.

Relational DBMSs are effective when the structure is either known in advanced due to their predefined schemas. Need to make a structure change? Create a new schema and migrate old data to the new. Highly ineffective with large databases that have dynamic structures.

NoSQL on the scene: “I got the sauce”

NoSQL shines with agile. NoSQL databases have more options in handling complex data structures (document based, graph based, key-value pair, etc). NoSQL is an “unstructured” database. NoSQL databases are designed to handle unstructured data models in a scalable way.

SQL or Nah?
@thetealpickle on the internet. Namaste.

Swift on the Server. WTF.

✨ thetealpickle 📱 — Thu, 26 Sep 2019 20:52:57 +0000

Swift is an insidious fart that is slowly taking over the world and resistance is futile.

What is a server?

Server or Backend, two names for the same entity. Servers handle the interaction between an application and a database. The database stores the data. App platforms are designed to be able to communicate directly with databases. In many cases, i.e. an informational/read-only application, speaking directly to the database suffices. For other apps, a backend comes in clutch.

Having a backend insures your data goes through the same flow for all of your platforms (iOS, Android, Web, etc). Shifting the data processing to the backend allows the front end applications to be more lightweight and nimble. A backend can also centralize analytics across platforms, making data syncing more attainable while reducing duplicating/duplicate checking.

Cool, so we know what a server is and why it's pretty useful in most cases to create one. The sauce.

Swift on the backend.

As server languages stand the most popular options are Javascript and Python. For many web developers who are already using Javascript on the front-end leveraging their Javascript knowledge on the backend with node.js saves time. For cleaner coding practices and front-end platform uses beyond web, Python and its frameworks - typically Flask or Django, make it a more suitable option.

Server side Swift bring compiled language performance to a space which typically works with runtime languages. If close to native speed is needed, server side swift should be a consideration.

Swift as a language is elegant and nicely balances type safety and high level programming capabilities with approachability. If Swift is already being used on front-end applications, that Swift knowledge can be leveraged and applied to the backend side as well.

There are three main Server side Swift frameworks, Vapor, Kitura, and Perfect.

Swift Package Manager and Xcode 11.

The 2019 update of Xcode, Xcode 11, integrates Swift Package Manager within Xcode. Pre-Xcode 11, Cocoapods was the defacto dependency manager for Swift/Objc projects. The integration of a native swift package manager into Xcode increased my allure for Swift on the Server.

Things are different now 🥴

Often times models used within the Swift Server are copied from the iOS project. A swift package can be created with all 'central' models and entities and shared between the app and server. The added benefit of the package manager being integrated into Xcode assures that packages can be automatically configured to upgrade to the latest version, bug fix versions, or not upgrade at all, staying fixed on that one version.

Turn up the coding sun, things just became more D.R.Y (Don't Repeat Yourself)

#serverSideSwift

@thetealpickle on the internet. Namaste.

iOS Dev Newbie Consideration 🤔🖐🏾

✨ thetealpickle 📱 — Mon, 05 Aug 2019 21:46:47 +0000

If you're new to iOS Dev in 2019, the thought of SwiftUI or UIKit probably crossed your mind! My answer ♥️