2016-08-22 24 views
14

Mamy niestandardowych obiektów UIApplication, więc nasz main.swift byłXcode 8 beta 6: main.swift nie będzie skompilować

import Foundation 
import UIKit 

UIApplicationMain(Process.argc, Process.unsafeArgv, NSStringFromClass(MobileUIApplication), NSStringFromClass(AppDelegate)) 

i że nie działał w Xcode 8 beta 5 więc użyliśmy tego

//TODO Swift 3 workaround? https://forums.developer.apple.com/thread/46405 
UIApplicationMain(Process.argc, UnsafeMutablePointer<UnsafeMutablePointer<CChar>>(Process.unsafeArgv), nil, NSStringFromClass(AppDelegate.self)) 

na Xcode 8 beta 6 otrzymujemy Korzystając z nierozwiązanym identyfikatorze 'proces'

Co musimy zrobić w Xcode 8 beta 6/Swift 3 do zdefiniowania UIApplicationMain?

+0

Jak w ten sposób określić klasę UIApplication? –

Odpowiedz

31

piszę to w ten sposób:

UIApplicationMain(
    CommandLine.argc, 
    UnsafeMutableRawPointer(CommandLine.unsafeArgv) 
     .bindMemory(
      to: UnsafeMutablePointer<Int8>.self, 
      capacity: Int(CommandLine.argc)), 
    nil, 
    NSStringFromClass(AppDelegate.self) 
) 

Aby zmienić klasę UIApplication, zastąpić NSStringFromClass(MobileUIApplication.self) dla nil w tym preparacie.

Jeśli jednak tylko celem jest tutaj zastąpić podklasy UIApplication jako udostępnionego instancji aplikacji, istnieje prostszy sposób: w Info.plist dodaj klucz „główny class” i ustawić jej wartość na nazwę napisu twojej podklasy UIApplication i oznacz swoją deklarację tej podklasy atrybutem @objc(...), nadając jej tę samą nazwę obiektu C.

3

Wydaje Process została zmieniona na CommandLine w beta 6.

CommandLine

ale rodzaj CommandLine.unsafeArgv jest niedopasowanie drugi argument UIApplication, więc może trzeba napisać coś takiego:

CommandLine.unsafeArgv.withMemoryRebound(to: UnsafeMutablePointer<Int8>.self, capacity: Int(CommandLine.argc)) {argv in 
    _ = UIApplicationMain(CommandLine.argc, argv, NSStringFromClass(MobileUIApplication.self), NSStringFromClass(AppDelegate.self)) 
} 

(AKTUALIZACJA) To niedopasowanie należy uznać za błąd. Ogólnie rzecz biorąc, lepiej wysłać bug report, gdy znajdziesz rzeczy "to nie powinno być", takie jak trzeci parametr w wersji 5. Mam nadzieję, że ten "błąd" zostanie wkrótce naprawiony.


Jeśli chcesz tylko wyznaczyć niestandardową klasę UIApplication, dlaczego nie używasz Info.plist?

NSPrincipalClass | String | $(PRODUCT_MODULE_NAME).MobileUIApplication 

(pokazana jako "główny" w klasie non-raw kluczy/wartości zobaczyć.)

Mając to na swojej Info.plist można używać MobileUIApplication z wykorzystaniem @UIApplicationMain normalny sposób.

(dodatkowo) Header doc z UIApplicationMain:

// If nil is specified for principalClassName, the value for NSPrincipalClass from the Info.plist is used. If there is no 
// NSPrincipalClass key specified, the UIApplication class is used. The delegate class will be instantiated using init. 
+0

Należy pamiętać, że ta sytuacja jest uważana za błąd. Ta odpowiedź jest mniej więcej taka sama jak tutaj podana: https://bugs.swift.org/browse/SR-1390?focusedCommentId=17441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment -17441 – matt

+0

@matt, Nie sądzę, aby zmiana nazwy 'Proces' na' CommandLine' nie była identyczna z raportem o błędzie.Ale tak, pozornie głównym kodem w mojej odpowiedzi jest obejście tego błędu, a ja zaktualizuję część. – OOPer

+0

NSPrincipalClass nie ma znaczenia przy korzystaniu z systemu iOS. Ale wiemy, że OP używa tego systemu iOS, inaczej nie rozmawialiśmy o UIApplicationMain. – matt

Powiązane problemy