Apple hat eine kleine Einschränkung in AppIntents und zwar kann man nicht so einfach eine LiveActivity aus einem App Intent starten.

> Error requesting Live Activity visibility.

Man kann es zum Glück leicht lösen in dem man ```LiveActivityStartingIntent``` als Protokoll ergänzt:

```swift
import AppIntents

struct ShowACommentIntent: AppIntent, LiveActivityStartingIntent {
    
    static var title: LocalizedStringResource = "Show a comment"
    static var description = IntentDescription("Show a comment with configuration")
    
    @Parameter(title: "Comment")
    var comment: String?
      
    
    func perform() async throws -> some IntentResult {
    
    /// Do your thing
    
    }
    
 }
 ```

Live Aktivität  und ActivityAuthorizationError.visibility in Appintent

Bist du es auch leid, von einem Projekt zum anderen zu springen, und manchmal brauchst du nodejs 14, manchmal brauchst du nodejs 16, und manchmal brauchst du nodejs 18.

Mir geht es genau so und ich weiß, es ist nur ein Befehl mit ```nvm``` oder mein persönlicher Favorit ```n```.

Aber was wäre, wenn man in sein Projekt geht und die richtige Node-Version ist immer da?

Das war auch mein Wunsch und ich habe ihn erfüllt.

### Was brauchst du
- [node](https://nodejs.org/de) (hoffe das ist schon installiert)
- [nvm](https://github.com/nvm-sh/nvm) oder [n](https://github.com/tj/n) 
- [zsh](https://ohmyz.sh/)
- [node-package-version](https://github.com/tzdesign/node-package-version)

Wenn du mein Tool installierst, kannst du mit npv fix direkt schon die richtige node version bekommen.

### Installation

```bash
npm install -g node-package-version
```
oder 
```bash
yarn install -g node-package-version
```

Danach einfach in deine ```.zshrc`` folgenden Teil hinzufügen:

```bash
precmd(){
    npv fix
}
```

Jetzt reicht enter drücken oder ein neues terminal im Projekt öffnen und schon ist läuft das Skript und wählt die richtige Node-Version.



Node version über package.json

Auch in Qwik braucht man machnmal komplexere Komponenten, die sowohl als Link als auch als Button oder welches Element auch immer gerendert werden müssen.

## QwikIntrinsicElements

Der Type QwikIntrinsicElements ist hier die Basis auf die du setzen solltest.
Das Qwik-Team hat hier die **HTMLAttributes**  erweitert.

Wie können jetzt deine Props aussehen? Wie der Titel schon vermuten lässt, kommen wir nicht um Generics herum.

Für meine Buttonkomponent sehen die Props so aus:

```tsx
export type ButtonProps<C extends keyof QwikIntrinsicElements> =

QwikIntrinsicElements[C] & {
	as?: C;
};
```

**C** ist dann die prop, die entscheiden, was für Props aus QwikIntrinsicElements verwendet werden.

Die Implementierung dafür ist dann insgesamt folgende:

```tsx
import type { QwikIntrinsicElements } from '@builder.io/qwik';
import { component$, Slot } from '@builder.io/qwik';

export default component$(
  <C extends keyof QwikIntrinsicElements>(props: ButtonProps<C>) => {
    const Component = (props.as ?? 'button') as string;
    return (
      <Component>
        <Slot />
      </Component>
    );
  }
);

export type ButtonProps<C extends keyof QwikIntrinsicElements> =
  QwikIntrinsicElements[C] & {
    as?: C;
  };

```

Gern kannst du unter ```as?``` einfach noch deine eigenen Props hinzufügen.


## Casting als String

```tsx
 const Component = (props.as ?? 'button') as string;
```

Leider scheint es noch kein sauberer Übertrag in JSX zu existieren. Ich habe relativ viel experimentiert und mit ```keyof QwikIntrinsicElements``` etc. gearbeitet. Ich hatte erst mit ```any```gearbeitet, aber da viele von euch sicher Prettier und Lint nutzt, finde ich string hier etwas passender.

Viel einfacher als in React, wo man immer auch ```forwardRef``` mit denken muss.

Viel Spaß mit Polymorphism



Qwik Polymorphism

Wer hätte es gedacht, aber es gibt eine Alternative zu ```parseInt``` und ```parseFloat``` um mit Usereingaben weiterzuarbeiten.

```tsx
<input type="number" onChange={(event) => {

console.log(event.target.valueAsNumber)

}} />
```

Als ob das nicht schon genug Good News ist, gibt es auch noch valueAsDate:

```tsx
<input type="date" onChange={(event) => {

console.log(event.target.valueAsDate)

}} />
```
    
Mehr Infos findet ihr auf dem [Builder.io Blog](https://www.builder.io/blog/numbers-and-dates).

HTML Input ValueAs

Du kennst das sicherlich, du schreibst eine Funktion und am Ende hast du mehrere Blöcke IF-ELSE.


Klar kann es auch sein, dass dein Programmierstil etwas **dirty** ist, aber vielleicht arbeitest du auch einfach mit einer Sprache die kein guard unterstützt wie z.B. Typescript/Javascript.

Hier ein Beispiel, was für eine Art code ich meine:


```typescript
function getClassNameByNumber(number: number): string {
  if (number > 100) {
    return "dark";
  } else if (number > 50) {
    return "medium";
  } else {
    return "light";
  }
}
```



## Fallthrough switch

Klar kann man bei vielen solcher Funktionen vermutlich auch ein switch nehmen, ist sich aber genauso schlecht lesen.


```typescript
function getClassNameByNumber(number: number): string {
  switch (true) {
    case number > 100:
      return "dark";
    case number > 50:
      return "medium";
    default:
      return "light";
  }
}
```

## guard-style in Javascript

Nutzt man aber eine Art **guard-style**-Code, ist es viel viel einfacher zu lesen:

```typescript
function getClassNameByNumber(number: number): string {
  if (number > 100) return "dark";
  if (number > 50) return "medium";
  return "light";
}
```
## Das echte Guard-Statement in Swift

Achtung, guard ist eine Art negative IF. Deshalb sind die Logiken hier umgedreht. Nur wenn das Guard-Statment True ist, geht es in der Funktion weiter.



```swift
func getClassName(for number: Int) -> String{
    guard number < 100 else { return "dark" }
    guard number < 50 else { return "medium" }

    return "light"
}
```

## Fazit

Ich denke das diese Art von Abfragen viel besser lesbar sind. Natürlich sollte man Funktionen so klein wie möglich halten und im letzten Return-Statement sollte eigentlich immer der Rückgabetyp eingehalten werden.

Grade in Swift, möchte ich guard nicht mehr hergeben.

Guard Statements statt IF-ELSE Hölle

Tobias Zimmermann

Softwarearchitekt und Interaction Designer

Vor kurzem habe ich mich dazu entschlossen, meine 5 Jahre alte App von UIKit auf SwiftUI umzuschreiben. 

Das war keine leichte Entscheidung, da eine solche Umstellung eine Menge Arbeit bedeutet und auch ein gewisses Risiko birgt. Aber ich bin überzeugt, dass es sich gelohnt hat und möchte in diesem Blogbeitrag beschreiben, warum ich mich für diesen Schritt entschieden habe.

![swiftuimigration](https://api.tzdesign.de/uploads/swiftuimigration_d0a3c6b4f9.png)

## Vorbereitung

Da ich über 100 verschiedene Views habe, war ein komplettes Umschreiben viel zu gefährlich. Ich habe mich deshalb ausgiebig mit [UIViewRepresentable](https://developer.apple.com/documentation/swiftui/uiviewrepresentable) beschäftigt.

Mit dieser API ist es möglich sehr komplexe Views und auch Views, wo es aktuell noch keine nativen SwiftUI-Alternativen gibt, weiterzuverwenden.

Ein Beispiel ist UIPageController. Es gibt zwar die Möglichkeit mit statischen Seiten TabView zu benutzen, aber das ist nicht das Gleiche.

Ich muss allerdings dazu sagen, dass ich in naher Zukunft für PageController keine SwiftUI Alternative bekomme. Deshalb bleibt der sicher noch etwas da:

```swift
import SwiftUI
import UIKit

struct PageView<Page: View>: UIViewControllerRepresentable {
    
    var pages: [Page]
    @Binding var currentPage: Int
    
    func makeUIViewController(context: Context) -> UIPageViewController {
        let pageViewController = UIPageViewController(transitionStyle: .scroll, navigationOrientation: .horizontal)
        
        pageViewController.dataSource = context.coordinator
        pageViewController.delegate = context.coordinator

        return pageViewController
    }
    
    func updateUIViewController(_ pageViewController: UIPageViewController, context: Context) {
        var direction: UIPageViewController.NavigationDirection = .forward
        var animated: Bool = false
        
        if let previousViewController = pageViewController.viewControllers?.first,
            let previousPage = context.coordinator.controllers.firstIndex(of: previousViewController) {
            direction = (currentPage >= previousPage) ? .forward : .reverse
            animated = (currentPage != previousPage)
        }
        
        let currentViewController = context.coordinator.controllers[currentPage]
        pageViewController.setViewControllers([currentViewController], direction: direction, animated: animated)
    }
    
 }

```

## Von View zu View

Mit **UIViewControllerRepresentable** konnte ich also SwiftUI mit UIKit nebenher nutzen. 



Von UIKit zu SwiftUI

amplify console

amplify-cli

apache

apollo-client

apollo-server

aws-lambda

aws-rds

canvas

docker

enzyme

express

golang

grunt

gulp

HTML

Icon Design

Javascript

jest

jquery

kubernetes

lambda

mobx

MongoDB

MySQL

nextjs

nginx

nodejs

objective-c

oclif

qwik

react

react-native

redux

responsive design

ruby

SASS

serverless

swift

SwiftUI

symphony

Typescript

webpack

yarn

StempelUhr App

Website.png

Shop-Fair / technische Umsetzung

Bildschirmfoto 2022-01-14 um 16.55.59.png

Intermittent Fasting

tzdesign.de.png

Freibad Grasleben

Bildschirmfoto 2022-01-15 um 09.07.20.png

EAGOSH

Bildschirmfoto 2022-01-14 um 17.00.50.png

Tobias Zimmermann

Softwarearchitekt und Interaction Designer

Letzte Blogeinträge

Meine Projekte

Software und Skills