50 советов для разработки безупречного дизайна iOS приложения. Разработка под ios на windows
Руководство React Native — создаем приложение под iOS. Часть 1.1 / Хабр
Идея создавать мобильные приложения на JS не нова. Мы видели, что фреймворки, такие как Ionic или PhoneGap, справляются с этой задачей и привлекли изрядное количество разработчиков.
Тем не менее ни эти фреймворки, ни идея создавать мобильные приложения на JavaScript никогда не привлекали меня. Я всегда думал, почему бы не изучить Swift/Objective-C или Java и просто делать настоящие приложения? Конечно, это потребует затраты значительных усилий на обучение, но разве непрерывное обучение — это не то, что мы, разработчики, делаем и должны делать хорошо? Быстро изучать новые языки и фреймворки? Тогда в чём смысл? Что касается меня, очевидные преимущества такого подхода никогда не перевешивали сомнения. Пока я не прочитал статью Chalk + Chisel, в которой обратил внимание на следующее:
Я думал, что React Native — это всего лишь маленький эксперимент. И считал, что настоящее нативное приложение все еще должно писаться на нативных языках. Если бы перемотать время на пару месяцев вперед, я мог бы уверенно сказать, что я никогда больше не буду писать под iOS на Objective-C или Swift. Что! Вы это… серьёзно?Какое приложение мы будем создавать?
Я никогда не мог найти нормальное приложение для поиска обоев для моего iPhone в App store. На десктопе Unsplash — это все что нужно, чтобы удовлетворить все мои потребности. На телефоне же: Настройки → Обои :(Таким образом, в отличие от других руководств, где вы создаёте никому ненужные «Hello World!» счетчики, в этом мы вместе сделаем приложение, которое сможет загружать случайные фото из Unsplash, показывать их в эстетически привлекательном виде и даст возможность сохранять из в Camera Roll (по-видимому аналог «Галереи» в Android, хотя там еще какое-то My Photo Stream есть — прим. переводчика). Это приложение понравилось мне больше, чем я думал. Поэтому, даже если в конце этого руководства, вы не будете впечатлены React Native, у вас останется крутое приложения для поиска и сохранения обоев. Разве это не здорово?
Перед тем, как начнём, перечислю то, с чем вы уже должны быть знакомы на этот момент:
- JavaScript
- Некоторые особенности ES2015, такие как классы, стрелочные функции, деструктуризация и шаблоны-строки(${name}) (на русском)
- Mac OS X командная строка (терминал)
- CSS (неожиданно!)
- React (необязательно)
Ремарка
К концу этого руководства, вы будете достаточно хорошо знакомы с React Native, чтобы писать свои приложения. Мы рассмотрим настройку проекта в Xcode, установку сторонних модулей и компонентов, импортирование библиотек, стилизацию приложения с помощью flexbox, создание настраиваемых обработчиков жестов и другие вещи.Для вашего удобства руководство разбито на две части. Каждая часть состоит из пяти разделов. В каждом разделе мы двигаемся на один шаг ближе к нашей цели. Я рекомендую вам, если вы начали, заканчивать задание в каждом начатом разделе, поскольку они короткие, чтобы понимать общую концепцию на каждом этапе и не терять концентрации.
Исходный код приложения можно посмотреть на репозитории GitHub.
1. Создание пустого проекта React Native
Убедитесь, что у вас установлен Xcode версии 7.0 или выше. Его можно скачать бесплатно из App Store. Скорее всего (если вы являетесь веб-разработчиком и читаете это в 2016) у вас уже установлен Node. Если нет, установите его. Другой важный инструмент, который надо установить — это npm (node package manager — менеджер пакетов для Node — прим. переводчика). Node идет с предустановленным npm, вам надо обновить его, поскольку обновления выходят достаточно часто. Следуйте инструкции.Если всё это кажется вам непонятным или вы не можете выполнить какой-то шаг, вам поможет официальная документация (также моя небольшая заметка по поводу запуска android studio под window7 с процессорами amd — прим. переводчика).
Перейдите в папку, где у вас хранятся проекты через командную строку и наберите в терминале react-native init SplashWalls.
Эта команда загрузит все необходимые модули в новой папке, под названием SplashWalls.
Содержимое папки SplashWalls
Одной из замечательных особенностей React Native является то, что вы пишете приложение под Android и iOS, используя JS, большая часть которого используется в обоих приложениях. В директории есть два файла index.android.js, index.ios.js, названия которых говорят сами за себя. Для разработки под конкретную платформу, вам надо менять соответствующий файл или оба, если вы разрабатываете под обе платформы.
Поскольку мы разрабатываем приложение iOS, мы удалим файл index.android.js и соответствующую папку. Мы будем работать с файлом index.ios.js. Этот файл запускается первым, когда вы запускаете ваше приложение.
Затем перейдите в папку ios и запустите файл SplashWalls.xcodeproj. В Xcode вы увидите следующее всплывающее окно:
Обратите внимание на предупреждение, которое мы видим на скриншоте: «Не найдено совпадающих профилей». Давайте исправим это.
Сначала измените текст в поле Bundle Identifier. Вы должны убедиться в том, что вводимое вами имя соответствует обратной DNS нотификации(зона_домена.название_домена.название_пакета, пример adobe.com > com.adobe.package — прим. переводчика). Это соглашение позволяет различать ваше приложение на App Store. Я буду использовать com.nashvail.me.tutorial.SplashWalls.
Далее выберите ваше имя в списке:
Кликните на Fix Issue.
Пока мы здесь, обратите внимание на пункт Deployment Info. Нам надо кое-что изменить здесь:Измените настройки следующим образом:
Мы создаём приложение только для портретного вида и прячем статус-бар. Поднимитесь наверх и нажмите кнопку Run в левом верхнем углу Xcode. Это приведет к вызову окна терминала, как показано на скриншоте ниже. Это может занять некоторое время.
По завершении вы должны получить следующий результат в эмуляторе мобильного устройства:
На этом мы закончим с разделом 1 и перейдём к следующему.
Продолжение тут.habr.com
Как скомпилировать билд Unity3D проекта для IOS на Windows? / Хабр
Билд для IOS всегда стоял особняком в Unity3D. Если все остальные можно было компилировать на Windows машинах, то для IOS обязательно нужен был Мак. Я как и все столкнулся с этой проблемой при попытке выпустить свой первый проект на IOS, которая казалась мне трудно преодолимой. Однако, совсем недавно произошло два события которые делают эту проблему практически неактуальной, и которые прошли на Хабре незамеченными.Как было до этого?
Раньше чтобы скомпилировать проект необходимо было:- установить Unity3D на Мак или Хакинтош;
- скопировать туда свой проект с Windows;
- скомпилировать из него проект для Xcode;
- открыть полученный проект в Xcode и упаковать его в ipa файл;
- отправить тестерам или в Appstore.
Соответственно, проблемы синхронизации проектов между Windows и Mac версиями Unity3D давали о себе знать и для комфортной работы необходимо было покупать б/у Мак или мучиться с виртуальными машинами.
Кстати, к своему стыду установить хакинтош на VirtualBox у меня так толком и не получилось.
Что же такого произошло, что кардинально изменило ситуацию?
Новый Хакинтош!!!
Не знаю почему, но тема Хакинтоша не поднималась на Хабре уже пару лет. Рутрекер нас тоже особо не балует, но пару недель назад там появился готовый образ Хакинтоша для VMware причём для последней версии 10.9 Маверик. Всё работает на VMware Workstation 10.x, что называется прямо из коробки и без всяких проблем. Ссылки не даю, кому надо тот и сам легко найдёт.Unity3D 4.3
Хотя недавно была небольшая статья с обзором новой версии Unity3D, но в ней никто не обратил внимание на ключевое нововведение:Ability to build iOS target in Windows! It's still necessary to compile resulting Xcode project on a Mac.Да-да!!! Теперь файлы для Xcode можно компилировать прямо в Windows версии!!! Соответственно про пункты 1, 2 и 3 можно теперь забыть. Т.е. теперь почти всю работу с проектом можно выполнять в Windows, а Мак нужен лишь для упаковки проекта, которая занимает по времени несколько минут, и для которой достаточно виртуальной машины с Хакинтошем!!!
Краткое руководство для тех, кто этим раньше не занимался
Для компиляции рабочего билда и запуске его на своём устройстве необходимо всего три вещи:- Unity3D 4.3 — для компиляции Xcode проекта
- Mac OS X с установленным Xcode — для упаковки Xcode проекта в ipa файл
- Аккаунт IOS разработчика — для создания сертификатов и провижин профайла, необходимого для подписи ipa файла
В настройках проекта вводите Bundle ID, который вы указали при создании провижин профайла.
Билдите проект.
Полученные файлы переносите на Мак машину и открываете с помощью Xcode.
Архивируете проект Product->Archive.
Для подготовки архива для распространения нажимаете на Distribute.
Если вы ещё не готовы отправлять приложение в Appstore, то выбираем 2-й пункт.
Выбираете свой провижин профайл и жмёте Export.
После чего указываете куда сохранять файл.
После чего генерируется долгожданный ipa файл.
Теперь можете устанавливать его на свои устройства через свой Itunes или Testflight.
habr.com
Обзор кросс-платформенных решений для разработки мобильных приложений / Хабр
В этой статье мы сравним 6 решений для кросс-платформенной разработки, которые были популярны в 2016 году и попытаемся найти лучшее решение.Кросс-платформенные фреймворки PhoneGap, Xamarin, Unity, Qt и Appcelerator Titanium, Telerik Platform на сегодняшний день занимают 80% рынка кросс-платформенной разработки для мобильных устройств.
В таблице ниже представлены основные характеристики для каждого фреймворка:
| PhoneGap | Xamarin | Unity | Qt | Appcelerator Titanium | Telerik AppBuilder | |
| Языки | JavaScript, HTML5, CSS3 и нативные языки (Java, Objective-C, C#) | C#, Xaml | C#, UnityScript, Boo | C++ QML | JavaScript, Python, Ruby, PHP | .Net, JavaScript, HTML5, Java, PHP |
| Поддерживаемые латформы | Android, iOS, Windows Phone, Blackberry, WebOS, Symbian, Bada, Ubuntu, Firefox OS. | iOS, Android, Windows Phone and Windows 8/RT, Tizen | Android, iOS, Windows Phone, Tizen, PS 4, Xbox One | Android, iOS, WinRT, Windows, Symbian, Linux, QNX | iOS, Android, BlackBerry, Windows, Tizen, Denso | iOS, Android, BlackBerry, Windows, Windows Phone |
| Цены | Цены PhoneGap Платная версия: от 9.99$ Бесплатная версия: доступна Adobe Creative Cloud Membership: доступно |
Цены
Xamarin Xamarin Studio Community: бесплатно Visual Studio Community: бесплатно Visual Studio Professional: доступно Visual Studio Enterprise: доступно |
Цены
Unity Personal Edition: бесплатно Professional Edition: от 75 $ в месяц |
Цены
Qt Есть бесплатная версия. Платные версии начинаются от 79$. |
Цены
Appcelerator Есть бесплатный пробный период Indie: 39$ в месяц Pro: $99 в месяц |
Цены
Telerik AppBuilder Есть бесплатный пробный период Цена от 39$ в месяц |
| Open source | + | - | - | + | + | - |
| UI | Web | Native | UI Canvas | Native | Native | Web |
PhoneGap Build позволяет делать сборки для iOS, Android и Windows Phone одновременно, без необходимости устанавливать какие-либо SDK tools (конечно, в этом есть доля лукавства – при разработке всё равно лучше делать сборку локально, хотя бы на Android, перед отправкой на тестирование). Но что более важно, этот сервис позволяет делать сборки для iOS в облаке без наличия Mac.
Установка PhoneGap требует неимоверных усилий, потому советую освободить пол дня… Шутка. Установка для XCode заняла минуты 3 — заключалась в скачивании архива, распаковке и установке. Вот собственно и все.
PhoneGap представляет возможность использовать нативные функции мобильного устройства по работе с:
- акселерометром,
- камерой,
- компасом,
- контактами,
- файловым хранилищем,
- геолокацией,
- базой данных,
- событиями, уведомлениями,
- медия и др.
Преимущества:
- PhoneGap имеет простое API, что позволит легко начать разработку, для тех кто сталкивался с HTML, CSS и JavaScript.
- Возможность использования любых существующих JavaScript библиотек (JQuery, Prototype, Sencha Touch)
- Поддержка всех мобильных платформ
- Пользовательский интерфейс визуализируется с помощью встроенного браузера. Это создает трудности в получении обратной связи по сравнению с нативным приложением.
- Часто существующие плагины оказываются устаревшими, поэтому иногда придется писать свои.
Функционально платформа Xamarin представляет ряд субплатформ. Эти субплатформы играют большую роль — через них приложения могут направлять запросы к прикладным интерфейсам на устройствах. Определяется визуальный интерфейс, привязывается логика на C#, и все это будет работать на Android, iOS и Windows Phone. Видео с разработкой приложения на Xamarin.
Преимущества:
- Большое и развивающееся сообщество.
- Разработчики могут использовать TestCloud для тестирования приложений автоматически.
- Если вы уже знакомы с C# и .NET то вам не нужно будет тратить много времени на изучение нескольких новых фреймворков.
- Можно повторно использовать уже написанный код.
- Приложения под разными системами будут выглядеть очень похоже.
- Динамическая верстка для iOS в бесконечное число раз проще, чем использование constraints вручную.
- За счет CustomRenderer‘ов стандартные контролы легко дополняются произвольными свойствами (например, сделать градиентную заливку кнопок — дело пары минут, хотя «из коробки» это не работает).
Недостатки:
- Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.
- Возникают проблемы со стороны платформы mono, monotouch и monodroid. Ваше приложение должно удовлетворять особенным требованиям стабильности.
- Android страницы невозможно расположить как часть уже существующего Activity/Fragment.
- Реализованы не все контролы.
Возможность создавать iOS приложения работая на Windows или Linux еще одно преимущество.
И напоследок, принадлежность AppBuilder к Telerik Platform дает вам возможность пользоваться такими фичами как аналитика, всплывающие уведомления, авторизация пользователей и облачным хранилищем. Подробное описание в статье и видео.
Преимущества:
- Telerik предоставляет плагины Visual Studio и Sublime Text для AppBuilder.
- AppBuilder предлагает быстрый способ импорта плагинов Cordova.
- Полноценная онлайн IDE.
- Легок в использовании и изучении
Недостатки:
- Небольшое сообщество
Преимущества:
- Отличный вариант для создания мобильных игр для целого ряда устройств
- 3D-движок дает высококачественные результаты без каких-либо сложных конфигураций
- Есть много хороших бесплатных плагинов
- Unity позволяет разработчику сделать свои собственные шейдеры и изменить путь, которым Unity визуализирует игру.
Недостатки:
- UI и сложность в использовании для новичков
- Исходный код недоступен
- Компиляторы Unity не оптимизированы для ARM процессоров на некоторых мобильных устройствах.
- Qt имеет множество хороших инструментов которые помогут в разработке, например: IDE QT Creator, Qt Designer и code profiling.
- Он имеет библиотеки, содержащие интуитивно понятные API интерфейсы для элементов, таких как сети, анимации и многое другое.
Недостатки:
- Qt сложен для начинающих
Вы можете создавать современные, а главное — нативные приложения, используя любую популярную на сегодняшний день операционную систему: Windows, GNU/Linux или MacOS X.
Приложения созданные с помощью данного SDK будут действительно нативными. Контроллер навигации на Андроиде будет выглядеть привычно и не так как на iOs. Причем не только вид, но и сам код приложения будет тоже нативный. Это кстати не мешает вам создавать и классический WebView и наполнить его желаемым web контентом.
Преимущества:
- JavaScript позволяет легко разрабатывать приложения без использования языков платформы.
- Appcelerator позволяет делать аналитику в режиме реального времени
- Использование native API даст более высокую производительность для приложений, которые не очень велики.
Недостатки:
- Есть задержки при запуске приложения из-за загрузки библиотеки
- Трудно создавать сложные приложения, так как использование JavaScript отрицательно сказывается на производительности приложений.
Технология очень перспективная, но молодая, поэтому платформа кое-где еще сырая. Версия для Android появилась позже, поэтому для iOS-приложений пока есть больше компонентов. Также стоит учитывать, что при разворачивании приложения на устройство пользователя попадет весь JS, поэтому на уровне презентации не стоит держать секретную бизнес-логику. Можно сказать, что сейчас React Native можно использовать для быстрого прототипирования мобильных версий ваших веб приложений. Причем если веб приложение уже написано на ReactJS, то скорость переноса возрастает в разы. Пример разработки на React Native.
Преимущества:
- Единый воркфлоу и инструменты: неважно, работаете ли вы на Android- или iOS-версией — все равно используете одни инструменты.
- По этой причине — скорость и простота разработки.
- Обвязка унаследованного приложения в JS API и гибридные приложения: допустим, у вас уже есть готовое приложение для iOS, и вы хотите перейти на React Native. Тогда можно обернуть нативные компоненты так, чтобы они были доступны в React Native. Так вы можете постепенно переходить на React, и получается гибридное приложение — половина его нативная, а половина — в React, и несколько унаследованных компонентов — в JS API.
habr.com
50 советов для разработки безупречного дизайна iOS приложения / Хабр
Привожу перевод статьи Ника Карсона. В статье собраны вместе, как мне кажется, основные правила построения интерфейса для iOS приложений.1. Возможно, сенсорное управление отличается гибкостью и интуитивностью, но оно далеко не совершенно. Подумайте, чем люди занимаются, когда используют ваше приложение, и как они держат устройство. Помните, что пальцы покрывают гораздо большую площадь, чем кажется, и их точность оставляет желать лучшего.
2. Ориентируйтесь на устройство при создании приложений: учтите не только размер экрана, но и где и когда устройство используется. Больше всего iPad используется для развлечений между 8-11 часами вечера, перед сном, тогда как iPhone — в очереди на автобус или в кофейне. Учтите различные сценарии использования при разработке приложений – включая и то, как далеко устройство расположено от лица пользователя.
3. Рассматривайте ваше приложение поэкранно. Определите, каковы основные задачи, которые достигаются при использовании данного активного экрана, и затем сделайте так, чтобы пользователь мог решить их, используя минимальное количество дополнительных опций, кнопок и других элементов управления. Избегайте слишком большой функциональной нагрузки на активный экран, в особенности на мобильных устройствах.
4. Разработка программ для мобильных телефонов или планшетов значительно отличается от разработки веб-приложений и даже приложений для стандартного рабочего стола, — каждый элемент занимает на экране определенное место, и это правило необходимо неукоснительно соблюдать. Рассматривайте это скорее как преимущество, чем ограничение: фиксированные шаблоны помогут лучше контролировать размер и расположение каждого элемента, видимого пользователю.
5. При адаптации приложения к экранам различных размеров, помните, что при значительном его изменении – например, от iPhone к iPad – способ использования устройства также изменится. Если размеры ограничены, используйте основные функции приложения, при их увеличении – можно включить любые дополнительные функции, которые не вошли в более сжатую версию, так как у вас появляется возможность обыграть дополнительное пространство.
За остальными 45-ю — добро пожаловать подкат. 6. Секрет создания хорошей иконки для приложения – отразить основную идею: очевидные функции вашего приложения, но в визуально привлекающей форме. Пользователи iOS порой очень тщательно подходят к выбору иконок для рабочего стола. Не жалейте времени, чтобы создать иконки всех возможных размеров, чтобы они хорошо смотрелись на экране любого устройства, включая миниатюрный вариант, используемый в меню «Настройки» пользователя.
7. Палец больше и менее точен, чем мышь, поэтому область нажатия на сенсорном экране должна иметь значительную погрешность. Чтобы упростить задачу: никогда не располагайте слишком много элементов управления в одной области экрана или слишком близко друг к другу, и убедитесь, что кнопки достаточно велики для точного нажатия. Apple рекомендует размер не менее 44x44.
8. Постарайтесь при разработке изначально ограничить основные функции вашего приложения, и по возможности не отклоняйтесь от первоначальной идеи. Таким образом, вы сможете развить и улучшить концепцию приложения, а также его внешний вид и интерфейс, не создавая путаницы добавлением новых переменных.
9. При разработке приложений для iOS, обратите внимание на систему обозначений Apple: у них богатый опыт разработки пользовательского интерфейса. Изменение стиля одного из элементов управления, чтобы улучшить вид и атмосферу вашего приложения это одно, но никогда не меняйте функции – это только спутает пользователей, которые привыкли к стандартным приложениям OS. К примеру, красные кнопки используются для удаления объектов, а синие – для выполнения действий.
10. Лучшие интерфейсы приложений обычно просты и интуитивны. Они кажутся пользователям очень понятными, и они могут чувствовать себя как дома. Главная задача разработчиков создать потрясающий визуальный эффект, чтобы пользователи были очарованы приложением, и при этом смогли бы использовать его, не читая никаких инструкций.
11. Начните разработку с планирования базовой структуры и затем добавляйте основные функциональные блоки. Самый легкий способ сделать это – нарисовать структурную схему приложения, а затем соединить все активные экраны и точки. Попросите постороннего человека посмотреть ваши наброски и оценить, удобно ли использовать предлагаемые функции.
12. При выборе внешнего вида и атмосферы приложения, соберите в помощь вдохновляющие материалы – например, составьте мудборд. Будет ли это нейтрально дружественный интерфейс или изображение реально существующих материалов таких как кожа, камень или металл? Экспериментируйте с различными комбинациями и цветовыми сочетаниями: в этом может помочь Adobe Kuler.
13. Размеры рабочей области iOS могут варьироваться от 1024x768 (iPad) до 640x960 (iPhone 4 и 4S) и 320x480 (iPhone 3GS). Часто приходится вставлять текст описания в дополнение к простым иконкам, чтобы вместить всю необходимую информацию в маленький экран. Это прекрасный способ разработать особый визуальный язык общения для ваших приложений, благодаря которому ясно какие функции выполняют иконки.
14. Можно легко адаптировать размер изображения для другого размера экрана, если создавать все графические элементы в Illustrator в форме векторов, а затем импортировать их в Photoshop, где вы можете легко подогнать их под конкретные размеры экрана и разрешение, дорабатывая и упрощая, где это необходимо.
15. Поработайте над набросками дизайна и функционалом на бумаге, используя в качестве образца доступные шаблоны iPhone или iPad. Когда вы уже готовы перевести дизайн на новый уровень, такие инструменты как LucidChart помогут вам создать функциональный макет приложения, чтобы далее перенести его в Photoshop для окончательной доработки внешнего вида приложения.
16. Рекомендации Apple по разработке дизайна интерфейса незаменимы для достижения совместимости с платформой, но некоторые правила нужно нарушить, если того требуют обстоятельства. Некоторые приложения — например, Flipboard, Twitter или Instagram — полностью отличаются от стандартных пользовательских ожиданий – поэтому не бойтесь выйти за рамки условностей.
17. При разработке приложения для iPad и iPhone, всегда начинайте с большего экрана и затем уменьшайте масштаб, упрощая изображение. Зачастую, при сохранении общей концепции, необходимо переосмыслить некоторые элементы интерфейса, например, рассмотреть ландшафтный и портретный режимы, чтобы включить в них различные виды и функции. Простое изменение масштаба интерфейса обычно неэффективно, поэтому потратьте время на поиск лучшего подхода.
18. При разработке приложений, функционирующих в реальном времени – таких как игры – решающее значение имеет разработка ключевых элементов достаточно крупного размера, чтобы пользователи могли легко и быстро их выбирать. В фазе тестирования найдите пользователя с относительно крупными руками: это самый эффективный способ выяснить соответствуют ли элементы требованиям и достаточно ли они велики.
19. Одно из ключевых решений, принимаемых разработчиком приложения – определение степени настраиваемости приложения относительно базовых установок. На каждом этапе задавайте себе этот вопрос, и всегда отслеживайте, что является самым важным в каждом конкретном контексте. Для функционала, например, панели общих настроек, базовые установки обычно лучшее решение.
20. Изучите как ваше приложение адаптируется к ландшафтному и портретному режимам. Может быть для отдельных элементов требуется больше или меньше места при смене ориентации, или нужно добавить какие-то другие опции или функции? Здесь пригодится возможность показывать и скрывать какие-либо элементы.
21. Как уже упоминалось, иконка дает пользователям первое впечатление о вашем приложении: если она выглядит непродуманной или непривлекательной, приложение не примут всерьез. Вы можете провести поиск по App Store и сравнить ее с другими иконками данной категории приложений. Хороший способ оценить, как выглядит иконка вашего приложения, поместить ее на экран среди других.
22. При разработке приложений форма всегда должна следовать за функционалом. Всегда существует бесконечное количество вариантов воплощения задачи с точки зрения внешнего вида и атмосферы, но при этом в первую очередь необходимо четко представлять себе цель создания приложения, еще до того, как вы будете заниматься его внешним видом и определением целевой аудитории. Естественно, что разные аудитории предпочтут различные стили – к примеру, приложения для бизнеса не должно быть исполнено в мультяшной манере.
23. Так как приложение со временем развивается, задайтесь целью добавить функции без излишнего усложнения – этот процесс известен под названием «наслоение функционала». Начните с четко определенной каркасной структуры, информационной архитектуры и схем взаимодействия, и будьте последовательны – это позволит добавить дополнительные функции без изменения концепции приложения.
24. Внимательно отнеситесь к разработке иконки. Это главный позиционирующий элемент – он должен не в точности отражать функционал вашего приложения, а наводить на мысль о профессионализме, и его цветовая схема, форма или изображение должны соответствовать интерфейсу самого приложения. У пользователя не должно быть диссонанса между внешним видом иконки и самим приложением.
25. Супер совет — Качественный дизайн прекрасно можно адаптировать под другие размеры – вспомните: такие сервисы как Google, Facebook и Twitter были адаптированы под другие формы, или версии приложений для iPhone или iPad, такие как например iWork. Небольшие версии более имеют более условную структуру, однако, большей частью имеют тот же вид и атмосферу.
26. Визуальное мышление часто помогает улучшить идею, используйте ручку и бумагу, Photoshop или интерактивный инструмент, например, макеты Balsamiq. Если у вас есть рабочий прототип на устройстве, вы можете получить драгоценное тестирования дешево — просто купите чашку кофе знакомому, в обмен на неофициальное 10-минутный юзабилити-тестирования.
27. Обычно, пользователи ожидают, что программы будут функционировать и выглядеть определенным образом. Например, не используйте жест «щипок» ни для каких функций кроме увеличения, сворачивания или расширения изображения, это только запутает пользователей. Но вы более свободны в выборе цветовых схем – будет слишком скучно, если все приложения будут рабски копировать стандартную палитру Apple.
28. Может быть это и очевидно, но чтобы приложение оставалось простым, избегайте наслоения функций. Может при сравнении с другими приложениями это звучит прекрасно, но это может усложнить и сделать трудным в использовании ваше приложение. Избегайте больших объемов информации, втискивание большого количества информации в маленький экран не сделает приложение проще, это просто утомит пользователя.
29. Всегда разрабатывайте приложение, отталкиваясь от цели, которую пользователь хочет достигнуть — при этом, помогите ему сделать это легко и интуитивно – а не только на основании того, что выбранный дизайн – самый легкий. Обычно приложения разрабатываются на основании единой технической концепции, где пользовательский интерфейс выстраивается вокруг ее нужд.
30. Большинство качественных приложений имеют единую стилистическую тему, которая в свою очередь, влияет на конструктивные решения, и придает вашим приложениям ощущение цельности. Данная тема всегда должна соответствовать главной функции приложения: приведем обратный пример, когда тема не совсем соответствует функции – использование «прошитой кожи» в новом приложении Find a Friend.
31. Чем проще иконка приложения, тем лучше. Иконка должна быть отлично узнаваема в разных размерах. Это не значит, что детализировать изображение не нужно, но эти детали не должны заслонять или перегружать фокус обзора. Избегайте и использования текста, пусть иконка будет визуально представлять ваше приложение.
32. Если визуальная область элемента управления немного меньше стандартного размера тач-области 44x44, убедитесь, что область экрана, отвечающая на прикосновение пользователя по размерам больше, и не размещайте элементы управления слишком близко друг к другу.
33. Постарайтесь разместить элементы так, чтобы пользователь во время работы не закрывал нужную информацию рукой. Обычно, для этого активные элементы размещаются в нижней части экрана, чтобы ничто их не заслоняло. Если это неизбежно, подумайте, как вы можете вывести на экран скрытую информацию. Хороший пример такого решения, функция выбора текста в iOS, где при выборе текста появляется увеличительное стекло.
34. Когда графические элементы ощущаются как настоящие, это всегда смотрится выигрышно. Приложения iOS обычно разрабатываются с учетом реалистичности, поэтому объекты на эркане имеют объем, светлые и затененные участки, как будто пользователь может дотронуться до них рукой. Реалистичный интерфейс должен отражать и свойства реальных объектов, или иллюзия будет нарушена.
35. Если вы разрабатываете тему по заказу клиента, важно применить ее при разработке даже мельчайших деталей интерфейса. Если вы разрабатываете, например, DJ приложение, которое выглядит как микшер, можно использовать затертые и текстурированные кнопки, блестящие диски. Неожиданно появившийся элемент управления, не поддерживающий общую концепцию, будет выглядеть совершенно не к месту, поэтому каждый новый компонент должен соответствовать общей теме.
36. По своей природе, мобильные устройства имеют ограничения, которые разработчикам приходится преодолевать. Нет клавиатуры, экран очень маленький и настоящих кнопок всего несколько. При разработке дизайна интерфейса приложения, в особенности для сенсорного экрана, вам нужно четко определить иерархию и важные элементы каждого из активных экранов. К примеру, если одна из кнопок будет постоянно использоваться, разместите ее в нижней части экрана, чтобы было удобнее нажимать ее большим пальцем.
37. Если иконка вашего приложения не привлекает внимания, она не выполняет свою функцию. Плохие иконки — это иконки, где вместо индивидуального дизайна используется усредненный, используется текст и они перегружены деталями. И еще раз убедитесь, что ваши иконки могут изменять размер без ущерба для собственных функций – если Apple заинтересуется им, у вас будет всего пару дней для предоставления изображения в высоком разрешении.
38. Несмотря на то, что изменить размер приложения, растянув изображение, добавив минимум новой информации, — легче, разумнее будет – хотя это и потребует больше времени – полностью переосмыслить управление приложением и добавить новые элементы для того, чтобы в полной мере воспользоваться преимуществами более крупных размеров. Устройства с большими экранами предоставляют огромное поле для пользовательских экспериментов, тогда как для телефонных экранов важнее доступ к информации и скорость.
39. При разработке структуры приложения, продумайте каждый экран в отдельности, учитывая где и какую информацию разместить, и какие нужны элементы управления. Вероятно, будет трудно сразу понять, какие элементы управления потребуются, поэтому сосредоточьтесь на главной функции каждого из экранов. Когда вы набросаете некоторые экраны в Photoshop в натуральную величину, сохраните их в iPhone в приложении для просмотра фото, и просто пробегитесь по ним взглядом и убедитесь, что они хорошо смотрятся на экране.
40. Обычно, элементы управления в приложениях, располагаются у краев экрана, при этом основной фокус оказывается в центре. Элементы должны быть расположены компактно, так как места в принципе немного – но при этом пользователь должен различать их на расстоянии вытянутой руки, и при нажатии на один элемент, другой активироваться не должен.
41. Если вы хотите разработать интерфейс, поражающий своей красотой, всегда ориентируйтесь на устройство более нового поколения. Используйте по максимуму все возможности, включая дополнительные текстуры, детали и нюансы дизайна, а затем адаптируйте приложение к более старым устройствам.
42. Одно из обязательных условий при разработке приложений – разместить в верхней части экрана источник света под углом 90 градусов, который будет освещать все элементы интерфейса. Угол освещения позволяет представить все тени и градиенты прямо, без наклона. Использование угла в 45 градусов возможно, но при сравнении ваше приложение может проигрывать другим.
43. При выверенном и умеренном использовании, высококачественные текстуры и материалы придадут ощущение качества и высокого класса физическим объектам – например, анодированный алюминий, кожаная обивка, скорлупа грецкого ореха или зеркальный хром – что в свою очередь придаст приложению законченный и дорогой вид, и повысит его ценность.
44. Если вы в приложении предлагаете достаточно широкий набор настроек, убедитесь, что пользователь может найти наиболее важные из них в один или два клика. Даже самые продвинутые из них должны запускаться в три клика.
45. Выделите пару сильных сторон приложения, и убедитесь, что они отражены в его иконке. Покажите ее тем, кто раньше не видел данного приложения, и убедитесь, что они интерпретируют концепцию иконки так, как это было изначально задумано. Не бойтесь отбросить старые идеи и начать сначала.
46. Если вы хотите перенести приложение для iOS на Android, учтите следующее: более старые модели телефонов могут работать с теми же приложениями, ОС автоматически настраивает размер изображений и текста. Что касается планшетов, лучше внести изменения в дизайн некоторых экранов. Помните, что разрешение экрана и плотность элементов – это две разные вещи — вы должны несколько раз проверить как выглядит приложение на большом экране с меньшей плотностью.
47. Помните, что у Apple гораздо больше конструктивных норм, чем у Android, и соответственно – визуальной согласованности. У телефонов и планшетов на платформе Android гораздо больше способов управления приложениями, например, кнопка меню, задние кнопки, регулятор громкости, строка меню и т.д. – но данные элементы могут использоваться по-разному в зависимости от приложения.
48. Наиболее качественно исполненные приложения, можно сказать, не имеют интерфейса– это просто «живой контент». Постоянно пересматривайте концепцию – никогда не успокаивайтесь на достигнутом – тестируйте ее на каждом этапе процесса. Если вы не будете стремиться к совершенству, решение будет очень ограниченным.
49. Финальные испытания приложения должны всегда проходить на настоящих устройствах, а не на эмуляторах – это не помешает даже на ранних стадиях. При переносе на Android, убедитесь, что при тестировании используются различные устройства с различными разрешениями экранов и плотностью.
50. При разработке приложений именно для iPad необходимо учесть множество нюансов форм использования приложения. При переключении между ландшафтным и портретным режимами, важно учесть какие элементы изменятся, и какие плавно перейдут в другую форму.
Благодарности: Yasuko Chujo and Koji Tachibana at e-bird Inc; Scott Meinzer at tap tap tap; Bowen Osborn at Shotzoom; Mladen Djordjevic at NFANY; Christoph Teschner at Algoriddim; Joey Neal at Superstashapp; Ben Zotto at Cocoa Box; Jon Steinmetz at Pixel Research Labs; Mike Rundle at Flyosity; Alex at Androidslide; Steve Varga, AKA Vargatron; and Marcos Weskamp at Flipboard.
Оригинал
habr.com
Intel INDE Multi-OS Engine / Блог компании Intel / Хабр
Не так давно, в начале августа, на конференции Android Developer Conference (Andevcon) 2015, проходившей в Бостоне, корпорация Intel анонсировала INDE Multi-OS Engine — фреймворк для разработки нативных кроссплатформенных приложений на Java.Разработку приложений, которые работаю одновременно на iOS и Android, нельзя назвать ни быстрой, ни дешевой. До недавнего времени, если вы хотели выпустить приложение сразу для двух самых популярных мобильных платформ, перед вами вставал непростой выбор. С одной стороны, вы могли использовать кроссплатформенный инструмент, например Cordova, и в результате получить условно недорогое приложение с достаточно качественным, но в то же время весьма ограниченным UI/UX.
С другой стороны, у вас была возможность разрабатывать два отдельных нативных приложения: Оба подхода имеют свои плюсы и минусы. Однако, даже для крупных компаний с серьезными ресурсами этот выбор оказывался непростым. Но ситуация меняется. Теперь разработчики могут попробовать Intel’s Multi-OS Engine (MOE), который специально предназначен для значительного сокращения времени разработки, необходимого для создания отдельных нативных Android и iOS приложений: Как вы можете знать, Intel INDE — кроссплатформенный набор инструментов для создания нативных мобильных приложений. INDE состоит из целого ряда SDK, библиотек, компиляторов, отладчиков и утилит анализа производительности — всего того, что требуется для полного цикла разработки ПО. А Multi-OS Engine можно смело назвать настоящей “вишенкой” на “торте” INDE!
Почему быть нативным так важно?
Современный пользователь мобильных приложений очень искушен, а магазины для любой платформы заполнены огромным количеством аналогов. Как выделиться среди них? Я сам из двух похожих приложений скорее выберу то, которое выглядит и ощущается по-настоящему согласованным со всей системой. Даже несмотря на то, что разработка нативных приложений занимает больше времени, нативный “Look & Feel” — это именно то, на что обращают внимание конечные пользователи, а значит, экономить на этом просто нельзя. По ряду причин нативные приложения имеют в этой области заметное преимущество:- Прямой доступ к UI-компонентам конкретной платформы: стек навигации приложения, диалоги выбора даты и времени, карты и т.д. Без сомнения, можно пересоздать все эти компоненты самостоятельно, но наша повторная реализация никогда не будет чувствоваться такой же родной, как нативная. Такие самодельные компоненты также не получат никакого автоматического обновления вместе с изменениями в платформе.
- Отсутствие накладных расходов, связанных с отрисовкой UI.
- Нативная многопоточность. Фреймворки, основанные на веб-технологиях не позволяют распараллелить работу приложения так, как это возможно в нативном коде.
Почему именно Java?
Чтобы ответить на этот вопрос, достаточно обратиться к следующему графику: Рейтинг языков GitHub, основанный на объёме кода, хранящегося в его репозиториях, совершенно четко объясняет, почему в качестве языка кросс-платформенной разработки для React Native в Facebook выбрали Javascript, а Intel выбрал Java для Multi-OS Engine.Технические детали
Multi-OS Engine поставляется в виде плагина для Android Studio. С помощью него вы можете создать новый MOE проект, либо добавить MOE модуль в уже существующий проект. Таким образом, вам совсем не обязательно знать Objective-C, чтобы писать нативные приложения под iOS. При этом разработка под Android не претерпевает никаких изменений. Но у вас появляется замечательная возможность переиспользовать весь платформенно-независимый код. MOE не предлагает 100% переиспользование кода, но при правильной архитектуре эта величина может достигать 60%. Вот как Multi-OS Engine обеспечивает поддержку Java на iOS:- Автоматически генерирует байндинги по заголовочным файлам ObjectiveC и C
- Использует специальные Java-аннотации
- Связывает Java с нативным кодом с помощью библиотеки NatJ
- Избавляет от необходимости JNI вызовов
- Полностью покрывает iOS API
Процесс разработки iOS-приложений на Java
- Создайте Multi-OS Engine проект в Android Studio
- Если вы используете Mac, добавьте новую Run/Debug конфигурацию “Intel MOE iOS Application” для сборки на локальной машине. На Windows-хосте доступна конфигурация “Intel MOE Remote Build” для сборки “в облаке”.
- Вы можете создавать UI прямо в XCode либо использовать специальный MOE UI designer, встроенный Android Studio.
- Свяжите ваш UI с Java, используя аннтотации и библиотеку NatJ.
- Используйте автодополнение кода для легкой работы с iOS SDK.
- iOS-приложения могут быть запущены на симуляторе и устройстве прямо из Android Studio.
- Отлаживайте ваши приложения прямо в Android Studio.
P.S. Команда, разрабатывающая Multi-OS Engine, почти полностью находится в России (Нижнем Новгороде и Москве). И если у вас есть вопросы, которые вы хотите задать лично, у вас есть отличная возможность — посетить конференцию Droidcon в Москве 26 сентября.
habr.com
Как создать приложение на iPhone не имея Mac OS Х и SDK? / Хабр
Я всегда хотел попробовать себя в таком деле, как написание приложений для iPhone. Пусть для начала оно было простым, как «Hello world!», но зато написанное своими руками. Тем более платформа iPhone OS стала очень популярна, и большинство разработчиков отдают предпочтение именно ей. Но как говорится — мои желания не совпадают с моими возможностями. SDK доступен только для маков, а возможности купить мак у меня нет — дорогой. Но в интернете, случайно, узнал об одном сервисе о котором я расскажу далее.
Сервис называется AppMark. Удобный и простой в пользовании (правда на английском), который позволяет прямо не выходя из браузера написать небольшое приложение.
Как работать?
Для создания мини-приложения переходим на главный сайт — тут всё и будет происходить.Давайте создадим приложение, позволяющее читать последние новости с сайта Хабрахабр. 1) Вводим адрес сайта в строку ввода. Жмем Go.
2) Система проведёт предварительные настройки.
3) В принципе всё! Сбоку появится iPhone в котором можно протестировать программу. Просто нажмите на иконку!
Вот как выглядит запуск приложения:
Окно с последними новостями:
Просмотр конкретной новости:
Хотите большего? Можно зарегистрироваться на сайте (бесплатно), и изменить полностью интерфейс: добавить логотип при загрузке, иконку. Также можно сделать несколько лент и добавить их в нижнюю панель в виде иконок (которые можно тоже выбрать). Если захотите что-нибудь рекламировать в приложении — можно добавить рекламу.
Какие плюсы?
- Можно создать приложение не имея мака и SDK разработчика. Зашел, смастерил — готово.
Есть минусы?
- Да. Если Вы хотите опубликовать его в App Store. то нужно купить лицензию, которая стоит немало — 199$. С учётом того, что лицензия для SDK стоит 99$ это большая разница. Но те, кто уже имеет лицензию для SDK, могут указать её в настройках.
habr.com
