SwiftUI dev
1.03K subscribers
87 photos
35 videos
1 file
72 links
Mobile development, SwiftUI, Compose, fell free to reach me: @lexkraev
Download Telegram
Must-have SUI-frame extension

Весьма удобные модификаторы, позволяющие избегать Spacer() и .frame(). Взял у Kavsoft :)
Забрать можно отсюда

Useful modifiers to avoid Spacer() and .frame(). Check out here.

#howto #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
У LazyVGrid отсутствует возможность объединения столбцов.
Сделал пример, как можно это реализовать

LazyVGrid does not have a column span feature.
This tutorial demonstrate how we could implement it easily.

#howto #getsources
Проект с примерами различных анимаций на SwiftUI с лицензией бесплатного коммерческого использования.

A repository containing a variety of animations and Animated components created in SwiftUI that you can use in your own projects.

#howto #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
Possible implementation of waterfall grid with row spanning-trick effect based on LazyVStack.

Реализация грида с ячейками разной высоты на LazyVStack.

#howto #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
Implementation SwiftUI tab bar instead of UIKit’s.

Написал статью, как мы внедряли SwiftUI таб-бар взамен UIKit.

#readthis #howto
This media is not supported in your browser
VIEW IN TELEGRAM
Увидел этот пример в ленте linkedin (первоисточник — Eran Lunenfeld, который реализовал на jetpack compose). Решил воспроизвести сам 😊 Думаю, хороший челендж и пример для тестовых заданий на SwiftUI. Попробуйте сверстать сами: есть интересные моменты. Посмотреть код здесь

Saw this example in news feed on linkedin, author was Shai Mishali (who originally saw it from Eran Lunenfeld in his turn) and decided to reproduce myself ))
Think it was nice challenge ))
Try to make it yourself! Anyway code is here

#trytodo #howto #tasty #groovy #getsources
This media is not supported in your browser
VIEW IN TELEGRAM
По-умолчанию, если вы добавляете кнопку в ячейку, вся ячейка будет реагировать на action этой кнопки.

Для ожидаемого поведения используйте модификатор .buttonStyle(PlainButtonStyle()) (или .buttonStyle(BorderedButtonStyle()), доступный с iOS 15)

By default, if you add a button to a SwiftUI's cell, all the cell's area will react to button's action.

To fix this, use .buttonStyle(PlainButtonStyle()) modifier (or .buttonStyle(BorderedButtonStyle()) available from iOS 15)

#howto
Media is too big
VIEW IN TELEGRAM
Кастомизируем таб бар Код можно найти здесь

Customising and animating tab bar 🌊 using SwiftUI Code is here

#howto #tasty #groovy #getsources
В SwiftUI отсутствует метод viewDidLoad(), самый близкий по смыслу: onAppear. Можно сэмулировать поведение viewDidLoad() следующим модификатором.

There is no viewDidLoad() equivalent method in SUI, the closest one is onAppear. Actually we can simulate viewDidLoad() behavior with custom modifier.

#howto
This media is not supported in your browser
VIEW IN TELEGRAM
Навигация

Один из блоков вопросов на iOS - собеседовании - архитектура приложений. При этом почти в любой архитектуре вопросы навигации всегда находятся сбоку от обсуждения. Более того, для навигации разрабатывают свои паттерны. Одними из таких являются координатор и навигатор.

Начиная с SwiftUI 1.0 Apple практически на каждом WWDC рассказывает про работу с MVVM, как будто забывая про роутинг. Да, нам показали NavigationView, NavigationLink, но не покидало ощущение, что Apple опять представили что-то промежуточное. Многие стали писать свои обертки над этим API, чтобы сделать работу удобнее. И наконец в iOS 16 Apple представили новое API навигации, которое так долго ждали.

Вместо NavigationView (deprecated) теперь нужно использовать NavigationStack. Экран для перехода будет определять модификатор navigationDestination.

Будем честны, многие команды до сих пор используют роутинг на UIKit в проектах на SwiftUI. Даже те, кто пытались разобраться в NavigationView, в конечном итоге возвращались обратно в UIKit. С появлением нового API навигации такой подход - поворот не туда. С другой стороны, новое API требует минимальный таргет у проекта iOS 16.0 . Что делать? Использовать бэкпорт! Можете создать свой тестовый проект, чтобы поработать с этой библиотекой. Мой сэмпл здесь.

#switfpm #howto #getsources #groovy
SwiftUI dev
Навигация Один из блоков вопросов на iOS - собеседовании - архитектура приложений. При этом почти в любой архитектуре вопросы навигации всегда находятся сбоку от обсуждения. Более того, для навигации разрабатывают свои паттерны. Одними из таких являются координатор…
Navigation

Hey guys! I’ve created test project with sample of new navigation API back ported in older SwiftUI versions.

One of the main question at every iOS-interview is app architecture. At the same time routing in the app almost always is the side theme of discussion. Moreover there are different approaches in the navigation in general and all of them have their own patterns such as navigator or coordinator.

Starting from SwiftUI 1.0 in almost every WWDC Apple talks about working with MVVM as if forgetting about routing. Yes, we were introduced to NavigationView, NavigationLink. But the feeling that Apple again has presented intermediate solution does not leave us. Some developers started to create their own wrappers over this API for convenience. Finally in iOS 16 Apple introduced the long-awaited new navigation API.

Instead of NavigationView (starting with iOS 16 it has been deprecated) we have to use NavigationStack. Now the navigationDestination modifier defines a view to display.

Frankly speaking many teams are still using UIKit routing in SwiftUI projects. Even those who tried to understand NavigationView, gave up and went back to UIKit. With the release of the new navigation API, this approach is a wrong turn. Apart from that the new API requires a minimum deployments as iOS 16.0. So what to do? Use a backport! Try my sample! You may create your own test project to try to work with this package using it.

#swiftpm #howto #getsources
⚖️ Хорошая либа FluentUI от Microsoft как пример того, как можно хорошо структурировать дизайн-систему

👷‍♂️ Nice package Microsoft's Fluent UI as example how you can organize your design system

#swiftpm #howto #getsources #groovy
🧭 Быстрая навигация на канале

#readthis - ссылки на статьи, книги и др
#watchthis - ссылки на видео
#howto - воркшопы, обучающие статьи и т п
#getsources - ссылки на проекты с открытым исходным кодом (включая #swiftpm модули)
#trytodo - челенджи, иногда простые, иногда не очень
#groovy - посты с наибольшим количеством шарингов и реакций
#tasty - “посмотри, чтоб вдохновиться”, здесь будут анимации, концепты и т п
🧭 Quick navigation

#readthis - recommended articles, books, etc
#watchthis - recommended videos, clips, etc
#howto - tutorials, rtfm
#getsources - where the hell are sources? open-source repositories (including my own swift packages #swiftpm), projects
#trytodo - “try to do” challenges, sometimes not easy
#groovy - trending high-rated posts based on statistics (private or public sharing and positive reactions)
#tasty - cool creative features (animations, concepts, etc), might be useful for inspiring developers, designers or PMs
Media is too big
VIEW IN TELEGRAM
💣 Мобильная разработка разделена между iOS и Android. iOS популярна на Западе, а у Android больше пользователей по всему миру.

Пренебрежение любой платформой означает отказ от большого процента потенциальных пользователей. За редким исключением приложения сначала создаются для iOS, а значит и дизайн разрабатывается сначала для iOS.

В последнее время крупные компании стараются сократить время разработки на обеих платформах. Кроссплатформенная разработка — один из способов сделать это. В моем последнем проекте мы выбрали для этого KMM. Но, будем честны, используя KMM-подход, вы сначала разрабатываете для Android-платформы, а уже потом адаптируете код для iOS. Но есть ли способ делать наоборот? Да, Skip.

Мой демо-проект с использованием Skip здесь.

🧨The mobile development is divided between iOS and Android. iOS is popular in the West, while Android has more worldwide users.

Neglecting either platform means leaving behind a large percentage of potential users. However, apps are generally made for iOS first. Clients ask for an iOS app, then expect a port to the Play Store. Actually companies design for iOS first, then adapt their designs for Android.

However large tech companies really try to reduce the development time on both platforms. Cross-platform is one of the ways to do it. On my last project we choosed KMM for this. But using KMM-approach you firstly develop for Android-platform and after that you adapt code for iOS. Is there any way to do the opposite? Yes, to use a Skip.

My demo project is here.

#getsources #howto #readthis #tasty #groovy
Media is too big
VIEW IN TELEGRAM
🔥 Весьма удобный и крутой лайфхак, как можно быстро помочь себе в верстке

🧨 Really nice and awesome lifehack how to help yourself with layouts

Думаю, уже все знают про то, как найти размер вьюхи с помощью GeomertyReader, если .frame не задан. Если нет, то я напомню:

Hope everyone already knows how to find the view size using GeomertyReader if .frame is not specified. Don’t worry, I'll remind you:


import SwiftUI

struct SizePreferenceKey: PreferenceKey {
static var defaultValue: CGSize = .zero
static func reduce(value: inout CGSize, nextValue: () -> CGSize) {
value = nextValue()
}
}

struct MeasureSizeModifier: ViewModifier {
func body(content: Content) -> some View {
content.overlay(GeometryReader { geometry in
Color.clear.preference(key: SizePreferenceKey.self,
value: geometry.size)
})
}
}

extension View {
func measureSize(perform action: @escaping (CGSize) -> Void) -> some View {
self.modifier(MeasureSizeModifier.init())
.onPreferenceChange(SizePreferenceKey.self, perform: action)
}
}


Теперь создадим структуру и модификатор, которые будем использовать для отображения границ размера элемента:

Next let's create a struct and modifier for displaying the view size:


import SwiftUI

struct Measurements: View {

@State private var size: CGSize = .zero

let showSize: Bool
let color: Color

var body: some View {
label.measureSize { size = $0 }
}

var label: some View {
ZStack(alignment: .topTrailing) {
Rectangle()
.strokeBorder(
color,
lineWidth: 1
)

Text("H:\(size.height.formatted) W:\(size.width.formatted)")
.foregroundColor(.black)
.font(.system(size: 8))
.opacity(showSize ? 1 : 0)
}
}
}

extension View {
func measured(_ showSize: Bool = true, _ color: Color = Color.red) -> some View {
self
.overlay(Measurements(showSize: showSize, color: color))
}
}

extension CGFloat {

var formatted: String {
abs(self.remainder(dividingBy: 1)) <= 0.001
? .init(format: "%.0f", self)
: .init(format: "%.2f", self)
}
}

extension Double {
var formatted: String {
CGFloat(self).formatted
}
}


А теперь можете сравнить итоговые вьюхи с макетами и проверить на случайные .padding():

That’s all! Now you can compare views in Canvas with the designed in Figma and check on accidental .padding():


YourView()
.measure()


#howto #getsources #groovy

@swiftui_dev