Am avut nevoie în zilele acestea de mai multe informații despre DateFormater – modalitatea prin care pot “pregăti” un Date pentru a fi afișat.
Am găsit o resursă foarte tare care-mi permite practic să formatez date-ul asa cum imi doresc – http://nsdateformatter.com/.
Foarte tare partea aia de localizare.
P.S. Vin cu o extensie la Date pentru a verifica dacă Date-ul conține ziua de azi
extension Date {
func isToday() -> Bool {
return Calendar.current.isDateInToday(self)
}
}
Se da o aplicatie IOS. Butoane, label-uri “scrise” in limba de baza – base language. Se cere, de un ipotetic client, ca aplicatia sa fie disponibila in … olandeza de exemplu.
Cum procedam?
1. Introducem un nou fisier in proiect – String File si il denumim Localizable
3. Deschidem fisierul nostru de stringuri – Localizable.strings – si in File Inspector observam un meniu nou “Localization” cu un buton “Localize” pe care trebuie sa-l activam. Aceasta sectiune isi schimba continutul, avand in mod predefinit Base – bifat. Activam si limba pe care tocmai am adaugat-o in proiect si in acest moment fisierul nostru Localizable.strings devine folder cu doua inputuri – Localizable.strings (Base) si Localizable.strings (Dutch).
Cum folosim localizarea mai sus configurata?
Avem de exemplu un label “Cancel”. Acesta va trebui sa fie etichetat cu “Annuleer” in olandeza.
1. In fisierul Localizable.strings (Base) adaugam:
cancelButton = "Cancel";
iar in Localizable.strings (Dutch)
cancelButton = "Annuleer";
acesta este stringul pe care-l vom folosi functie de ce localizare are telefonul userului
2. definim un string localizat de forma in fisierul nostru in care avem IBOutlet-ul catre buton:
let cancelBtn = NSLocalizedString("cancelButton", comment: "Cancel")
3. Definim un AlertAction – de exemplu – care va fi etichetat functie de localizare
let cancel = UIAlertAction(title: cancelBtn, style: .Cancel, handler: {
(alert: UIAlertAction) -> Void in
Log.d("Cancel");
});
4. Command+R
Adium pentru IOS are un plugin special pentru filtrarea cuvintelor urate – profanity list – care in schimb e foarte Objective C.
Am modelat in playground o clasa speciala de Regular Expression prin intermediul careia filtrez continutul unui dictionar. Ideea de baza este de aici
var badWordDictionary: [String : String] = [
"cuvant1" : "*******",
"cuvant2" : "*******",
"cuvant3" : "*******",
"cuvant4" : "*******",
"cuvant5" : "*******",
"cuvant6" : "*******",
]
var bannedWords = badWordDictionary.keys
var bannedPattern = bannedWords.joined(separator: "|")
var badWordPattern = "\\b(?:\(bannedPattern))\\b"
class MeetMeBadWordRegularExpression: NSRegularExpression {
override func replacementString(for result: NSTextCheckingResult, in string: String, offset: Int, template templ: String) -> String {
let matchingRange = result.range
let matchingWord = (string as NSString).substring(with: matchingRange)
if let replacedWord = badWordDictionary[matchingWord] {
return replacedWord
} else {
return "*"
}
}
}
Apoi vom folosi astfel:
var bodyMessage = "acesta este cuvant1"
let regex = try! MeetMeBadWordRegularExpression(pattern: badWordPattern, options: [])
let clearBodyMessage = regex.stringByReplacingMatches(in: bodyMessage as! String, options: [], range: NSRange(0..<(bodyMessage as! String).utf16.count), withTemplate: "")
print("clean message - \(clearBodyMessage)")
Vom avea clean message - acesta este *******
Deranjant uneori, separatorul dintre View-ul principal si UINavigationBar aparut in IOS 7 poate fi scos prin adaugarea acestui cod in AppDelegate -> application: didFinishLaunchingWithOptions:
UINavigationBar.appearance().setBackgroundImage(
UIImage(),
forBarPosition: .Any,
barMetrics: .Default)
UINavigationBar.appearance().shadowImage = UIImage()
Cea mai utilizata situatie in care sunt folosite XIB-urile este aceea a view-urilor. In aceasta situatie putem defini, configura si testa un TableViewCell – de exemplu – fara a mai incarca si restul de elemente grafice definite in Storyboard sau alte XIB-uri.
Un exemplu in acest sens:
– adaugare XIB file atunci cand adaug un fisier “Cocoa Touch Class”. Se adauga fisierului .swift un fisier .xib cu acelasi nume dar continand “reprezentarea grafica” a clasei derivate.
– clasa adaugata pentru un UITableViewCell-> RequestProfileTableViewCell.swift si .xib file adaugat.
– adaugam continut in RequestProfileTableViewCell.xib si generam IBOutlet/IBAction pentru elementele din .xib in .swift
– daca este cazul -> definim continutul RequestProfileTableViewCell.swift
Din experienta mea, acest ultim pas, cel cu definire de continut este cel mai putin consistent. Foarte important e faptul ca, in prealabil, se definesc IBOutlet/IBAction pentru elementele grafice “desenate” in XIB.
Cum folosim view-ul definit XIB?
In exemplul nostru am definit un UITableViewCell.
Vom folosi acest Cell intr-un TableView atunci cand vom scrie codul pentru delegatul tableView(_:cellForRowAt:) – cam ciudatica aceasta sintaxa folosita in Swift dar cu timpul ea devine inteligibila –
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = Bundle.main.loadNibNamed("RequestProfileTableViewCell", owner: self, options: nil)?.first as! RequestProfileTableViewCell
cell.textLabel?.text = "bubu"
return cell
}
Am bolduit modul de “import” al XIB-ului aferent unei UITableViewCell. Foarte simplu si autocomplete-ul XCode-ului ajuta daca cumva omit vre-un parametru.