Действительно, попадание платежных данных (как и паролей) на скриншот равноценно их сохранению в файл. Но решением здесь является не маскирование скриншота, а маскирование самого поля «звездочками». Таким образом, данные не будут видны не только на скриншоте, но и на самом экране (который можно увидеть, открыв само приложение, если оно еще запущено; либо просто «через плечо»).
Но часто данные предлагается вводить в банковскую платежную веб-форму, которая используется не только внутри приложений, но и в браузере. А в этом случае нельзя контролировать, какие скриншоты маскировать, зато можно маскировать поля. Но это задача разработчиков платёжной формы.
В данном случае мы не храним ни паролей, ни ключей (которые действительно стоит хранить в keychain), ни платежной информации (которую вообще нежелательно хранить ни в каком виде). Некоторые личные данные хранятся в файлах с использованием iOS Data Protection. Хранить их в keychain смысла не имеет, тем более, что их можно просмотреть в самом приложении, запустив его.
Следовательно, если пользователь не установил пароль на телефоне, и злоумышленник получил физический доступ к нему, то защищать эти данные уже невозможно.
1. Если перевода для некоторой метки не будет найдено в словаре текущего выбранного языка, и для него не специфицирован язык-заместитель (см. ниже), то для перевода будет использована сама метка. В принципе, сама метка может выступать в качестве отображаемого текста. Метки поддерживают пробелы и некоторые спецсимволы. Это может быть любая строка, которая может быть ключом JSON.
2. Вариант Default text, к сожалению, не поддерживается, в качестве текста будет отображаться метка.
3. Что касается поиска в нескольких локалях:
Опять же, если перевода для некоторой метки не будет найдено в словаре текущего выбранного языка, и для него не специфицирован язык-заместитель (так называемый fallback language), то для перевода будет использована сама метка. Метка может быть произвольного вида, не обязательно в стиле “uppercased”. Таким образом, при желании, дефолтный язык можно отображать самими метками. Также можно задать язык по умолчанию вызовом .preferredLanguage('en').
Вы действительно правы: Xmarin — это порт платформы Mono на мобильные устройства, т.е. среда выполнения кода на С# и ее нельзя ставить в один ряд с Титаниум и Phonegap. У нас есть опыт работы с Ксамарин и мы обязательно поделимся, сейчас однозначно можем сказать, что есть довольно много сложнестей с тем, чтобы совместить MVC и MVVM Andriod и WinPhome 8 — т.е. по сути тот же if код получается.
Вот тут мы видимо уже переходим в плоскость философии и различных точек зрения на корпоративные порталы, обсуждать можно долго и приводить доводы на контордоводы, все же позволим себе прокомментировать:
1. С точки зрения внутреннего маркетинга, портал — это не только инструмент, а еще и способ создать красиво и донести до сотрудников информацию о корпоративной культуре, новостях и т.д. И тут важно, чтобы не 1 — 2 странички были «Вау», а все, и скорее удобны, просты и дружелюбны, а также соответствовали корпоративному брендбуку.
2. Научить можно кого угодно и чему угодно :) Только люди в компании меняются (особенно актуально для больших организаций). Просто, удобно и дружелюбно — значит не нужно учить каждый раз заново.
3. Каждая из описанных функций используется не очень часто, действительно, Вы правы. А есть еще архив документов, документооборот, новостные ленты и т.д., и если каждый из этих инструментов будет не очень удобный, то на вопрос времени посмотрим уже по-другому.
4. Про Exchange: мы не подменяли стандартную функциональность, а лишь ее расширили. Например, информацией об оборудовании в конференцзалах, это важно, когда для разных встреч нужны переговорки разной вместимости и укомплектованности — опять просто, удобно…
5. SSIS, который делает цикл по всем спискам, и скрытый список — и каждый раз при развертывании этого решения на новый узел, нужно подправить этот SSIS :) Технически решение понятно, но опять — не дружелюбно это.
6. Конечно какие-то вещи можно сделать и без портала, но в целом портал — это стратегический выбор, который позволяет решать на единой платформе много разных задач и реализовать документооборот (в статье про миграцию есть те части портала, которые без него реализовать дороже, чем с ним).
В нашем решение — простота, удобство, дружелюбность стоят во главу угла, и, наверное, есть ситуации, когда это важнее. Вот тут как раз и можно обсудить те ситуации, когда портал это простой стандартный инструмент, а когда нужно его брендировать и делать кастомным — все зависит от решаемых задач и целей.
Иногда ощущение сотрудника, что что-то сделали для него, чтобы ему было хорошо и удобно, дороже. Особенно для компаний, в которых человеческий капитал — это главное.
Спасибо Вам огромное за интерес к нашему посту, действительно, способов реализации функциональности существует много, предложенный Вами считаем рабочим — особенно, если необходимо быстро сделать и обкатать бизнес-процесс в жизни.
Есть НО:
— пользовательский интерфейс должен выглядеть просто и понятно, так, чтобы люди без особой подготовки могли с ним работать. с помощью кастомных форм мы решали именно задачу. Как Вы сами знаете, со стандартным UI SharePoint это не всегда просто
— у нас есть блок управления различными заявками, отпуска, переговорки и т.д… в этом и была суть всего решения — все нужно под рукой
В случае тиражирования одного и того же решения возникают вопросы, например, SSIS будет тоже тиражироваться для всех отделов, т.е. если 100, то будет 100 пакетов, и их придется администрировать, а что делать с обновлениями, когда оно настроено для каждого — опять руками для всех?
Как видите всегда есть свои за и против :) для нас в данном случае важным были простота и понятность UI в корпоративном стиле и снижение затрат на поддержку и обновления.
Признак уволен нужен потому, что Project Server так устроен, что даже если сотрудник уволен, то у него в таймщите в базе будут пустые строки, т.е. за какую бы дату не смотрел данные все равно будут. Нужно четко знать — он не заполнил или его уже нет и он не должен заполнять.
Фильтр по дате и так есть, как по фискальной, так и по реальным месяцам. Для старых сотрудников мы используем признак уволен он или нет, который стал свойством измерения аналитического куба — что более правильно: ставишь в одном месте флажок (в стандартных свойствах пользователя Project Server) и не нужно думать, за какую тебе дату отфильтровать, чтобы лишних данных не было.
Организация занимается разработкой программного обеспечения на заказ, планы работ составляют руководители проектов.
Полезность есть, так как это инструмент оперативного контроля, а спустя 3 — 4 месяца от старта проекта без оперативного контроля может получиться такой бардак в учете, что они будут уже не пригодны для анализа, т.е. это вопрос чистоты данных, а значит правильности принятия решений.
1) Да
2) Нет, не только
3) Да
4) Исторически изначально портал развивался с функционала, трогающего больше внутренних сотрудников, которые внутри домена. Для них не хотелось внедрять формы, так как виндовые логины у них уже были. А с кассирами как хлынуло много внешних пользователей, так и пришла идея их перевести в первую очередь
Вы, скорее всего, говорите о максимальном размере пула у ThreadPoolExecutor, экземпляр которого использует AsyncTask. Однако, запустить задачу в этом экзекуторе можно только методом task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, <остальные параметры>);
Если посмотреть исходники AsyncTask любой из последних версий android (например, тут grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.3_r2.1/android/os/AsyncTask.java), то можно заметить, что коммандой AsyncTask#execute(…) задача будет передана не в ThreadPoolExecutor, а в дефолтный SerialExecutor с одним потоком.
загрузка картинок — очень типовая операция в андроиде и, конечно, уже есть тысячи библиотек для загрузки картинок, но в статье помимо примеров с картинкой еще много чего про фоновые процессы :)
1. Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
MVVM Light и Caliburn.Micro библиотеки хорошие. Но под Windows Runtime вам понадобиться решить ряд проблем.
2. Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
В статье показаны возможные варианты.
3. Для этого есть более красивый EventToCommand behavior без засорения ViewModel
В этом случае в XAML получится больше кода. Разве это красиво? И в чём будет состоять засорение модели в нашем методе?
4. Это уже MVP а не MVVM
Для MVP не хватает P. Вызовы представления через дополнительный слой вполне легитимны. Главное, что нет зависимости между моделью и представлением.
5. Этот пункт видимо был удалён.
6. Для этого придумали Visual States + GoToState
А ещё придумали триггеры, только не реализовали их в Windows Runtime. Посмотрите на WPF.
Кроме того, для переключения Visual States нужно писать код. А с триггерами всё делается в XAML.
7. Опять же завязываетесь на View из ViewModel
О чём Вы? Модель абсолютно ничего про представление здесь не знает.
Но часто данные предлагается вводить в банковскую платежную веб-форму, которая используется не только внутри приложений, но и в браузере. А в этом случае нельзя контролировать, какие скриншоты маскировать, зато можно маскировать поля. Но это задача разработчиков платёжной формы.
Следовательно, если пользователь не установил пароль на телефоне, и злоумышленник получил физический доступ к нему, то защищать эти данные уже невозможно.
1. Если перевода для некоторой метки не будет найдено в словаре текущего выбранного языка, и для него не специфицирован язык-заместитель (см. ниже), то для перевода будет использована сама метка. В принципе, сама метка может выступать в качестве отображаемого текста. Метки поддерживают пробелы и некоторые спецсимволы. Это может быть любая строка, которая может быть ключом JSON.
2. Вариант Default text, к сожалению, не поддерживается, в качестве текста будет отображаться метка.
3. Что касается поиска в нескольких локалях:
Опять же, если перевода для некоторой метки не будет найдено в словаре текущего выбранного языка, и для него не специфицирован язык-заместитель (так называемый fallback language), то для перевода будет использована сама метка. Метка может быть произвольного вида, не обязательно в стиле “uppercased”. Таким образом, при желании, дефолтный язык можно отображать самими метками. Также можно задать язык по умолчанию вызовом .preferredLanguage('en').
1. С точки зрения внутреннего маркетинга, портал — это не только инструмент, а еще и способ создать красиво и донести до сотрудников информацию о корпоративной культуре, новостях и т.д. И тут важно, чтобы не 1 — 2 странички были «Вау», а все, и скорее удобны, просты и дружелюбны, а также соответствовали корпоративному брендбуку.
2. Научить можно кого угодно и чему угодно :) Только люди в компании меняются (особенно актуально для больших организаций). Просто, удобно и дружелюбно — значит не нужно учить каждый раз заново.
3. Каждая из описанных функций используется не очень часто, действительно, Вы правы. А есть еще архив документов, документооборот, новостные ленты и т.д., и если каждый из этих инструментов будет не очень удобный, то на вопрос времени посмотрим уже по-другому.
4. Про Exchange: мы не подменяли стандартную функциональность, а лишь ее расширили. Например, информацией об оборудовании в конференцзалах, это важно, когда для разных встреч нужны переговорки разной вместимости и укомплектованности — опять просто, удобно…
5. SSIS, который делает цикл по всем спискам, и скрытый список — и каждый раз при развертывании этого решения на новый узел, нужно подправить этот SSIS :) Технически решение понятно, но опять — не дружелюбно это.
6. Конечно какие-то вещи можно сделать и без портала, но в целом портал — это стратегический выбор, который позволяет решать на единой платформе много разных задач и реализовать документооборот (в статье про миграцию есть те части портала, которые без него реализовать дороже, чем с ним).
В нашем решение — простота, удобство, дружелюбность стоят во главу угла, и, наверное, есть ситуации, когда это важнее. Вот тут как раз и можно обсудить те ситуации, когда портал это простой стандартный инструмент, а когда нужно его брендировать и делать кастомным — все зависит от решаемых задач и целей.
Иногда ощущение сотрудника, что что-то сделали для него, чтобы ему было хорошо и удобно, дороже. Особенно для компаний, в которых человеческий капитал — это главное.
Есть НО:
— пользовательский интерфейс должен выглядеть просто и понятно, так, чтобы люди без особой подготовки могли с ним работать. с помощью кастомных форм мы решали именно задачу. Как Вы сами знаете, со стандартным UI SharePoint это не всегда просто
— у нас есть блок управления различными заявками, отпуска, переговорки и т.д… в этом и была суть всего решения — все нужно под рукой
— про права мы не стали писать. они есть, а реализованы примерно вот так — habrahabr.ru/company/eastbanctech/blog/211735/
В случае тиражирования одного и того же решения возникают вопросы, например, SSIS будет тоже тиражироваться для всех отделов, т.е. если 100, то будет 100 пакетов, и их придется администрировать, а что делать с обновлениями, когда оно настроено для каждого — опять руками для всех?
Как видите всегда есть свои за и против :) для нас в данном случае важным были простота и понятность UI в корпоративном стиле и снижение затрат на поддержку и обновления.
Организация занимается разработкой программного обеспечения на заказ, планы работ составляют руководители проектов.
Полезность есть, так как это инструмент оперативного контроля, а спустя 3 — 4 месяца от старта проекта без оперативного контроля может получиться такой бардак в учете, что они будут уже не пригодны для анализа, т.е. это вопрос чистоты данных, а значит правильности принятия решений.
В России еще не продается.
2) Нет, не только
3) Да
4) Исторически изначально портал развивался с функционала, трогающего больше внутренних сотрудников, которые внутри домена. Для них не хотелось внедрять формы, так как виндовые логины у них уже были. А с кассирами как хлынуло много внешних пользователей, так и пришла идея их перевести в первую очередь
Если посмотреть исходники AsyncTask любой из последних версий android (например, тут grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.3_r2.1/android/os/AsyncTask.java), то можно заметить, что коммандой AsyncTask#execute(…) задача будет передана не в ThreadPoolExecutor, а в дефолтный SerialExecutor с одним потоком.
уже идет разработка. примерно в конце августа опубликуем
MVVM Light и Caliburn.Micro библиотеки хорошие. Но под Windows Runtime вам понадобиться решить ряд проблем.
В статье показаны возможные варианты.
В этом случае в XAML получится больше кода. Разве это красиво? И в чём будет состоять засорение модели в нашем методе?
Для MVP не хватает P. Вызовы представления через дополнительный слой вполне легитимны. Главное, что нет зависимости между моделью и представлением.
5. Этот пункт видимо был удалён.
А ещё придумали триггеры, только не реализовали их в Windows Runtime. Посмотрите на WPF.
Кроме того, для переключения Visual States нужно писать код. А с триггерами всё делается в XAML.
О чём Вы? Модель абсолютно ничего про представление здесь не знает.