передающие данные в ntier приложении

Я прочитал очень много статей по этой проблеме, где экранная клавиатура отказывается прятаться, когда вы звоните resignFirstResponder, но ни одно из предложений не сработало для меня.

Я использую XCode 5 (iOS 7) и у меня есть экран iPhone, содержащий пару элементов управления, для которых требуется экранная клавиатура, но если пользователь нажимает UIButton, то я хочу, чтобы клавиатура исчезла.

enter image description here

Я, вероятно, потратил впустую один полный день, экспериментируя с resignFirstResponder и добавляя disablesAutomaticKeyboardDismissal функции для возврата NO, но ничего не помогло. Как только появилась экранная клавиатура, я больше не мог заставить ее исчезнуть.

1117 Но потом у меня была небольшая мозговая волна (поскольку у меня только маленький мозг).

Теперь, когда пользователь нажимает на мой UIButton, я просто отключаю элементы управления UITextField и UITextView.

- (IBAction)btnDate_Tapped:(id)sender {
    //  The user has clicked on the "Date" button.
    self.tbClientName.enabled = NO;
    self.tbComments.editable = NO;

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

(С облегчением вздохнул.)

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

-(void)popoverControllerDidDismissPopover:(UIPopoverController *) popoverController {
    //  The user has closed our popup dialog.
    //  We need to make our UITextField and UITextView editable again.
    self.tbClientName.enabled = YES;
    self.tbComments.editable = YES;
    ... etc...
}

Просто, не правда ли?

И что удивительно, этот обходной путь работает даже на UIViewControllers, который появляется в Модальном стиле.

Надеюсь, это поможет другим жертвам XCode.

8
задан eiu165 27 May 2009 в 20:05
поделиться

4 ответа

If you're using a layered approach, meaning all layers are (essentially) executing in the same process space and there is therefore no marshalling/serialization, I'd go with approach B. Create a separate module for your entities upon which all aspects of your program depend, and couple to that.

If, however, you're using a tiered approach as your title suggests, meaning there are process and/or network boundaries that are crossed, I'd suggest you go with approach C. You're not really passing instances around, you're passing copies, so any benefits you get to coupling to the same object, like observable options for, say, an MVC approach, are lost anyway. Better to define data APIs at every tier level than to try to use the same class all around.

5
ответ дан 5 December 2019 в 22:20
поделиться

Отличный вопрос - как всегда, ответ должен быть «это зависит».

От типа приложения и действительно ли необходимость в бизнес-объектах ( Entities), в отличие от передачи объектов (т. Е. Упрощенных бизнес-объектов, которые больше соответствуют сущностям базы данных).

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

Однако с тех пор, как я начал работать с Linq to SQL, мои парадигмы изменились. В этом больше нет необходимости, поскольку модель Linq может включать в себя все - бизнес-объекты, объекты передачи и общие наборы данных. Я еще не исследовал, насколько хорошо это работает в действительно больших приложениях и должна ли быть необходимость изолировать внешний код от модели Linq. Я обсуждал это с коллегами, но так и не нашел ответа.

1
ответ дан 5 December 2019 в 22:20
поделиться

Я предполагаю, что все 3 уровня существуют в одном приложении. По крайней мере, в java я использовал Hibernate для доступа к данным и использовал эти компоненты данных на всех уровнях. (вариант B) Имеет смысл иметь возможность повторно использовать ваши объекты в ваших слоях.

0
ответ дан 5 December 2019 в 22:20
поделиться

Мне нравится вариант C, но он также заставляет меня задуматься по двум причинам:

  1. Я должен распространять знания о том, какие свойства есть во многих местах.
  2. DTO должны быть сериализуемыми, что не является Это не ужасно, но все же стоит задуматься.
0
ответ дан 5 December 2019 в 22:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: