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

Часть 3. Создание новых элементов управления

Посредством присоединенных свойств (Attached Properties) и поведений (Behaviors) мы имеем возможность расширять существующие элементы управления без вмешательства в их внутренее устройство. Располагая же разметкой их шаблонов, мы также можем изменить их внешний вид и работу визуальных состояний (VisualState). Однако, если требуется изменить или расширить логику существующего элемента управления, или и вовсе создать новый элемент управления, то нам необходимо опуститься на уровень кода (ControlName.cs).

В компании Mutual Mobile тестирование является частью создания отличного программного обеспечения. Однако тестирование не всегда было ключевой частью при создании приложений под iOS. Когда мы начали искать способы, чтобы улучшить тестирование наших приложений, то обнаружили, что написание тестов для приложений это довольно сложно. И решили, что если мы собираемся улучшить способ тестирования программного обеспечение, то мы должны сначала придумать лучший способ спроектировать приложения, и это решение мы назвали VIPER.

Традиционным способом проектирования приложения под iOS является использование шаблона MVC (модель-представление-контроллер). Использование MVC для архитектуры приложения, может натолкнуть Вас на мысль, что каждый класс представляет собой модель, или представление, или контроллер. Поскольку значительная часть логики приложения не входит в модель или представление, она обычно оказывается в контроллере. Это приводит к проблеме, известной как Massive View Controllers, где контроллеры в конечном итоге делают слишком много. Если вся логика встроена в контроллер представления, это приводит к тестированию логики через UI, в свою очередь это является неправильным способом проектированиям логики. Также проще совмещать бизнес-логику и UI код в том же методе. Когда Вам будет нужно добавить новые функциональные возможности или исправить ошибку, то будет трудно определить, где внести изменение и при этом быть уверенным, что не будет непредсказуемых последствий в другом месте.

Социальные сети, и особенно Facebook, уже давно используются в мобильных приложениях. Сегодня мы рассмотрим, как подключить нативные Facebook SDK к проекту на базе Xamarin.Forms (iOS и Android) для удобной авторизации пользователей и получения о них базовой информации. Вы также легко сможете расширить описанные в статье методы для того, чтобы реализовать полноценное взаимодействие с этим замечательным сервисом. Тема простая и понятная, поэтому без теорий и прелюдий перейдем сразу к практике.

Постараюсь коротко, но понятно, рассказать самое интересное о Xamarin. Самые основные концепты, которые необходимо знать UWP и WPF разработчикам, чтобы с места в карьер начать работать с Xamarin.Forms.

Сегодня мы представляем материал от наших давних партнеров, компании Music Paradise, которые, как вы помните, уже делились с Хабром секретами создания музыкальных приложений в нашей совместной статье «Внедрение социальных сервисов в неигровое приложение». На этот раз специалисты из команды расскажут о специфике реализации базовых функций утилиты Audio Editor, изначально написанной для iOS и Mac устройств, на новой платформе — Windows — и о том методе, который они применяли при адаптации.



«В этой статье мы рассмотрим один из самых доступных способов получения аудиоданных из файла. Извлечение аудиоданных является краеугольным камнем для всех разработчиков, которые делают первые шаги в работе со звуком, однако внимания ей уделяется на удивление мало. Проблема ощущается особенно остро при попытках найти готовые решения или инструкции для UWP в интернете: в большинстве случаев ответа не получаешь вообще или же приходится довольствоваться устаревшими решениями. Между тем, при работе со звуком извлечение данных имеет значимый смысл, давая разработчику возможность редактировать данные: копировать, добавлять, изменять, путем наложения эффектов, визуализировать их на экране пользователя. Именно о визуализации сегодня и пойдет речь. Несмотря на существование специальных библиотек для работы с аудиоданными в галерее NuGet, мы построим логику приложения на самостоятельной обработке байтов аудиофайла. Таким образом, в процессе мы узнаем больше о структуре wav-файла и убедимся на практике, что работа с аудио данными — это не так уж сложно.

При работе с платформой Android я столкнулся со множеством проблем, потому что проектировал свои Модели неправильно. Мои приложения были недостаточно реактивными. Теперь используя RxJava и Model-View-Intent (MVI) я, наконец, добился нужного уровня реактивности. Об этом я пишу цикл статей. В первой части расскажу о модели и объясню, чем она важна.

Представляем вам пятничную подборку полезных гайдов и шпаргалок от Джеймса Монтемагно для разработчиков разного уровня.

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

В данном материале можно будет увидеть различные инструменты и подсказки, которые здорово облегчают жизнь Android разработчикам. Большая часть собрана напрямую от знакомых разработчиков и содержит вещи, которые должен знать каждый. Дополнения и расширения приветствуются, и если вы знаете о каком-то крутом механизме, который не был упомянут в статье, не поленитесь перейти в оригинал и открыть pull request.

Знакомьтесь: Win2D это легкое в использование Windows Runtime API для более удобного использования возможностей DirectX. Прорисовка графики осуществляется с ускорением GPU. Win2D доступно для разработчиков C#, C++ и VB и в Windows 8.1 и в Windows 10.

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

Предлагаю рассмотреть на примерах основной функционал библиотеки.

Здравствуйте! Однажды, задумавшись о безопасности своего автомобиля, я прошелестел достаточно много ресурсов с информацией об автомобильных противоугонных системах в том числе и с GPS. Но все было либо не то, что нужно, либо достаточно дорого, да и сопутствующие сервисы мне особым функционалом не нравились, да и признаться есть доля паранойи во мне. В общем, главной отпугивающей причиной для меня стало — делить с кем-то информацию о своем местоположении. В итоге была куплена обычная сигнализация с авто запуском и обратной связью, но речь сейчас немного о другом.

Все же мысли о сохранении информации о положении авто у меня крутились в голове, да и хотелось просто найти интересное занять на досуг. НА этих мыслях я решился на покупку т. н. персонального GPS — трекера. Особо к моделям не присматривался, у все примерно одно и тоже, но очень важной особенностью такой как настройка на собственный сервер обладали не многие из перебранных кандидатов. В итоге мой выбор пал на персональный GPS трекер китайской компании Xexun — Xexun TK102-2. После еще нескольких часов выискивания как все настраивается и кучи различных мануалов я решил, что нужно уже купить и посмотреть что это такое. Кому интересна информация о трекере и о написании собственного «сервера» для трекера, прошу подкат.

Ключевое противоречие ООП

Как известно, классическое ООП покоится на трех китах:

1. Инкапсуляция
2. Наследование
3. Полиморфизм

Классическая же реализация по умолчанию:

1. Инкапсуляция — публичные и приватные члены класса
2. Наследование — реализация функционала за счет расширения одного класса-предка, защищенные члены класса.
3. Полиморфизм — виртуальные методы класса-предка.

Но еще в 1986 году была обозначена серьезнейшая проблема, кратко формулируемая так:

Наследование ломает инкапсуляцию

Делимся полезным контентом по разработке на Xamarin: видео The Xamarin Show на Channel 9, базовый курс Microsoft Virtual Academy для новичков, список обучающих материалов и первый в России Moscow Xamarin Meetup.

Не так давно мы работали над диагностикой, связанной с проверкой финализатора, и у нас с коллегой возник спор по поводу деталей работы сборщика мусора и финализации объектов. И хотя я и он занимаемся разработкой на C# более 5 лет, к общему мнению мы не пришли, и я решил изучить этот вопрос подробнее.

Да-да, вы все правильно поняли, это статья об еще одном велосипеде — о моем Dependency Injection (DI) контейнере. За окном уже 2015-ый год, и самых разных контейнеров на любой вкус и цвет полным полно. Зачем может понадобиться еще один?

Во-первых, он может просто образоваться сам собой! Мы в Эльбе довольно долго использовали этот контейнер, и некоторые из описываемых в статье идей (Factory Injection, Generics Inferring, Configurators) изначально были реализованы поверх него через публичное API.

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

В-третьих, DI-контейнер — относительно простая штука. Он очень хорошо поддается разработке в режиме TDD, за счет чего делать его становится весело и приятно.

Эта статья — не введение в DI. На эту тему есть много других прекрасных публикаций, в том числе и на Хабре. Скорее здесь собран набор рецептов приготовления DI так, чтобы получившееся блюдо было вкусным, но не острым. Если у вас DI-контейнер в продакшене или вы написали свой собственный самый лучший контейнер, то здесь отличное место для холиваров о том, чей контейнер круче!

Коль захотел ты сборки передать
И с ними пламенный привет
Нугетом не забудь запаковать
В пакет!

Сразу оговоримся, что в этой статье речь пойдёт о стеке технологий Microsoft .NET.

Часто так бывает, что какое-то подмножество проектов начинает использоваться в разных решениях.

Как правило, программисты, разглядев в соседнем проекте что-то полезное, первое время не заморачиваются — создают папку lib (dll, assemblies и т.п.) и складывают туда скомпилированные сборки из оригинального решения. Со временем становится понятно, что это не самый удобный вариант и вот почему:

• оригинальное решение начинает развиваться в свою собственную сторону, без учёта «потребителей»: добавляются новые зависимости, обновляются версии .net и т.п. «приколы»;
• если даже о «потребителях» задумываются, то забывают обновить сборки у них, когда выходит критическое обновление или просто новая версия, а потом всё становится ещё хуже, когда сборок становится больше одной и между ними возникают некоторые зависимости — обновляя одну сборку, получаем проблемы в момент исполнения, т.к. другая сборка может оказаться не той версии;
• оригинальное решение перестаёт дальше разрабатываться.

Ответом на все эти неприятности может служить вынесение проектов в отдельное решение и создание NuGet-пакета, включающего общие сборки, и смена парадигмы развития этих сборок. По большому счёту, всё это можно сделать и без NuGet, но удовольствия в этом гораздо меньше.Как сделать так, чтобы NuGet-пакет собирался сам автоматически вместе с компиляцией проекта на сервере построения и включал все необходимые свистелки и гуделки — об этом и будет наш рассказ.

В своих C# проектах при реализации GUI я часто использую фреймворк ReactiveUI.

ReactiveUI — полноценный MVVM-фреймворк: bindings, routing, message bus, commands и прочие слова, которые есть в описании почти любого MVVM-фреймворка, есть и тут. Применяться он может практически везде, где есть .NET: WPF, Windows Forms, UWP, Windows Phone 8, Windows Store, Xamarin.

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

Друзья! Очередная статья на тему разработки мобильных приложений на Xamarin. Мы не прекращаем рассматривать особенности использования Xamarin.Forms при разработке бизнес-приложений для iOS и Android. Все статьи из колонки можно найти и прочитать по ссылке #xamarincolumn

В прошлой статье мы рассмотрели, как можно повысить продуктивность при разработке мобильных приложений с использованием Xamarin, а также отметили базовые механизмы повышения производительности бизнес-приложений на базе Xamarin.Forms.

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

Что такое бизнес-приложения?

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

Часто с началом нового проекта программист не в состоянии увидеть полную картину — он не знает с чего начать, где получить информацию, сколько ее получить, при этом есть шанс засесть за документацией надолго пока не пропадет желание что-либо делать. Я относительно часто делаю проекты «для души» в ранее незнакомых областях, например, программировал микроконтроллеры, делал свой segway, проектировал на ПЛИС свой микропроцессор, делал плагины под Counter-Strike, софт к купюроприемникам и другие проекты, в которых на старте был абсолютным нулем.

Тег-хэлперы (Tag Helpers) – новая функция MVC, которую удобно использовать для генерации HTML кода. Они выглядят как обычные HTML элементы и атрибуты, но обрабатываются движком Razor на стороне сервера. Тег-хэлперы во многом представляют собой альтернативный синтаксис для HTML Helpers, но также они позволяют сделать то, что было трудно или невозможно сделать с помощью HTML Helpers. У каждого тег-хэлпера свое поведение и возможности. Эта статья рассмотрит базовые тег-хэлперы, существующие в MVC 6 (ASP .NET Core 1.0, как стало известно совсем недавно).