iOS представление "перенаправление"

Question

Я веб-разработчик, которому поручено создавать базовое приложение для iOS для внутреннего использования.Ряд функций в приложении требует аутентификации, и я успешно построил представление / контроллер входа в систему, которое вызывает веб-сервис, аутентифицирует пользователя и т. Д. И т. Д.

В настоящее время я могу загрузить «LoginView» одним нажатием кнопкии после аутентификации пользователя отклоните представление из стека представлений, возвращаясь к исходному представлению, теперь с установленными учетными данными.Ничто из этого не является моей проблемой.

Теперь я ищу эквивалент «перенаправления», как при разработке для сети.Мне нужно загрузить LoginView из любой функции в моем приложении, где требуется аутентификация, и в случае успеха загрузить другое представление, которое будет «передано» (в Интернете я бы предоставил URL-адрес перенаправления) в LoginView.Я чувствую, что это простая вещь, и она должна выполняться постоянно, но я не могу найти хороший пример или объяснение этому.Я уверен, что мое очевидное новшество мешает мне даже искать правильные термины.

Надеюсь, кто-то сможет расшифровать мою бедную, но лучшую попытку объяснить, что я ищу.Заранее спасибо.

Answer 1

Я использовал один шаблон, чтобы передать блок обработчика успеха контроллеру представления аутентификации.

Это имеет преимущество перед делегатской системой в том, что вы можете настроить ее на выполнение любого действия, включая переход на любой контроллер представления, без изменения каждого контроллера представления в соответствии с протоколом делегата.

Например, одна вещь, которую я мог бы сделать после успешной аутентификации, это вернуть стек контроллера представления обратно в главное меню или продолжить обработку запроса веб-службы, который уже выполнялся. Система делегатов на самом деле этого не допускает, в то время как блоки более гибкие, так как вы можете передавать любой код по вашему желанию.

Answer 2

Это идеальная работа для делегатов.В вашем интерфейсе контроллера вида входа в систему (обратите внимание, что я пишу это с головы до головы, так что может быть несколько опечаток / пропущенные точки с запятой и т. Д .:

@protocol LoginControlDelegate <NSObject>
- (void)loginDidSucceed:(BOOL)success
@end

@interface ...
{
    ...
}

@property (nonatomic, assign) id<LoginControlDelegate> delegate;

@end

А затем в вашем файле реализации,После того как вы установили, что веб-служба ответила на запрос входа в систему, вы можете позвонить:

if (self.delegate != nil)
     {self.delegate loginDidSucceed:<YES/NO depending on the webservice response>]

Таким образом, каждый раз, когда вы создаете экземпляр вашего контроллера представления входа в систему, вы можете назначить «родительский» контроллер представления какделегат и затем соответствует <LoginControlDelegate> путем реализации метода loginDidSucceed:

LoginViewController *vc = [[LoginViewController alloc] init....];
vc.delegate = self;
[self presentModalViewController:vc animated:YES];
[vc release];

и метода loginDidSucceed:

- (void)loginDidSucceed:(BOOL)success
{
     if (success)
     // Logged in successfully, push the appropriate view
     } else {
     // Login failed...
}

Answer 3

То, что выложил @Rog, будет работать как указано Я бы только предложил, что если у вас уже есть что-то похожее на WebRequestManager, который отправляет вызовы вашему веб-сервису (создает соединение, управляет ошибками, возвращает данные), чтобы не беспокоиться о делегировании имени входа, а вместо этого управлять этим представлением входа в систему в менеджер, изолирующий все ваши взгляды от необходимости такого рода делегата (который становится головной болью обслуживания).

Таким образом, ваши представления просто инициируют запрос через менеджера и ожидают, что данные будут возвращены, независимо от того, требуется ли авторизация. Примечательно, что приложению даже не нужно (или не может) знать, какие запросы требуют входа в систему, только обнаруживая это как ответ от сервера. В этот момент вы можете запустить представление входа в систему, получить учетные данные, а затем перезапустить запрос с действительными учетными данными.

И в этот момент я сохраню учетные данные, по крайней мере, для текущего сеанса выполнения, поэтому любые будущие запросы не требуют другого входа в систему.

Answer 4

Разработка для мобильных устройств - это не то же самое, что разработка для Интернета.В общем, приложения будут иметь логин пользователя один раз, а затем никогда не получат (или, по крайней мере, только когда приложение открыто, как Mint).Если возможно, рассмотрите возможность изменения дизайна приложения, чтобы соответствовать соглашениям о мобильном дизайне, а не заимствовать из веб-мира.Это другая игра с мячом, и ваши пользователи это оценят.

Тем не менее, я мог бы атаковать это, создав собственный UIView, основанный на дизайне Apple для UIAlertView.Дайте ему протокол делегата, и когда он вернется с аутентифицированным пользователем, контроллер, из которого вы его вызвали, может внести соответствующие изменения в себя, используя метод делегата.