Что такое «Нативное приложение»?
Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.
Titanium !== HTML
Каждый раз при сравнении с Phonegap (Cordova), Ionic и чем-либо еще, я начинаю мотать головой, махать руками и громко кричать о том, что в Titanium нет HTML.
Приложения на Titanium – это не сайты, которые чудесным образом обернуты в приложения.
Но при общении с клиентами или людьми, не очень подкованными в техническом плане, для которых JavaScript вызывает ассоциации с этими технологиями, представление HTML как просто еще одного технического термина не всегда помогает. Кроме того, определение Titanium как чего-то, чем он не является, не совсем правильно.
Что ты имеешь в виду под «Нативной» разработкой?
Как работать в Kontakt
В ответ я стал спрашивать:
А что делает приложение нативным?
Может быть, то что…
- Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
- Разработчик использует стандартный для платформы язык?
- Приложение использует строительные блоки (API), которые предоставляет платформа?
- Приложение работает так, как ожидает пользователь на этой платформе?
После короткого разговора о том, чего, по их мнению, JavaScript предложить не может, чаша весов всегда склонялась к четвертому пункту. Это подтверждает опрос в Твиттере, который я недавно провел.
Что такое хороший User Experience?
Итак, что же значит соответствующий платформе UI и UX? Ну, в первую очередь то, что мы не печемся о технологии, только о том, что она нам дает; Как приложение выглядит и чувствуется пользователем. Во вторую то, что поведение приложения зависит от платформы.
Выглядит и ведет себя ожидаемо
iOS, Android и Windows имеют различные требования к дизайну (iOS, Android,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана.
Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
Секреты Автоматизации KONTAKT 6 (Native Instruments)
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Tab A Tab B Tab C
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView.
Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.
Чувствуется ожидаемо
Но есть еще один, менее заметный фактор, который влияет на UX. Взаимодействие с приложением должно вызывать правильные чувства. Здесь мы имеем в виду, что время реакции и визуальный отклик такие, какие вы ждете от платформы.
Исторически этот момент всегда был большой проблемой для кросс-платформенной разработки. Все решения так или иначе имеют некий уровень абстракции над платформенными API. Это потенциальное узкое место. В Titanium мы посвятили массу времени оптимизации. Возьмите например, ListView, он может быть на 60% более отзывчивым, чем его предок, TableView.
В приложениях, которые используют HTML, это продолжает быть проблемой. Плоский интерфейс сделал все для того, чтобы такие приложения выглядели хорошо, но не нужно быть семи пядей во лбу, чтобы заметить разницу в том, как UI реагирует на взаимодействия. Часто он просто «не такой», и вот в чем задача UX: сделать его «таким».
Как достичь классного UX?
Кроме всего прочего, вам нужно классный разработчик. Плохие приложения можно и в XCode со Swift сделать, так что без сомнения, вы можете сделать его и с помощью любой (кросс-платформенной) технологии. Используйте нужные платформо-зависимые UI компоненты в нужных местах, избегайте утечек памяти, пишите чисто и с умом.
Плюс ко всему, используйте имеющиеся в вашем распоряжении строительные блоки, не имитируйте их. Помните, Titanium !== HTML и наши 4 пункта списка. Мы с уверенностью полагаем, что для нативного UX нужно использовать нативные UI и системные API. Для достижения пункта №4 нужно выполнить пункт №3.
Вот поэтому Facebook отказался от HTML приложений и создал React Native.
И да, у нас в Titanium это было с 2009.
Code Strong, Code Native… In JavaScript!
- JavaScript
- Разработка мобильных приложений
Источник: habr.com
Как разработать своё первое приложение на React Native
Привет я Никита, занимаюсь разработкой на React/React Native и на всяких других штуках в Secreate. Хочу немного поговорить о том, что же всё-таки такое React Native, почему он сейчас важен и популярен, а также вместе с вами попробую написать небольшой проект для демонстрации основ.
Что такое React Native?
Сначала нужно разобраться, что есть React. React — это инструмент для создания пользовательских интерфейсов. Его основная задача — обеспечить отображение на экране того, что можно увидеть на веб-страницах. React позволяет легко создавать интерфейсы, разделяя каждую страницу на небольшие фрагменты и компоненты.
Он очень удобен для создания веб-приложений и не требует большого порога вхождения. Так вот, разработчики популярной соцсети подумали, что было бы круто, если бы React можно было бы использовать для создания кросс-платформенных мобильных приложений, и в 2015 году React Native был представлен публике и появился на GitHub, где уже каждый мог внести свой вклад. React популярен по нескольким причинам. Он компактен и отличается высокой производительностью, в особенности при работе с быстро меняющимися данными. За счет своей компонентной структуры, React поощряет вас писать модульный и многократно используемый код.
В мире кроссплатформенной мобильной разработки уже были свои решения, к примеру Apache Cordova — технология, которая позволяла использовать HTML + CSS + JavaScript + нативный функционал платформы, на которой приложение было запущено, для его работы. Однако, технология имеет большую проблему — быстродействие. Так же на данный момент существуют и другие, такие как Xamarin, Flutter, QT и так далее.
Cравнение фреймворков для кроссплатформенной мобильной разработки: React Native, Flutter, Ionic, Xamarin и PhoneGap
В React Native код пишется на JavaScript, и исполняется при помощи JavaScriptCore — движка, который использует Safari. Так же можно использовать нативные модули платформы, к примеру камеру или Bluetooth. Для этого пишется код, реализующий функциональность на языке, который предназначается для разработки под конкретную платформу (Java/Swift/Objective C) и сообщается со средой JavaScript посредством bridge.
Если сравнивать с типовой разработкой для iOS и Android, React Native предлагает много других возможностей. Так как ваше приложение в основном состоит из JavaScript, можно воспользоваться многими преимуществами. Например, для того чтобы увидеть добавленные в код изменения, вы можете немедленно «обновить» приложение, не дожидаясь завершения билда.
Senior Android Developer МТС , Москва, можно удалённо , По итогам собеседования
Для большинства стандартных элементов UI есть компоненты в RN, к примеру View = UIView в iOS, так что реализовывать изыски интерфейса должно быть несложно, если есть знания React.
Почему же RN стал таким популярным?
- для написания кода используется JavaScript, в частности React;
- есть возможность быстро написать приложение под обе платформы. Меньше затраты — выгоднее бизнесу;
- большая библиотека нативных и не-нативных компонентов;
- для отладки можно использовать браузер, так же есть hot-reload для быстрого просмотра изменений. Нет необходимости пересобирать приложение при внесении изменений в код;
- для отрисовки компонентов используются нативные компоненты используемой системы (например UIImage/ImageView), соответственно производительность такого UI выше, чем при использовании webview;
- просто написать свою библиотеку для RN, использующую нативный функционал системы;
- ещё одна причиной почему RN набрал популярность в последние годы является то, что его используют такие гиганты как Skype, Tesla, Baidu, Bloomberg и т. д.
Натив или кроссплатформа — что выбрать начинающему мобильному разработчику? Отвечают эксперты
Первое приложение
Давайте попробуем написать своё первое приложение и понять что для этого нужно. Пусть это будет, к примеру, приложение для отображения и поиска разных пользователей.
Нам понадобится cli утилита npx, которая поставляется вместе с Node.js, Android Studio — если мы хотим протестировать приложение на Android, либо Xcode — если на iPhone. Как установить указанные инструменты подробнее можно почитать здесь.
30 шикарных инструментов, чтобы писать под Android как профи
Начнем с того, что создадим проект командой npx react-native init RandomGuysApp . В RN приложение также можно добавить TypeScript, но мы этого здесь делать не будем.
Спустя какое-то время у нас создалась такая структура папок
В index.js написано:
это показывает, что компонент App является точкой входа в наше приложение. Я предпочитаю хранить код в отдельной папке, поэтому перенесу App.js в новую папку — src , сменив в index.js путь до него на
import from ‘./src/App’;
Начнем с создания роутера. В браузере, когда пользователь кликает по ссылке, URL добавляется в стек истории переходов, а когда он жмет кнопку назад — браузер удаляет последний посещенный адрес из стека. В RN по умолчанию такого понятия нет, для этого и нужен React Navigation. В приложении может быть несколько стеков. К примеру у каждого таба внутри приложения может быть собственная история посещений, но может быть и один.
Создадим папку navigators , а в ней RootNavigator.js , в который поместим такой код
- компонента ListScreen еще не существует;
- в приложении ожидается всего два экрана, так что структурно оно несколько упрощено, для демонстрации работы с RN.
Что здесь происходит? Создаётся новый стек навигации, в котором указывается список экранов, находящихся в нем. А также указывается стартовый экран стека. Т. к. у нас будет всего один стек, то по сути это и будет стартовый экран приложения.
Перейдем к созданию первого экрана. Добавим папку screens , в которой создадим файл PersonListScreen
Там разместим такой код:
import React, from ‘react’; import from ‘react-native’; import from ‘../components/PersonListItem’; export class PersonListScreen extends Component < state = < list: [], isLoading: false, >; componentDidMount = () => < this.onRefresh(); >; getMoreData = (isRefreshing) => <>; onRefresh = () => < this.getMoreData(true); >; onScrollToEnd = () => < if (distanceFromEnd < 0) < return; >this.getMoreData(false); >; onItemPress = (item) => < this.props.navigation.navigate(‘info’, ); >; keyExtractor = (person) => person.login.uuid; renderItem = () => < return ( /> ); >; render = () => < const = this.state; return ( > renderItem= keyExtractor= refreshing= onRefresh= onEndReached= onEndReachedThreshold= /> ); >; >
Опять же, PersonListItem еще не существует, но это временно. FlatList , это эффективный компонент для рендера списков — он поддерживает PullToRefresh , прокрутку к элементу списка по индексу, производительный рендер за счет отключения рендера компонентов, которые слишком далеко от видимой области экрана и многое другое. Конечно, одинаковые элементы в столбик/ряд можно рисовать и другим образом, например через ScrollView , но это самый эффективный способ.
В renderItem передается каждый элемент массива из пропсы data , и возвращается списковый компонент. keyExtractor это по сути аналог свойства key , только в виде функции, вызываемой для каждого элемента.
Итак, при заходе на страницу мы собираемся получить список юзеров, и отрисовать его. Когда список тянется вниз — обновить его, а когда мы достигаем его конца — подгрузить новые данные. Вернёмся пока к PersonListItem , добавим в components файл PersonListItem.js и заполним его таким кодом
import React, from ‘react’; import from ‘react-native’; export class PersonListItem extends Component < render = () => < const = this.props; return ( onPress=> > resizeMode= style= /> > > > ); >; > const styles = StyleSheet.create(< container: < flexDirection: ‘row’, alignItems: ‘center’, padding: 12, borderBottomColor: ‘#b0b0b0’, borderBottomWidth: 0.4, >, avatar: < width: 50, height: 50, borderRadius: 25, >, col: < marginLeft: 10, >, name: < fontSize: 16, color: ‘#2e2e2e’, >, email: < marginTop: 10, fontSize: 13, color: ‘#b0b0b0’, >, >);
В RN нет пропсы className и стили передаются в пропсе style , а объявляются через StyleSheet.create() . Можно, конечно, использовать объект как стиль, но в этом случае не будут применяться некоторые внутренние оптимизации производительности.
Заметили, что вместо пикселей используются голые числа? Потому что по умолчанию, как единица измерения используются dp (density-independent pixels), а для конвертации в px можно использовать PixelRatio.getPixelSizeForLayoutSize() , но это нам не особо нужно. В принципе, практически все свойства стилей дублируют CSS, так-что особо проблем быть не должно.
Но есть такая особенность — все компоненты в RN имеют display: flex . Ещё есть display: none , других вариантов нет. Главное отличие, что все компоненты по умолчанию имеют flexDirection: column , в отличие от браузерной версии. Есть еще несколько отличий, но перечислять я их не буду, в целом можно сказать, что в RN display: flex несколько урезанный.
Вернёмся к App.js . Заменим содержимое файла следующим кодом
Используем наш созданный роутер, что-бы у нас работала навигация. Так же здесь используется компонент SafeAreaView , он нужен что-бы контент в iOS отрисовывался внутри «безопасных» границ экрана и, к примеру, не наезжал на «монобровь» в iPhone X.
Продвинутый дебаг в Xcode: средства отладки, про которые часто забывают
Сборка и запуск
Попробуем собрать и запустить то, что у нас есть. Если у вас macOS, то можно использовать Xcode. Для этого при открытии проекта нужно указать файл ios/RandomGuysApp.xcworkspace внутри проекта. Если Android, то нужно установить JDK и необходимые SDK. Проще всего открыть папку android в Android Studio, и IDE установит необходимое ПО. А после этого написать в корневой папке проекта npx react-native run-android .
Когда проект запустится, то на экране должно появиться, что-то вроде этого.
Это экран с названием list , который мы зарегистрировали в навигаторе. Но там пока что пусто, так как нам еще нечего отрисовывать. Поэтому вернемся в PersonListScreen.js и добавим в функцию getMoreData() код для получения данных.
getMoreData = (isRefreshing) => < const limit = 15; const offset = isRefreshing ? 0 : this.state.list.length; const page = Math.ceil(offset / limit) + 1; fetch(`https://randomuser.me/api/?seed=foobarpage=$`) .then((r) => r.json()) .then((json) => < this.setState(< list: isRefreshing ? this.state.list.concat(json.results) : json.results, >); >) .catch((e) => < console.log(e); >); >;
Для отладки приложения можно использовать react-native-debugger, либо браузер. Включается дебаггер комбинацией клавиш ctrl(cmd) + M для Android, cmd + D для iOS. Там же можно включить live reload.
Сверху к import из react-native добавим импорт модуля StyleSheet
Вниз этого же файла добавим
const styles = StyleSheet.create(< container: < flex: 1, >, >);
и добавим этот стиль нашему View . Получаем что-то вроде такого
При подтяжке экрана вниз — список обновляется, при скролле — догружается. Добавим возможность перехода в карточку юзера.
onItemPress = (item) => < this.props.navigation.navigate(‘info’, ); >;
Это переход в экран с названием info с передачей выбранного юзера как параметра. В дальнейшем его можно будет получить из компонента экрана. Теперь добавим этот экран в навигатор RootNavigator.js и напишем для него код.
. import from ‘../screens/PersonInfoScreen’; . component= /> component= /> .
Так же создадим файл src/screens/PersonInfoScreen.js и добавим туда следующий код.
import React, from ‘react’; import from ‘react-native’; export class PersonInfoScreen extends Component < renderRow = (cells) => < return cells.map((cell) =>( key=> > > )); >; render = () => < const = this.props.route.params; return ( > > style= resizeMode= /> , , , , , ])> ); >; > const styles = StyleSheet.create(< container: < flex: 1, alignItems: ‘center’, >, avatar: < width: 100, height: 100, borderRadius: 50, marginTop: 20, >, cell: < marginTop: 15, justifyContent: ‘center’, alignItems: ‘center’, >, cellTitle: < fontSize: 13, color: ‘#b0b0b0’, >, cellValue: < marginTop: 10, fontSize: 16, color: ‘#2e2e2e’, >, >);
Вот что у нас получилось.
Таким образом мы сделали приложение для вывода и просмотра некоторой информации по разным людям.
Ресурсы
Для изучения RN можно найти много ресурсов, вот небольшой список:
- Официальная документация, здесь вы сможете найти описания всех API и встроенных компонентов библиотеки.
- Один из лучших курсов для изучения React Native. Он поможет быстро разобраться в нём, а также научит пониманию экосистемы RN и React в целом.
- Тут большой список крутых библиотек на разные случаи жизни и статей по теме.
В итоге
React Native — это мощная платформа, используемая предприятиями любого размера для создания мобильных приложений. Это быстрый, эффективный и относительно простой способ для создания приложений на JavaScript. Главным его преимуществом является то, что он позволяет быстро создавать приложение под несколько платформ одновременно, а также имеет невысокий порог вхождения. React Native широко используется крупными брендами, поэтому не стоит беспокоиться о том, что он куда-то денется в ближайшие пару лет.
Код проекта можно найти здесь.
Источник: tproger.ru
Что такое нативные и кроссплатформенные приложения? Плюсы и минусы.
08.04.2019
10681
Рейтинг: 5 . Проголосовало: 4
Вы проголосовали:
Для голосования нужно авторизироваться
- Что такое нативные приложения?
- Что из себя представляют кроссплатформенные приложения?
- Какие инструменты для разработки кроссплатформенных приложений применяют чаще всего?
- Преимущества и недостатки нативного подхода
- Преимущества и недостатки кроссплатформенных приложений
- Вывод
Мировая статистика использования смартфонов показывает абсолютное преобладание всего двух мобильных операционных систем. Так, по данным портала statista.com, во втором квартале 2018 OS Android была установлена на 88% всех используемых смартфонов, а iOs – на 11.9%. Данные портала netmarketshare.com, в свою очередь, показывают на апрель 2019 для OS Android – 69.63%, а для iOs — 28.50%.
- разрабатывались быстро;
- получались качественными и надежными;
- легко обновлялись и поддерживались;
- легко задействовали все необходимые возможности платформы.
Фактически, рынок заставляет разработчика делать выбор между разработкой кроссплатформенных приложений и разработкой нативных приложений. Рассмотрим детальнее, что представляет из себя каждый из указанных подходов.
Что такое нативные приложения?
Нативные приложения (от англ. native — родной) разрабатываются под конкретную аппаратно-программную платформу и пишутся на языках, созданных для данной платформы. И iOs, и Android имеют свои SDK (от англ. software development kit — набор средств разработки) и свой стек технологий, завязанные на определенный язык программирования. Например, родными языками для Android являются Java и Kotlin, для iOS, соответственно — Swift и Objective-C.
Нативные приложения создаются специально для запуска на целевой платформе — с поддержкой всех нативных технологий и аппаратных возможностей конкретной платформы.
Что из себя представляют кроссплатформенные приложения?
Как следует из названия, кроссплатформенность подразумевает создание приложений, которые могут работать в различных операционных системах. После написания кода приложения его можно развернуть на разных устройствах и платформах, не беспокоясь о проблемах несовместимости. Это универсальный подход, который широко используется для экономии времени и денег на разработку. Часто для этого используются специализированные кроссплатформенные фреймворки.
Примером такой разработки является применение фреймворка Xamarin для создания приложений, работающих не только на Windows. Благодаря использованию Mono (опенсорс реализации платформы .Net), проекты, написанные на C#, успешно запускаются на Unix-like системах – iOs, Android, Linux.
Какие инструменты для разработки кроссплатформенных приложений применяют чаще всего?
Ссылаясь на статистику appfigures.com можно выделить такие инструменты:
Как мы видим наиболее часто применяемым инструментом разработки кроссплатформенных мобильных приложений на конец 2017 года был Cordova – 39.89%. Вторым по частоте применения инструментом является Unity – 30.93%. Третьим – Adobe Flash с 10.39%. Следом идут Cocos2D – 9.37%, Xamarin – 4.5%, Appcelerator – 3.79%, Corona – 2.68%, React Native – 1.85%.
Итак, стоит ли вам инвестировать в разработку отдельных нативных приложений на несколько платформ сразу, или убивать двух зайцев одним выстрелом, разрабатывая кроссплатформенные приложения? Или может стоит вообще сосредоточиться только на одной платформе и не обращать внимание на другую, пока не достигнут успех среди приложений первой?
По данным портала appfigures.com на начало 2018 года количество приложений, присутствующих на обеих популярных платформах, было вполне ощутимым:
Тема связана со специальностями:
450 тысяч приложений на обеих платформах. Это более 28% приложений в Apple App store и 14% в Google Play Store. Это выглядит достаточно весомой частью, чтобы задуматься об присутствии на обеих платформах и попытке экономии используя кроссплатформенную разработку.
По данным того же портала, многие уже существующие приложения расширяют свой рынок, выходя, со временем, на другой платформе. При че чаще приложения выходят дополнительно на Android, выпускаясь изначально под iOs.
Можно также наблюдать тенденцию к снижению процента кроссплатформенных приложений за 2016 – 2017 годы.
Так стоит ли потратить деньги на разработку двух нативных приложений, идеально соответствующих каждой платформе, или есть смысл сэкономить ресурсы и получить одно – кроссплатформенное?
Давайте рассмотрим плюсы и минусы каждого из указанных подходов.
Преимущества и недостатки нативного подхода
Плюсы нативных приложений
- Высокая производительность
Нативные приложения задумываются и разрабатываются, чтобы решать конкретные задачи на конкретной платформе. Это приводит к лучшему соответствию возможностей приложений аппаратным возможностям устройств, включая Bluetooth, NFC, камеру, GPS и т. д.
Эта соответствие необходимо, когда приложение должно использовать такие данные, как физическое и географическое местоположение и др.
Лучший пользовательский интерфейс
Минусы разработки нативных приложений
- Дороговизна и затраты времени на разработку
Видео курсы по схожей тематике:
UWP Community Toolkit Углубленный
Плюсы и минусы кроссплатформенных приложений
Как следует из названия, кроссплатформенность влечет за собой создание приложений, которые могут работать в различных операционных системах. После написания кода приложения его можно развернуть на разных устройствах и платформах, не беспокоясь о проблемах несовместимости. Это универсальный подход, который широко используется для экономии времени и денег.
Вот некоторые преимущества и недостатки использования кроссплатформенного подхода в разработке мобильных приложений.
Плюсы кроссплатформенных приложений
- Один код доступен для повторного использования на других платформах
Недостатки кроссплатформенной разработки приложений
-
Кроссплатформенные приложения не являются такими гибкими, как нативные приложения
Вывод
Подведем краткие итоги. Попробуем сузить наш достаточно сложный выбор между нативной разработкой и кроссплатформенной.
Обратите внимание на стратегию продвижения приложения и на его предполагаемый функционал. Если вам сразу нужен будет охват большей аудитории и у приложения функционал не является сложным — проще и дешевле воспользоваться кроссплатформенным подходом. Если вашему приложению необходимо использовать специфические особенности платформы, при этом нет необходимости в одновременном присутствии сразу и в Apple App Store, и в Google Play Store – разрабатывайте под выбранную платформу нативное приложение. И если ваши успехи покажут вам, что можно захватывать новый рынок – у вас уже будут средства на разработку под вторую платформу. Другие промежуточные варианты будут компромиссами и могут склонять чашу весов как к нативным, так и к мультиплатформенным решениям.
Бесплатные вебинары по схожей тематике:
Увлекательное путешествие в страну динамического программирования
Введение в Kotlin
Джинн – сервис анонимного поиска работы для программистов
Используйте выбранный вами подход для построения качественных и полезных приложений. С нашей стороны можем порекомендовать ряд видеокурсов.
Для создания кроссплатформенных игр очень удобным инструментом является Unity и на ITVDN вы найдете серию видео курсов по разработке игр на Unity.
Если вы хотите попробовать себя в разработке кроссплатформенных приложений с использованием такого инструмента, как Xamarin, вам могут оказаться полезными такие уроки на портале ITVDN.com, как Xamarin. Легкий старт и Разработка пользовательского графического интерфейса (GUI) на C# под Android (Xamarin).
Если вы планируете в дальнейшем разработку нативных приложений под Android, мы рекомендуем начать с таких курсов — Java Starter и Java Essential.
Также смотрите на ITVDN видео курсы по специальности Android Developer и iOS Developer.
Источник: itvdn.com
Что такое нативное приложение? Мобильное приложение
В переводе с английского native означает «родной». Нативное приложение разрабатывается для мобильных телефонов под конкретную операционную систему. Этим занимаются специалисты, которые обладают определенными знаниями и навыками в этой области. У нативных приложений приятный дизайн, они свободно взаимодействуют с мобильной ОС, могут работать через интернет-соединение или оффлайн.
Что это?
Нативное приложение – это разработка, доступная для одной платформы устройства. Например, существуют мобильные приложения, которые созданы специально для платформы Android или iPhone. С развитием современных технологий, появлением различных приложений (нативных, гибридных, веб) появилась возможности выбора. Загружаются нативные приложения через специальные магазины (App Store, Google Play) и устанавливаются на смартфон.
Особенность в том, что они разрабатываются для конкретной платформы, с использованием «родных» языков программирования при их написании. Если приложение создано под конкретную операционную систему, оно хорошо работает и смотрится органично. К тому же приложение с легкостью использует функции программного обеспечения смартфона, такие как фотокамера, микрофон, плеер, и экономит ресурсы устройства.
Одно из самых известных примеров нативных приложений – Shazam. Оно определяет, какая песня играет на другом устройстве. Shazam устанавливается из магазина, для него требуется доступ в Интернет, а для работы необходим диктофон смартфона. Instagram – популярное нативное приложение, которому для работы необходимо соединение с Сетью.
Предназначение
Мобильное приложение в современном мире – это канал связи, коммуникации между людьми и компаниями. Они необходимы в бизнесе. Через них можно продавать услугу или товар, общаться с клиентами, создавать структуру бизнеса с партнерами. Приложения для телефона помогают оптимизировать внутреннюю коммуникацию в фирме.
Сегодня через мобильные приложения можно читать газеты, узнавать последние новости, смотреть телешоу, фильмы. И все это независимо от времени суток и места нахождения. Приложения способы продвигать товар, презентовать услуги. Это отличное маркетинговое средство. Кроме того, через мобильные приложения можно посещать социальные сети, общаться с друзьями и заниматься бизнесом.
Особенность в том, что приложение для смартфона разработчики могут сделать на заказ, специально для конкретного проекта.
Разработка нативных приложений для бизнеса проходит три основных этапа. Первый – это адаптация уже имеющегося веб-сайта под смартфон (создание web-приложения). Второй этап – создание гибридных приложений, сочетающих веб-технологии и функции мобильных устройств. Третий шаг – написание нативного приложения для мобильного телефона.
Он наиболее ресурсоемкий, но позволяет реализовать возможности операционной системы устройства и добиваться намеченных результатов за счет расширенного функционала смартфона. Популярность нативных приложений зависит от их высокой производительности, отлаженности, стабильности, возможности работать без Интернета. Последующая загрузка в магазин приложений позволяет отслеживать разработчику статистику продаж. Используйте нативные приложения, если необходима обработка огромного количества данных и большая скорость работы.
Виды
Виды мобильных приложений: нативные, веб и гибридные имеют сходства. Нативные пишутся специально для операционных систем, таких как iOS. Android, Win Phone. Загружаются они через магазины приложений и соответствуют их требованиям. Нативные приложения работают быстро и отлажено, благодаря оптимизации под конкретные ОС.
У них есть доступ к функциям устройств. Эти приложения могут работать от Интернета или же автономно.
Веб-приложения имеют общие черты с мобильными версиями сайтов, но у них расширенный интерактив. Они создаются для того чтобы можно было пользоваться сайтом через смартфон. Его главное отличие: приложение не нужно устанавливать. Вся работа осуществляется через браузер. Разница между нативным и веб-приложением заключается в возможности свободно управлять информацией.
Гибридные сочетают в себе функции двух предыдущих. Приложение работает с программным обеспечением смартфона, так как является кроссплатформенным. Загружается из магазина приложений, работает через Интернет. Гибридное приложение – самое популярное среди пользователей.
Нативное используется, если нужна высокая скорость обработки информации (социальные сети, игры или геолокация). Помните, что нативные приложения Android не подойдут для айфона или смартфонов с другой платформой.
Преимущества
Нативное приложение обладает рядом преимуществ. Высокая производительность, взаимодействие с конкретной операционной системой, малое потребление энергии, памяти телефона, удобство использования. К преимуществам этого приложения можно отнести максимальную функциональность и отличную скорость работы, доступ к программному обеспечению смартфона, в некоторых случаях для использования не требуется интернет-соединение. Скачать и установить приложение можно лишь через специальный магазин.
Недостатки
Нативное приложение имеет недостатки. На его разработку уходит много времени, стоимость такого приложения выше. От разработчика требуются знания определенной среды программирования. Кроме того, нативное работает с единичной операционной системой. Если потребуется что-либо изменить в приложении, необходимо выпускать обновление.
Как установить?
Нативное мобильное приложение устанавливается с учетом операционной системы смартфона. Для того чтобы выбрать необходимое приложение, перейдите в любой магазин, например Google Play, и выберите подходящее. Скачайте его и установите. Как правило, приложение будет работать, если есть соединение с Интернетом. Если не получается установить, проверьте объем памяти смартфона.
Его должно быть достаточно для установки.
Нативный код
Что значит «нативное приложение»? Для многих это словосочетание покажется новым, но на самом деле практически все современные пользователи гаджетов сталкиваются с ним ежедневно. Для корректной работы нативного приложения разработчики пишут специальный код. Эта система команд, машинный язык, который будет интерпретироваться смартфоном.
Инструкции, заложенные в приложении, позволят пользователю реализовать его возможности на полную мощность. Команды, заложенные разработчиком, могут быть разной длины и диапазона. Нативные приложения работают быстро из-за емкого, но небольшого кода.
Самый популярный язык программирования этих приложений – Java. Он дает разработчикам большие возможности. Его универсальность, удобство позволяет создавать в кратчайшие сроки простые корпоративные приложения. Плюс Java-разработки в том, что его инструменты доступны на всех операционных системах ПК, которые включают Linux и MacOS. Если хотите разработать приложения на языке Java, потребуется компьютер под управлением MacOS X. Нативное приложение iOS отличается от Android количеством времени, потраченного на разработку.
Цена
Бесплатный конструктор для нативных мобильных приложений помогает пользователям самостоятельно его создать. В Сети огромное множество конструкторов. Самые популярные и известные – это My-apps, Net2Share, BuildApp, MobiumApps, Appsa4u. Например, конструктор My-apps самостоятельно собирает приложение под операционные системы iOS и Android.
Пользователи могут выбрать один из десяти готовых шаблонов, в зависимости от предназначения приложения. Конечный результат можно будет опубликовать в магазине для скачивания.
Полноценная разработка нативного приложения стоит недешево. Перед тем как ее планировать, определитесь с бюджетом. Он должен состоять из средств на продвижение готового продукта и саму разработку. Если приложение готовится для нескольких операционных систем, его стоимость увеличивается вдвое. Речь идет о разработке для юридических лиц, например, торговых компаний.
Гибридные приложения стоят на 30% больше нативных, а у веб низкая цена из-за единой кодовой базы, поэтому разрабатывать их выгоднее, чем нативные.
Создание нативных приложений – это всегда огромные траты денежных и временных ресурсов. Не существует типовых проектов, для каждого заказчика приложения разрабатываются индивидуально. Цена включает в себя дизайн, число операционных систем, использование технологий для написания кода, сложность работы, тестирование, публикация и прочие нюансы.
Сложное приложение может стоить несколько миллионов рублей. Причем это только разработка. Публикация, тесты и прочие услуги нуждаются в дополнительном финансировании. Именно поэтому приложения заказывают крупные бизнес-компании, которые готовы позовлить себе такое благо. Приложения в дальнейшем приносят хороший доход и окупаются со временем.
Ведение бизнеса, расширение клиентской базы, увеличение спроса на продукцию, создание положительного имиджа — плюсы мобильных приложений.
Производительность
От производительности смартфона зависит, как будет работать приложение. У нативных есть прямой доступ к платформе телефона и его функциям, что положительно влияет на их производительность. Гибридные приложения, если они корректно сделаны, могут преобразовывать веб в нативные. Производительность web-приложений зависит от скорости интернет-соединения, поэтому у нескольких пользователей оно может работать по-разному.
Распространение
После разработки нативное приложение Windows, Android, iOS должно добраться до пользователей. Распространение через магазины приложений – самый оптимальный вариант. Существуют особые требования к готовому продукту, которых разработчику следует придерживаться заранее. Они зависят от внутренней политики магазина.
Если приложение успешно, его скачивают пользователи, а владелец получает прибыль и повышение рейтинга. Помните, что добавление любого контента (нативных и гибридных разработок) в магазин приложений нуждается в процедуре подтверждения.
Источник: fb.ru
Кроссплатформенные приложения против нативных: сравнение и выбор подходов
Как правило, выход любого бизнеса в интернет протекает по следующему сценарию: сначала компания запускает сайт, затем его адаптируют под мобильные устройства, и если наблюдается прирост трафика, появляется смысл закрепиться среди владельцев мобильных гаджетов, и компания выпускает приложение.
Сравнивать мобильный сайт и приложение нет смысла — второе однозначно выигрывает за счет широты своих возможностей и отзывчивого интерфейса, взаимодействовать с которым через телефон или планшет гораздо комфортнее. Кроме того, приложение может работать без постоянного подключения к интернету.
Вне зависимости от того, на чем построен ваш бизнес — на продажах, предоставлении услуг или просветительской деятельности, сегодня невозможно не учитывать время, которое люди проводят перед экранами мобильных устройств.
Эта статья призвана рассказать о двух подходах к разработке приложений — нативном и кроссплатформенном.
Каждый из подходов обладает своей спецификой, критически влияющей на конечный результат. И дабы облегчить понимание между заказчиком и разработчиком, хочется рассказать о том, что собой представляют оба подхода, разобрать их достоинства и недостатки, разрушить укрепившиеся стереотипы о разработке и дать ответ на главный вопрос: как сделать выбор в пользу того или иного подхода по принципу целесообразности.
Нативный подход
Нативные приложения — это приложения, с которыми вы сталкиваетесь с первого дня использования устройства. Это установленные по умолчанию браузер, почтовый клиент, адресная книга, будильник, календарь и другие стандартные программы.
Как создать нативное приложение? Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то и Swift для iOS или Java для Android, такое приложение будет называться нативным (от англ. native — родной, естественный). «Нативки» могут получать доступ ко всем службам, сервисам и примочкам телефона: камере, микрофону, геолокатору, акселерометру, календарю, медиафайлам, уведомлениям и так далее — в общем, полноценно обживаются и чувствуют себя как дома.
Кроссплатформенный подход
Кроссплатформенные приложения — что это? Представьте себе мобильный сайт, которому не всегда нужен интернет, а с точки зрения дизайна он ближе к мобильным приложениям, а не к . Примерно так можно описать кроссплатформенные приложения.
Так на чём писать кроссплатформенные приложения? Зачастую они создаются на языке разметки и стилей (HTML, CSS и JavaScript), как и мобильные сайты. Логически такой поступок оправдывается тем, что, в конце концов, весь — это . Такие приложения пишутся одновременно для всех платформ и адаптированы к большинству устройств, потому что для их работы в основном используется браузерный движок.
Большинство специалистов, создающих такие приложения, пользуются фреймворком PhoneGap. Его особенность заключается в том, что он позволяет открыть приложению доступ к аппаратным и программным возможностям платформы. Также к технологиям разработки кроссплатформенных приложений относятся Xamarin, Unity и прочие, но они не так популярны, как .
Компания Лайв Тайпинг имеет опыт разработки кроссплатформенных приложений. При создании таких проектов, как Classboom и «Карьера в кармане» мы успешно использовали фреймворк PhoneGap. Ниже — цитата из нашей краткой характеристики технологии для сайта Clutch.
«PhoneGap помог нам создать надёжно работающие кроссплатформенные приложения для iOS и Android. Кроме того, использование PhoneGap снизило время разработки, что повлияло на стоимость приложения для клиента.»
Владислав Коробов, исполнительный директор Live Typing.
Гибридные приложения
Как видно, планка для входа в более чем перспективную область разработки мобильных приложений значительно снизилась. может подумать, что теперь верстальщики, которые не идут дальше проверенных HTML и CSS, будут отнимать хлеб у настоящих программистов. Другие видят за кроссплатформенным подходом будущее, в котором время и затраты на разработку приложений будут полностью оптимизированы. С обеих сторон найдутся аргументы, объясняющие, почему правильным является именно этот, а не другой подход к разработке.
Но когда мы говорим о решении определённых задач, эффективнее будет эти подходы скомбинировать — использовать кроссплатформенные преимущества HTML для оформления контента, а требовательные к скорости отзывчивости меню и элементы управления сделать нативными, затратив на это минимум усилий, времени и бюджета. Такие приложения называются гибридными. В этом случае только объём нативного кода определяет, какому подходу больше соответствует разработка приложения.
Какие ситуации приводят к слиянию подходов? Предположим, что клиенту нужна незатейливая новостная лента, где не будет ничего, кроме текста и изображений. Исходя из этой задачи, разработчик принимает решение использовать кроссплатформенный подход. Но если через некоторое время заказчик пожелает, чтобы приложение хранило большое количество данных или обрабатывало звук и графику, задача усложняется. Для этих целей нужно писать нативный код под каждую конкретную платформу, и некогда полностью кроссплатформенное приложение превращается в гибридное.
Распространено заблуждение, что за любой иконкой на рабочем столе пользователя ждёт нативное приложение. Это заблуждение пустило корни настолько глубоко, что даже в профессиональных кругах грешат формулировками высокого градуса абсурдности вроде «нативное ». Но на рабочий стол можно вывести даже ярлык для сайта, поэтому иконка ничего не гарантирует, и по ту сторону с равной вероятностью может оказаться как нативное приложение, так и любое другое.
Сравнение подходов
Рынок предложений растёт. Статистика продаж мобильных приложений показывает, что год от года пользователи гаджетов всё чаще меняют стандартные сервисы на альтернативные. Так, родной менеджер задач заменяется на Wunderlist, почтовый клиент — на приложение Mailbox, Evernote оказывается предпочтительнее стандартных заметок.
Заказчику важно знать преимущества и недостатки каждого из подходов и не завышать ожидания, делая выбор. Проводить сравнительный анализ будет уместно по ряду критериев.
Зависимость от платформы
Могло сложиться впечатление, что кроссплатформенному приложению комфортно на всех платформах, вплоть до самых непопулярных. Требуется оговорка: чтобы это убеждение соответствовало действительности, под каждую платформу, возможно, придётся писать кусок дополнительного кода. В случае же нативных приложений можно рассчитывать на их отличную работу, но для каждой платформы требуется разрабатывать свою версию.
Дизайн интерфейса
Не затронуть гайдлайны в контексте разработки мобильных приложений невозможно. Гайдлайны — это ценные указания от платформ в адрес разработчиков мобильных приложений, направленные на то, чтобы подогнать их дизайн и функциональность под стандарты. Гайдлайны — это фундамент, на котором зиждется психология и комфорт пользователей платформы. Проще говоря, элементы интерфейса имеют привычный внешний вид и расположение.
Языковая среда, в которой разрабатываются нативные мобильные приложения, обладает необхоимыми инструментами для создания привычного пользователю интерфейса. Другая ситуация с : чтобы сделать кроссплатформенное приложение похожим на нативное, придётся приложить немало усилий. Разные кроссплатформенные фреймворки (Framework 7, Sencha Touch, Kendo UI, Ionic и другие) помогают с той или иной степенью достоверности имитировать нативный интерфейс, но чаще всего отзывчивость, скорость анимации, эффекты и дизайн будут другими. Этому и посвящен следующий пункт.
Пользовательский опыт
Первое, чего на подсознательном уровне ждёт пользователь от своего приложения — это отзывчивости. За действием пользователя тут же следует ответная реакция, прокрутка страницы и анимация протекают плавно и без подвисаний. Кроссплатформенные приложения в этом плане значительно уступают нативным, а если не ходить вокруг да около, они тормозят, и это их главная проблема.
Также пользователь уверен в том, что каждый элемент управления, каждая иконка будут иметь стандартный вид и положение на экране приложения. Для разных платформ эти стандарты будут разными, и если создание кроссплатформенного приложения осуществлялось по гайдлайнам iOS, то пользователям Android это доставит дискомфорт, и наоборот.
Одним из ярчайших примеров может стать кнопка Back: это типичная для Android функция, которая не имеет аналога на iOS. Поэтому, когда вы создаёте кроссплатформенное мобильное приложение, компромиссов в этой ситуации может быть только два: либо дизайн един для обеих платформ, и пользователи одной из них вынуждены приспосабливаться, либо вы создаёте два разных дизайна с учётом особенностей каждой платформы. По сути, во втором случае создаются два приложения, но на одном кроссплатформенном языке.
Ограничения
Нативное приложение, написанное под конкретную платформу, чувствует себя её полноправным обитателем, получая максимальный доступ ко всем устройствам и сервисам устройства. Проектируя кроссплатформенное приложение, разработчик учитывает только возможности фреймворка, налагающего свои ограничения.
Может создать проблему и то, что у фреймворков есть множество версий, и чем старее версия, тем больше ограничений. В любом случае, кроссплатформенному приложению открыты двери далеко не ко всем фишкам платформы. Не всегда возникает необходимость в полной интеграции — её глубина зависит от задач, которые должно решать приложение.
Безопасность
Для всех популярных браузеров существует стандартный безопасный протокол передачи данных — HTTPS. Но если требуется особый уровень шифрования, решение этой проблемы ложится на разработчика. Обеспечение надёжной защиты данных возможно только при нативной разработке мобильных приложений, так как связано с математикой, а подобные операции требуют максимально эффективного использования аппаратных ресурсов.
Обслуживание и поддержка
Комплексное обслуживание нативных Android и (поиск и исправление ошибок, обновление и любое незначительное изменение) в среднем занимает в два раза больше ресурсов по причине необходимости как минимум двух разных специалистов (iOS и Android). С кроссплатформенным приложением может управляться один разработчик.
Стоимость мобильной разработки и затрачиваемом времени опутана заблуждениями и мифами, а потому хотелось бы затронуть эти вопросы отдельно и если не расставить все точки над i, то хотя бы этому поспособствовать.
Быстрая и дешёвая разработка кроссплатформенных приложений — миф или реальность
Кроссплатформенная разработка мобильных приложений обходится дешевле, что объясняется меньшими объёмами работ относительно нативной разработки. Но и здесь есть свои подводные камни, разглядеть которые можно, только поняв принципы ценообразования.
Всегда нужно помнить, что время и стоимость регулируется сложностью и уровнем качества выполнения задачи. Допустим, что для разработки кроссплатформенного продукта у нас есть один специалист, который знает HTML, CSS, JavaScript и имеет опыт работы в PhoneGap. Один специалист — это одна абстрактная единица ресурса (допустим, один ).
Для работы над нативным приложением таких ресурсов требуется два — iOS и Android. В итоге, для завершения нативного проекта требуется два , для завершения кроссплатформенного — полтора.
Справедливым будет вопрос: «Как так — полтора? Почему не один?» Увы, на практике кроссплатформенное приложение, хорошо работающее на iOS, будет плохо работать на Android — у всех браузерных движков своя специфика, и как следствие, оптимизацию под Android может уйти ещё половина .
Исходя из вышесказанного, был произведен расчёт стоимости мобильной разработки в случае нативного и кроссплатформенного подходов, представленный в двух таблицах. Результаты в таблице 1 отталкиваются от средней почасовой ставки фрилансеров из баз freelansim.ru и fl.ru в рублях, в таблице 2 — средней почасовой ставки фрилансеров и студий из международной базы upwork.com в долларах.
Таблица 1
Платформа | Средняя ставка (RUR) | Количество человеко-месяцев | Количество часов | Итого, RUR |
iOS/Android | 800 | 2 | 320 | 256000 |
Гибридные приложения | 800 | 1,5 | 240 | 192000 |
Таблица 2
Платформа | Средняя ставка (USD) | Количество человеко-месяцев | Количество часов | Итого, USD |
iOS/Android | 25 | 2 | 320 | 8000 |
Гибридные приложения | 25 | 1,5 | 240 | 6000 |
Когда мы сравнивали подходы по нескольким критериям, мы сказали, что степень интеграции приложения в платформу обусловлена сложностью задачи, решаемой приложением. Использование того или иного шаблона или готового решения может быть довольно дешевым способом сделать приложение, пока возможностей шаблона или решения достаточно для выполнения конкретной задачи.
Но есть нюанс
И он заключается в структурной особенности приложения. Чаще всего оно предполагает наличие серверной части, куда пользователи приложения сохраняют данные и через которую обмениваются ими с другими пользователями, и она тоже требует финансовых вложений. Работа над ней может занимать до трети всего времени разработки, и оно увеличивается при необходимости создания административной панели для удобного управления данными.
Резюме
К нативной разработке стоит прибегать, если:
- вашему приложению требуется свободный доступ ко всем ресурсам и сервисам телефона;
- вы хотите получить максимально отзывчивое приложение;
- приложение должно уметь работать в офлайне;
- ваше приложение должно максимально эффективно использовать аппаратные части устройства.
Ваш вариант — кроссплатформенная мобильная разработка, если:
- вы готовы примириться с низкой отзывчивостью;
- приложение не предполагает сложной анимации и не занимается расчетами;
- приложению необходим постоянный доступ в интернет, чтобы загружать контент;
- вам нужно быстро выйти на рынок для тестирования идеи;
- у вас есть сайт, и вы хотите обернуть его в приложение за минимальную цену.
К выбору той или иной стратегии всегда приводят индивидуальные обстоятельства, ни одна статья не даёт универсального ответа.
Наш материал скорее дает вводную информацию общего характера, помочь заказчику и разработчику наладить диалог на понятном для обоих языке.
Окончательное решение стоит принимать после консультаций с разработчиками. Чем больше аргументов относительно того или иного подхода вы выслушаете, тем лучше.
Источник: livetyping.com