App Store mě poslal k šípku, že nám chybí ikona:

ITMS-90713: Missing Info.plist value - A value for the Info.plist key 'CFBundleIconName' is missing in the bundle 'cz.movapp.app.watchkitapp'. Apps built with iOS 11 or later SDK must supply app icons in an asset catalog and must also provide a value for this Info.plist key. For more information see http://help.apple.com/xcode/mac/current/#/dev10510b1f7.

@pionl, mrkneš na to, prosím?

Datový model

• Většinou není potřeba ručně psát init(from decoder: Decoder) throws - kompilátor je dost chytrý na to aby to zvládnul odvodit.
• Většinou není potřeba psát ani DecodingKeys - JSONDecoderu lze nastavit např. keyDecodingStrategy = .convertFromSnakeCase.
• Nebojte se zanořovat typy (struktura JSONu jde pak vidět na první pohled a ještě to tvoří relativně hezký "namespacing").

Obecně

• Je dobré se vyvarovat používání ! (force unwrap). Může jednoduše způsobit crash a v drtivé většině případů se tomu dá lehce vyhnout použitím if let/guard let.
• V případě použití SwiftPreview na komponentu (ne celou obrazovku) je dobré použít následující modifikátor .previewLayout(.sizeThatFits) (případně dohromady s .padding). Náhled pak bude zobrazovat pouze komponentu a ne celý simulátor, tzn. jde jich vidět daleko více a není tam tolik bílého místa.

• Trošku jsem překopal jak fungují "favorites". Zkoušel jsem to a zdá se mi, že všechno funguje, ale přece jen znáte appku líp, tak menší test by možná nebyl na škodu... :pray:
• Extrahoval jsem nějaké věci, které se používají jako pro náhledy do Dictionary+UIExamples, ale obecně by bylo lepší je spíš definovat pokaždé znovu. Člověk pak nemusí odcházet ze souboru pokud chce změnit náhled, atd...

Aktuálně to máme nastavené tak, že každý překlad v Xcode vyžaduje podpisy. To je hloupé kvůli novým přispěvatelům, kterým takhle házíme klacky pod nohy. Dalo by se to nastavit tak, aby mohl kdokoliv po běžném checkoutu spustit aplikaci na simulátoru? (Zavést třeba novou výchozí konfiguraci?)

• Lokálně udělat bundle exec fastlane release a pushnu změny s tagem (možná by to rovnou mohl udělat ten command
• Github action spustí toto https://github.com/marketplace/actions/create-pull-request
• Vezme se commit message jako title (což vždy bude Release XX) ${{ github.event.head_commit.message }} (https://stackoverflow.com/a/67145320)
• Script automaticky udělá novou branch který se pak smaže (release/TAG?) -> do release branche
• Github action poběží jenom na tag

on:
  push:
    tags:        
      - v1.**

• Nastaví se reviewer na @zoul, @pionl, @met
• Zbytek už známe :)

Pro zamezení review při vývoji nové verze je potřeba upravit release management. Místo PATCH version budeme zvyšovat BUILD number.

• V Xcode se nebude měnit verze vůbec (marketing), pouze build number -> https://docs.fastlane.tools/actions/increment_build_number/
• Formát tagu vMAJOR.MINOR.PATCH.BUILD -> vždy se veme marketing verze + se přidá build number
• Jakmile se provede release do produkce AppStore Spustit se zvýšení PATCH number (může být zase fastlane command). Tag se nebude dělat, pouze se změní marketing verze a pushne se.

Pro zjednodušení (co se v aplikacích častěji používá) bych asi i použil MAJOR.MINOR místo MAJOR.MINOR.PATCH.

Je to takto dostačující?

#41 a #42

@petrillek přepínání barvy baterky atd by bylo docela náročné udělat (co jsem našel). Sjednotil jsem spíše tedy pozadí pod status barem (chová se to pak lépe se skrečování). Abecedu jsem upravil aby využila nový prostor a trochu změnil barvy přepínána.

Průběžné TODO:

• [x] Zavést celoorganizační repo pro certifikáty
• [x] Nastavit Fastlane v projektu
• [x] Zprovoznit podepisování v GitHub Actions
• [x] Zavést release větev
• [x] Udělat GitHub Action pro upload z release větve

Do aplikace by jsme chtěli dát členy týmu - v rámci této úpravy navrhuji udělat jednotnou strukturu json, kterou si pak v budoucnu klidně bude stahovat aplikace.

Struktura by byla formou předem domluvených "skupin":

• Vývoj Apple aplikace
• Vývoj Android aplikace
• Vývoj webu
• Tvorba obsahu
• Ostatní?

Dal bych tam pouze seznam jmen? Chceme dát i odkaz na nějaká profil? Json bude podporovat i případně společnosti.

{
    "data": [
       {
               "section": {"name": "Vývoj Apple aplikace"},
               "persons": [{"name": "František"}]
       }
     ]
}

Souhlas? @met

• Předělal jsem sound service -> nyní lze globálně v aplikaci sledovat zda se něco hraje
• Předělal jsem jak se definují jazyky v aplikaci na lepší řešení @zoul připadá ti to ok?
• Se změnou jazyků nyní jsme schopni přehrávat jak cs tak uk + lze zvuk vypnout (mění se ikonka)
• předělal jsem TabBarItem

Errory jsem opravil nebo zakázal v configu.

Aktuálně je v projektu: Done linting! Found 587 violations, 0 serious in 71 files. Z toho je velká většina buď taby/mezery na prázdném řádku nebo řádek delší jak 120 znaků. To jde odstranit swiftlint autocorrect nebo swiftlint --fix.

Pipeline je nastavená aby kontrolovala pouze změněné soubory.

Před buildem se překontrolují soubory na localu, jen musíš mít lokálně nainstalovaný swiftlint. Do scriptu můžeme ještě přidat i automatické opravy chyb.

Kdyžtak napiš, jestli ti dávají pravidla smysl

Closes #74. Původně jsme releasy vyráběli z nových commitů ve větvi release, ale jelikož GitHub nedělá fast-forward merge, přijde nám to zbytečně zamotané, takže bychom zkusili vyrobit nový release z každého release tagu v main? Konkrétně tahle změna by měla zařídit, že se do App Storu nahraje nový build vždy po pushnutí nového tagu ve formátu v… do main.

Bavili jsme se taky o tom, že se nám na původním workflow s release PRs líbila ta možnost review. Říkal jsem, že u toho tag-based workflow tohle asi nepůjde, ale jde to, viz Reviewing deployments. Fungovalo by to tak, že by po pushnutí tagu naskočila deploy akce ve stavu Waiting a vyžadovala by potvrzení od předem definovaných reviewers. Podle dosavadních zkušeností mně to zatím přijde spíš zbytečné, zkusil bych čistě to workflow založené na tags a uvidíme, jestli budou potřeba nějaké korekce?

Až tohle mergnem, můžem zahodit větev release.

Je potřeba vytvořit unit testy:

• [ ] Kontrola načítání jsonů z movapp-data (team.v1.json, stories, uk-sk-dictionary.json, etc)
• [ ] Kontrolovat zda máme v projektu všechny potřebné resources (mp3 pro slovíčka, pohádky, znaky a obrázky pro pohádky)

If we want for kids rating, we need to implement family controls confirmation before opening any link in menu.

https://developer.apple.com/documentation/familycontrols

For easy review it would be create to create UI test that will screenshot all views in all languages and publishes the index.html on GitHub Pages for a review (and send a slack message to #ua-projekty-preklady-do-vsech-jazyku)

• we have already some tests, but no asserts
• run them in GitHub Actions

Should be easy, bundle exec fastlane tests should be prepared and do the trick