Comments 119
dp(46 + 21 * 1.5)Куча магических цифр в разметке.
Собственно, любимая плюшка xaml в разных его реализациях — стилизацию умеет?
А с weex почему нет сравнения?
Weex это что? Очередной JS фреймворк? HTML5? Даже сравнивать такое желания нет.
При чем здесь Cordova???
Что я получаю с Kivy?
Почему я вообще начал смотреть на Cordova, вот уже лет 5-10 лет я являюсь адептом теории о том, что почти все с чем сейчас мы имеем дело на компьютере можно упаковать в браузерную версию. Т.е. практически есть один браузер и в нем мы используем все что есть на сегодняшний день.
Я неоднократно убеждался в этом. Google согласились со мной практически придумав операционную систему, где есть практически один браузер Chrome OS.
Для мобилок есть Cordova которая по сути делает именно это.
Что я получаю с Kivy чего нет у Cordova? Почему Вы против HTML+JS в качестве приложений?
В Kivy не нужно придумывать плагины для того, чтобы использовать, например, геолокацию. Если вы пишите под конкретную платформу, которая имеет API для доступа к геолокации, то вы можете на нативном уровне использовать это API. Для каждой платформы имеется интерфейс посредством которого вы получаете доступ ко ВСЕМ нативных библиотекам и можете их использовать в своих проектах на Kivy.
На React Native приложения делают калеки. И если какой-то фреймворк и не нужен, то это именно React Native со своими костылями!
По поводу того же react-native я скажу вам так — всю вашу статью можно заменить на
$ npm install -g create-react-native-app
$ create-react-native-app my-app
$ cd my-app/
$ npm start
И ваша вода вокруг блоков с кодом не потребуется.
Unity 3D также потребует от вас только старта проекта в конструкторе для запуска Hello world.
А вот если бы вы сказали, что «здравствуйте питонисты, теперь мы можем писать приложения на любимом языке», то думаю статья была бы более дружественной и ваш материал оценили бы по достоинству.
всю вашу статью можно заменить на
$ npm install -g create-react-native-app
$ create-react-native-app my-app
$ cd my-app/
$ npm start
Видимо, тоже адепт React Native, да?
Вы писали приложения на Qt под мобильные платформы?
У Qt своих заморочек хватает, но вполне сносно.
Набросал аналог одним файлом:
import QtQuick 2.11
import QtQuick.Window 2.11
import QtQuick.Controls 2.2
import QtQuick.Controls.Material 2.4
ApplicationWindow {
id: window
visible: true
width: 320
height: 480
title: qsTr("Animated Buttons")
Material.theme: Material.Light
Material.primary: Material.Blue
property string currentLanguage: ""
property bool buttonsOpened: false
ListModel {
id: buttonsModel
ListElement {
name: "C++"
icon: "cpp.svg"
}
ListElement {
name: "PHP"
icon: "php.svg"
}
ListElement {
name: "Python"
icon: "python.svg"
}
}
Column {
anchors {
bottom: editButton.top
bottomMargin: 16
horizontalCenter: editButton.horizontalCenter
}
Repeater {
id: repeater
model: buttonsModel
delegate: Item {
id: wrapper
width: 46
height: 46
RoundButton {
id: button
width: 46
height: 46
icon.source: model.icon
Material.elevation: 5
Material.background: Material.Blue
onClicked: currentLanguage = model.name
state: buttonsOpened ? "opened" : "closed"
states: [
State {
name: "opened"
ParentChange { target: button; parent: wrapper; x: 0; y: 0 }
},
State {
name: "closed"
ParentChange { target: button; parent: dock; x: 0; y: 0 }
}
]
transitions: [
Transition {
from: "opened"
to: "closed"
ParentAnimation {
NumberAnimation {
property: "y"
duration: 500
easing.type: Easing.InElastic
}
}
},
Transition {
from: "closed"
to: "opened"
ParentAnimation {
NumberAnimation {
property: "y"
duration: 500
easing.type: Easing.OutElastic
}
}
}
]
}
Rectangle {
id: label
implicitWidth: text.implicitWidth
implicitHeight: text.implicitHeight
anchors.verticalCenter: parent.verticalCenter
color: Material.primary
border.color: "#70000000"
radius: 3
Text {
id: text
leftPadding: 6
rightPadding: 6
anchors.centerIn: parent
font.bold: true
text: model.name
}
state: buttonsOpened ? "opened" : "closed"
states: [
State {
name: "opened"
PropertyChanges { target: label; x: -width - 8 }
},
State {
name: "closed"
PropertyChanges { target: label; x: -width - window.width }
}
]
transitions: [
Transition {
from: "opened"
to: "closed"
NumberAnimation {
property: "x"
duration: 1000 - (repeater.count - index) * 300
easing.type: Easing.InElastic
}
},
Transition {
from: "closed"
to: "opened"
NumberAnimation {
property: "x"
duration: 500 * (repeater.count - index + 1)
easing.type: Easing.OutElastic
}
}
]
}
}
}
}
Item {
id: dock
width: 46
height: 46
anchors.centerIn: editButton
}
RoundButton {
id: editButton
anchors.bottom: parent.bottom
anchors.right: parent.right
width: 56
height: 56
icon.source: "edit.svg"
Material.elevation: 5
Material.background: Material.Blue
onClicked: buttonsOpened = !buttonsOpened
}
Text {
y: window.height / 3
anchors.horizontalCenter: parent.horizontalCenter
textFormat: Text.StyledText
font.bold: true
text: currentLanguage
? qsTr("I program in %1").arg(
"<font color=\"%1\">%2</font>").arg(Material.primary).arg(currentLanguage)
: ""
}
}
Но ведь поддержка мобильных платформ у Qt ужасна же.
A как же Flutter?
Я не видел ни одного приложения на Flutter, кроме примеров. Возможно, потому, что не интересовался этим фреймворком. Так что ничего определенного сказать по этому поводу, увы, не могу.
https://flutter.io/showcase/
Reflectly очень красиво сделанное приложение.
У меня есть несколько интересующих меня вопросов:
- Как тут рисуются все UI элементы? Ведь это не "нативные" платформенные виджеты, да?
- Что с быстродействием, плавностью интерфейса, анимациями, потреблением ресурсов системы? Например, как переваривает построение длинных списков(100+ элементов), или мультимедиа контент внутри списков(видео, gif).
- Какие есть средства отладки и профилирования кода, краш-репортинга?
- Что с кастомизацией виджетов? Насколько гибко построен фреймворк в этом плане? Одними стандартными компонентами сыт не будешь, да и очень редко бывают приложения состоящие только из стандартных элементов. И на iOS свой набор контролов тоже есть.
- Как происходит взаимодействие с API фреймворка OS Android или iOS? Например, доступ к Camera API, Bluetooth API, Wifi, запрос RuntimePermissions и тд.
- Как работать со спецефическими для каждой платформы вещами? Например, с Google Services, Push Notifications, iClound, UI guidelines. Взаимодействие с Java/Kotlin, Swift частью приложения.
- Картографические сервисы, Google Maps, Apple Maps поддерживаются? И как они работают, надеюсь не через WebView?
- Как выполняются python скрипты или они транспилируются во что-то ещё после сборки проекта, какой тут рантайм и размер релизного apk/ipa файла?
- Что с библиотеками для работы с сетью, бд, файлами?
К чему эти вопросы, я хочу понять насколько этот фреймворк подходить для создания "взрослых" приложений, а не приложений для Proof of Concept или визиток.
Банальный пример, средней сложности чат. Где есть и веб-сокеты, работа с бд, камерой, галереей, построение длинного списка с разными типами элементов(сообщения с картинками, видео, текст, эмодзи), пуш нотификации и тд. Иными словами ничего сверхъестественного для нативных приложений и даже для ReactNative или Flutter.
Насколько сложной будет разработка подобного приложения на Kivy?
Спасибо.
Как тут рисуются все UI элементы? Ведь это не "нативные" платформенные виджеты, да?
Да. Это не наивные виджеты, которые выглядят, как нативные. И в этом преимущество Kivy, потому что разработчику не нужно заботится о тонкостях платформы, например, когда при разработке под несколько платформ в нативных контроллах нужно учитывать те или иные свойства или события, которые присущи только конкретной платформе. Это избавляет от необходимости делать костыли. Все это работает очень быстро благодаря тому, что вся графика в Kivy нативно выводится с помощью OpenGl. Сердце же Kivy — это Cython, то есть весь механизм скомпилирован в Си библиотеки.
Что с быстродействием, плавностью интерфейса, анимациями, потреблением ресурсов системы? Например, как переваривает построение длинных списков(100+ элементов), или мультимедиа контент внутри списков(видео, gif).
Интерфейс Kivy отзывчив настолько, насколько отзывчив наивный UI. В некоторых случаях даже превосходит его. Если вы почитаете мои предыдущие статьи, то найдете ответ на эти и многие другие свои вопросы. У Kivy нет проблем с выводом списков даже в 10 000 элементов. Более того такой список будет выведен за одну секунду, чего нельзя сказать, например, о Xamarin. Также в Kivy нет проблем с выводом в списке gif и прочего контента. Есть свои нюансы в работе со списком, которые я описывал в предыдущей своей статье.
Какие есть средства отладки и профилирования кода, краш-репортинга?
Это Python. Поэтому используйте любые привычный инструменты отладки.
Что с кастомизацией виджетов? Насколько гибко построен фреймворк в этом плане? Одними стандартными компонентами сыт не будешь, да и очень редко бывают приложения состоящие только из стандартных элементов. И на iOS свой набор контролов тоже есть.
Вы можете сделать абсолютно любой виджет и контролл, как и кастомизировать стандартный. Пример — библиотека kivymd. Вообще стандартные виджеты Kivy серые и скучные. Но вы ведь этого не заметили, посмотрев скриншоты в этой статье. Всё потому, что Kivy настолько гибкий в этом плане, что вы можете создавать всё, что пожелаете с любой анимацией, трансформацией и кастомизацией.
Как происходит взаимодействие с API фреймворка OS Android или iOS? Например, доступ к Camera API, Bluetooth API, Wifi, запрос RuntimePermissions и тд.
Kivy позволяет использовать системные API как на Android так и на iOS. Камера, WiFi, GPS, работа с Google API, сервисами Google Play- все это доступно.
Как работать со спецефическими для каждой платформы вещами? Например, с Google Services, Push Notifications, iClound, UI guidelines. Взаимодействие с Java/Kotlin, Swift частью приложения.Картографические сервисы, Google Maps, Apple Maps поддерживаются? И как они работают, надеюсь не через WebView?
Для Android API и работы с сервисами Google Kivy использует интерфейс jnius, который позволяет в приложениях Kivy использовать Java API, которое используется в нативных проектах на Android. Поэтому в Kivy все это будет выполняться также на нативном уровне. Для iOS также используются системные API.
Как выполняются python скрипты или они транспилируются во что-то ещё после сборки проекта, какой тут рантайм и размер релизного apk/ipa файла?
Python код всегда останется Python кодом. Вы можете транслировать его в Си расширение при комплиляции пакета, если есть такая необходимость. Размер пакета от 5-6 Мб., если указывайте при сборке, какие библиотеки и файлы вам не нужны. Если не указываете, получаете размер пакета, как и в Xamarin, 10-12 Мб.
Что с библиотеками для работы с сетью, бд, файлами?
Всё, как в Python на десктопе, то есть очень хорошо!
Как-то слишком радостно всё звучит, а есть демо приложение сложнее того что в вашей статье? я хотел бы посмотреть.
Пожалуйста. Смотрите, щупайте:
https://vimeo.com/29348760
https://vimeo.com/206290310
https://vimeo.com/25680681
www.youtube.com/watch?v=u4NRu7mBXtA
www.youtube.com/watch?v=9rk9OQLSoJw
www.youtube.com/watch?v=aa9LXpg_gd0
www.youtube.com/watch?v=FhRXAD8-UkE
www.youtube.com/watch?v=GJ3f88ebDqc&t=111s
www.youtube.com/watch?v=D_M1I9GvpYs
www.youtube.com/watch?v=VotPQafL7Nw
https://youtu.be/-gfwyi7TgLI
https://play.google.com/store/apps/details?id=org.kognitivo.kognitivo
https://play.google.com/store/apps/details?id=net.inclem.pyonicinterpreter
https://play.google.com/store/apps/details?id=com.madhattersoft.guessthequote
https://play.google.com/store/apps/details?id=com.prog.ders.ceyhan
https://play.google.com/store/apps/details?id=com.heattheatr.quotessaints
Всё, как в Python на десктопе, то есть очень хорошо!
это скорее минус, насколько правильно будет использовать десктопные библиотеки на слабом мобильном железе?
Слабом? Вы о чем? Сейчас мобильные устройства по характеристикам не уступают компьютерам. В чем вы здесь нашли минус?
Не все покупают флагманские устройства, есть ещё нижний ценовой сегмент со слабым железом.
Сейчас мобильные устройства по характеристикам не уступают компьютерам
Компьютерам десятилетней давности. Просто физически камень с TDP в 2W не может быть быстрее десктопного с TDP в 100W.
Просто прикрепите к статье какое-нибудь более или менее реальное приложение, что сложнее того что в статье, чтобы можно было так сказать "пощупать" руками как оно работает. Очень интересно разобраться в происходящем. Спасибо.
Это не наивные виджеты, которые выглядят, как нативные. И в этом преимущество KivyВ некоторых случаях, это как раз недостаток. Если есть задача сделать UI приложения максимально приближенное к нативному. В свое время на одном проекте отказались от фреймворков на основе WebView именно по этой причине.
Разве в этой статье приложение выглядит не нативно??? А про то, что это плюс, написано там же. И не путайте Kivy с WebView.
Насколько сложной будет разработка подобного приложения на Kivy?
В любом случае на Kivy это будет в два раза быстрее и проще
Голословные заявления типа «в два раза быстрее и проще», не подкрепленные реальными тестами, цифрами и/или исследованиями.
Я понимаю, что вам тяжело признать, что 'ещё один фреймворк' оставляет далеко позади как React Native так и Xamarin, но возмущаться, размахивать руками, обвинять меня в неуважении к кому-либо и писать в комментариях чушь, будто бы я не привожу доказательств в пользу своих слов — ещё больший маразм и говорит только о том, что вы не можете принять тот факт, который красной линией проходит через мою статью.
А чтобы не оставаться 'голословным', как вы заявляете, я ещё раз приведу пример приложения, которое чуть сложнее, чем 'Hello world' на React Native и аналог на Kivy.
Реализация на React Native — https://medium.com/devschacht/create-devschacht-app-part-2-9fac76563392
Реализация на Kivy (код настолько прост и прозрачен, что я даже не стал прятать его под спойлер):
from kivy.app import App
from kivy.factory import Factory
from kivy.lang import Builder
Builder.load_string("""
<MyButton@Button>:.
background_down: 'button_down.png'
background_normal: 'button_normal.png'
color: 0, 0, 0, 1
bold: True
on_press:
self.parent.parent.ids.textEdit.text = self.text; \
self.color = [.10980392156862745, .5372549019607843, .996078431372549, 1]
on_release:
self.color = [0, 0, 0, 1] .
<MyActivity@BoxLayout>:
orientation: 'vertical'
TextInput:
id: textEdit
BoxLayout:
size_hint_y: None.
height: dp(45)
MyButton:
text: 'Статьи'
MyButton:
text: 'Подкасты'""")
class Program(App):
def build(self):
my_activity = Factory.MyActivity()
return my_activity
Program().run() И один особо ярый фанат React Native заявлял здесь в комментариях, мол, а что, разве React не справился со своей задачей в этом примере? С таким успехом, я могу заявить: а разве бумажные письма не справляются со своей задачей, зачем использовать электронную почту?
вам тяжело признать, что 'ещё один фреймворк' оставляет далеко позади
Что значит «далеко позади»? Мне вот код не нравится, который вы привели. И код из приложения уровня Hello World кодом считать нельзя, мне промышленный кусочек, пожалуйста. Из сложного приложения с разветвленной системой классов, нагруженным сетевым слоем, и так далее. А не «три кнопочки на экране».
обвинять меня в неуважении к кому
Окей, ваши фразы:
— На React Native приложения делают калеки
— как нормальный человек может писать код на React Native
— писать в комментариях чушь
— нужно быть действительно больным человеком, чтобы отрицать убогость React Native
— возмущаться, размахивать руками
Нормальное общение для вас? Хотя я не подал вам ни единого повода наезжать на меня. Возмущаетесь и машете руками здесь только вы. Я с вами общаюсь более, чем спокойно, если вы не заметили.
Почему я говорю, что вы голословны? Потому что вы не привели ни одного бенчмарка, который явно бы доказывал преимущество кодирования на продвигаемом вами фреймворке. Вы приводите лишь простейшие куски кода. А ваши фразы вида
Интерфейс Kivy отзывчив настолько, насколько отзывчив наивный UI. В некоторых случаях даже превосходит его.
В любом случае на Kivy это (разработка) будет в два раза быстрее и проще
простите, и вовсе являются полным «маразмом», выражаясь вашими же словами. Ни одна надстройка не может стать быстрее нативного кода, если сможете доказать обратное — вперед, получать премию. Имею полное право так говорить, так как сам являюсь нативным разработчиком на одной из платформ, и отлично понимаю, что имею в виду. К слову, я вообще не считаю хоть какое-то кроссплатформенное решение более удачным, чем натив, просто натив дороже, поэтому иногда (ИНОГДА) к подобным технологиям полезно прибегнуть.
я ещё раз приведу пример приложения, которое чуть сложнее
Не нужны мне примеры кода. Самым коротким в ряде задач может быть вообще код на ассемблере, что ж с ним-то не сравниваем? Или на брейнфаке том же. Он же еще короче, куда уж круче? Поэтому примеры кода в специфических простейших задачах — это ерунда. Сравнение делается на тяжелых участках кода. При попытках замерить производительность компьютерного железа запускаются тяжелейшие программы, нагружающие его на 100% в течение длительного времени, а не Сапер напополам с Косынкой, так понятна аналогия? Приведите, пожалуйста, цифровые официальные бенчмарки, подтверждающие ваши слова о «скорости». Особенно любопытно посмотреть доказательное сравнение со скоростью работы нативного кода. Ну очень интересно. Иначе это пшик, просто громкие слова.
Очередной JS фреймворк? HTML5? Даже сравнивать такое желания нет.
Раз вы сами пишете, что «нет желания сравнивать», то со всеми имеющимися решениями вы не сравнивали. Поэтому фраза «всегда в два раза быстрее на Kivy» уже не имеет под собой доказательной базы. Л — логика.
На самом деле, нет ничего плохого в том, чтобы считать какую-то технологию лучше другой. Плохо другое: вы сами себя ограничиваете, используя только один инструмент, второе — вы не уважаете коллег по работе (см. выше примеры), третье — вы считаете, что нашли «серебряную пулю», которой в нашем мире не существует, четвертое — вы пользуетесь бездоказательными тезисами (уже описал, почему). Поэтому вы либо тролль, либо еще не работали с по-настоящему сложными проектами, чтобы упираться в какое-то одно «идеальное» решение.
С таким же успехом, я могу заявить, что на ассемблере это делается в 10 раз быстрей. И насрать, что 95% аудитории его не знают. Раз я могу, значит быстрей!
ПС. А какая кроссплатформенность!!!
Ну и наконец главный вопрос. Есть ли разработчики?
Kivy — фреймворк для кроссплатформенной разработки №1
Человека, который делает такие заявления уже нельзя воспринимать всерьез.
Чем хорош Kivy? Во-первых, тем, что это не JavaScript.
Во первых, есть куча крупных приложений на React Native. О крупных приложениях на Kivy Я не слышал.
Во вторых, крупные компании не просто так JavaScript используют в тех или иных проектах. Каждый язык хорош по своему и подходит для решения определенного круга задач. А как показывает практика, компании не считают Python хорошим выбором для разработки кроссплатформенных приложений. Python хорош в нейросетях, в Big data, в работе с текстом.
Так что можно Вас перефразировать: Чем хорош React Native? Тем что это не Python…
Это Python. Поэтому используйте любые привычный инструменты отладки.
А они есть? Я не работаю с питоном, не знаю. Просто смущает уклончивый ответ.
Как видите, все просто, прозрачно и быстро. Боюсь представить, как реализация подобного функционала, учитывая, сколько кода потребовалось автору, чтобы реализовать приложение, типа «Hello World» в этой статье, будет выглядеть на React Native.
export default class App extends React.Component {
render() {
return (
<View style={styles.container}>
<Text>Привет, мир!</Text>
</View>
);
}
}
Вот весь код для вывода «Hello World». Не вижу сложностей.
А в статье описан код более сложного приложения с различными состояниями. Кстати в Вашем коде описана только одна функция тапа. Если будет приложение реализующее ту же логику что и приложение из статьи на медиуме, вполне вероятно что его Kivy реализация будет менее прозрачной и более сложной, чем на реакте.
Да ладно! Не видели приложений на Kivy! Я вот не видел, например, приложений на React Native и что? Python хорош везде. А то, что в мире мобильной кроссплатформы он не так популярен, как говорилось уже в статье, дело только пиара — и только. Холивары на эту тему я здесь не собираюсь устраивать, но нужно быть действительно больным человеком, чтобы отрицать убогость React Native!
Python хорош везде
Аргументы в студию… Чем он хорош? Чем он лучше Java например?
Холивары на эту тему я здесь не собираюсь устраивать.
Заявлениями типа Kivy — фреймворк для кроссплатформенной разработки №1 Вы как раз таки холивар и устраиваете.
нужно быть действительно больным человеком, чтобы отрицать убогость React Native
Ну, например, 1С убог более чем полностью, но тем не менее почему он никуда не делся? Потому что решает свои задачи. Так же как и React Native.
А оскорблять других людей, из-за различий выбранного инструментария, вот это действительно тупо и, более чем красочно, показывает кто вы такой.
Тогда объясните мне, как нормальный человек может писать код на React Native, ссылку на который я дал в статье, а потом заявлять, что этот фреймворк отлично справляется со своими задачами!? +500 строчек кода и две различные технологии для создания подписи на экране с двумя кнопками. Как нормальный человек может отрицать, что аналогичное приложение на Kivy делается за одну минуту в 10 строчек кода и просто отправляет в накаут React Native.! Объясните, может, я чего-то не понимаю? Сколько часов вам потребуется чтобы сделать на React Native то, что реализовано в этой статье? Да и возможно ли такое вообще на фреймворке-калеке?
Тогда объясните мне, как нормальный человек может писать код на React Native, ссылку на который я дал в статье, а потом заявлять, что этот фреймворк отлично справляется со своими задачами!? +500 строчек кода и две различные технологии для создания подписи на экране с двумя кнопками.
Вы какой то неадекватно агрессивный.
Там нет +500 строк.
Да, есть две библиотеки: React и Redux, которые выполняют свои задачи.
Redux нужен только для будущего масштабирования приложения, чтобы управлять состояниями. Можно и без него сделать, просто автор старается реализовать best practice. А свою задачу приложение разве не сделало? На мой взгляд всё просто и понятно.
Как нормальный человек может отрицать, что аналогичное приложение на Kivy делается за одну минуту в 10 строчек кода и просто отправляет в накаут React Native.! Объясните, может, я чего-то не понимаю?
Вы батюшка пустозвон. 10 строк? У Вас кнопка с одним тапом и парой иконок уже вышла за 10 строк. Причем всё захардкожено.
Да, Вы много не понимаете и понимать не хотите. Сначала даете ссылку и говорите что там только hello world, видимо рассчитывая что никто читать не станет.
Затем говорите что там +500 строк, хотя это не так.
Затем, оказывается, Вы можете реализовать такое приложение всего в 10 строк, хотя это тоже не так.
Обвиняете всех, кто работает на неугодной Вам технологии ненормальными.
Вам бы к психологу.
Да пишите, хоть на клинописе, ради Бога!
Я прошу реальных аргументов в пользу Kivy.
Уточню, реальных — значит конкретный пример, где Kivy справляется лучше чем React Native. Без преувеличений сложности React-а, без оскорблений реакт комьюнити и с конкретным обоснованием, чем именно код на Kivy будет лучше кода на реакте.
Вот если бы Вы реализовали на Kivy такое же приложение, которое делает автор на медиуме (ссылка из Вашей статьи), затем сравнили бы код, сравнили производительность, сравнили сложность отладки и будущего масштабирования, тогда бы получилось очень наглядно. А так — Ваша статья просто
По поводу Xamarin-а ничего не говорю, просто у самого личная неприязнь к данному продукту.
По поводу Xamarin-а ничего не говорю, просто у самого личная неприязнь к данному продукту.
Я так и понял, что вы 'посол' от React Native. В предыдущей статье я более, чем наглядно показал насколько React Native жалок. И достаточно убедительно показал превосходство Kivy. Но лично тебе, как приверженцу React Native всё равно, что я написал и какие аргументы привел. Поэтому предлагаю пинать воздух в другом месте.
on_press:
self.parent.parent.ids.textEdit.text = self.text; \Я бы хотел увидеть как Вы таким макаром напишите хоть сколько нибудь крупное приложение. И как это потом кто-то будет отлаживать, когда что-то изменится.
Тот код, которое вы якобы уличили в излишней сложности, масштабируется очень и очень комфортно. Но вы дальше простеньких приложений из 2 экранов ничего не видите.
Поэтому предлагаю пинать воздух в другом месте.
Ни конкретных примеров чем Kivy лучше, ни обоснований Вашей правоты. Действительно, тут обсуждать даже нечего.
Хотите поклоняться Kivy, распечатайте на бумажке и молитесь, а делать заявления типа Kivy — фреймворк для кроссплатформенной разработки №1! не надо.
Например предмет вашей гордости на ReactNative реализуется так docs.nativebase.io/Components.html#fabs-def-headref
Я рекомендовал бы вам прежде чем что то утверждать, хотя бы немного разобраться в теме.
Не понимаю, а зачем вы привели ссылку на компоненты Native Base???
Серьезно?)))
Средства отладки для Python есть. Начиная от хороших библиотек для unit-тестирования до системы опциональной аннотации типов с проверкой соответствия до запуска. Я уже не говорю про всяческие linter'ы, profiler'ы, возможность скомпилировать интерпретатор Python с спец. флагами и выводить всякую интересную статистику…
Ваша логика мне непонятна — «Python хорош в нейросетях, в Big data, в работе с текстом. ». И всё? И, типа, не лезь больше никуда? Python может ВСЁ, что может Node.js. Кстати, не обязательно использовать CPython, есть и другие интерпретаторы, некоторые (PyPy) быстрее в разы.
Почему мы должны смотреть на крупные компании? Во-первых у них ДРУГИЕ проблемы и возможности, чем у 99% остальных компаний. Во-вторых они уже подарили миру Java — крупная компания Sun очень торопилась выпустить недоделанный язык (Алан Кей говорит, что у них были правильные люди (Guy Steele), но, похоже, что давил отдел продаж), а другие крупные компании «купили» эту Java и породили целую эпоху беснования с неправильном понятым ООП.
Примерно такими же абсурдными соображениями (переиспользование кода и людей) сейчас продвигается Javascript для разработки чего-то кроме сайтов. «Фронтендеры смогут делать бэкенд. Фронтендеры смогут писать для микроконтроллеров, приложения с GUI для десктопа, ...» Так не бывает.
Ваша логика мне непонятна — «Python хорош в нейросетях, в Big data, в работе с текстом. ». И всё? И, типа, не лезь больше никуда? Python может ВСЁ, что может Node.js.
Я не прошу «не лезть», и конечно он может всё. Я всего лишь говорю что с нейросетями и Big Data он лучше справляется чем другие, но вот для остального, на мой взгляд, есть более подходящие инструменты.
Почему мы должны смотреть на крупные компании? Во-первых у них ДРУГИЕ проблемы и возможности, чем у 99% остальных компаний.
Любая крупная компания была когда то небольшой и они явно уже сталкивались с проблемами, с которыми сталкиваются более мелкие компании. Соответственно если они сделали какой-то выбор, значит на то была причина, которую можно найти, ознакомившись с их опытом. Но если Вы любите сами наступать на все грабли и учиться исключительно на собственном опыте — дело Ваше.
«Фронтендеры смогут делать бэкенд. Фронтендеры смогут писать для микроконтроллеров, приложения с GUI для десктопа, ...» Так не бывает.
Как не бывает, если уже есть?
Примерно такими же абсурдными соображениями (переиспользование кода и людей)
Что абсурдного в переиспользовании кода?
Любая крупная компания была когда то небольшой и они явно уже сталкивались с проблемами, с которыми сталкиваются более мелкие компании.
Да, а потом проблемы стали другими и решения стали другими. И те решения, которые они принимают сейчас, не имеют ничего общего с решениями, которые они принимали, когда были маленькими и которые стоит принимать другим компаниям поменьше.
Все эти извращения с JS на микроконтроллерах (и каким бы то ни было другим некомпилируемым языком) обусловлены только жестоким дефицитом кадров. Только вот если мне нужно будет разрабатывать какую-нибудь embedded-систему, я предпочту хорошего программиста на Си десятку джаваскриптеров. И вообще: для профессионала не проблема знать несколько языков. Как говорил Бьярне Строуструп в одном американском университете: «если вы хотите быть в индустрии, то должны знать минимум 2 языка, лучше 5, может быть ещё несколько».
Переиспользование кода — это отлично, если сделано правильно. Т.е. не так как в npm. «Качество» его пакетов и история с leftpad уже стали мемами.
Единственное что стало мемом – это вес node_modules.
Да, а потом проблемы стали другими и решения стали другими. И те решения, которые они принимают сейчас, не имеют ничего общего с решениями, которые они принимали, когда были маленькими и которые стоит принимать другим компаниям поменьше.
Батюшка, факты в студию. Какая техническая проблема есть у маленькой компании, которая не актуальна для крупной компании?
Абстрактно можно говорить о чем угодно и выдавать себя за умного, это как говорится: «На словах ты Лев Толстой, а на деле ### простой.»
Все эти извращения с JS на микроконтроллерах (и каким бы то ни было другим некомпилируемым языком) обусловлены только жестоким дефицитом кадров.
С такой логикой – зачем тогда высокоуровневые языки? Пишите на ассемблере. А все ваши Си и Питоны только из-за дефицита кадров, Я предпочту хорошего программиста на Ассемблере десятку си-шников.
И вообще: для профессионала не проблема знать несколько языков.
Конечно не проблема, вопрос в скорости, удобстве, возможностях и требованиях инструмента. А конкретно в этом посте говорится что нужно использовать только Kivy, а все остальные — калеки недоразвитые (со слов автора).
Даже, кошмар, кошмар, сам создатель Node.js Райан Дал сказал такую страшную вещь:
I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
Подробнее — см. видео с конференции
ЯП они как правило после набора критической массы живут своей жизнью. Nodejs это давно уже не личный проект Райна. Пока ЯП удовлетворяет требованиям его используют, до сих пор есть востребованность в COBOL программистах.
Кто то уходит с Node, кто то приходит. Это нормально…
Давайте согласимся, что дело в соотвествии языка предполагаемым задачам, прямых руках (квалификации команды) и грамотной архитектуре.
Не отрицаю того факта, что V8 быстрее CPython. Но есть же PyPy. И если уж сравнивать языки программирования, то надо сравнивать не в лоб, а идиоматический код, решающий одинаковую задачу.
Во-вторых они уже подарили миру Java
Так, и что? Что с ней не так?
абсурдными соображениями (переиспользование кода и людей)
А с этим какие проблемы вообще?
Почему мы должны смотреть на крупные компании?
На том же реакт нейтиве пишут делают приложения не только большие компании. И это прекрасно, что он подходит и для тех и для других.
Залез в вики, доставил зависимости. Заработал. Ну, ок. Собрал exe через pyinstaller. Exe не заработал. Поставил зависимости и дизайнер. Запустил. Не заработал.
Мобильной разработкой не интересуюсь, но для настольных приложений QT будет проще.
Некоторые и Qt установить не могут. Я не говорю уже о том, чтобы собрать exe с ним. Я видел вопросы на stackoverflow касающиеся сборки с Qt. С каждым инструментом нужно разобраться. Что лучше каждый решает для себя сам.
Файл floatingactionsbuttons.kv описывает разметку UI элементов на специальном языке Kv Language, который намного проще и понятней, чем XAML в Xamarin, xml в Java или JSX-разметке в React Native.
Открыл пример и начал смеяться… Вы серьезно? 50+ строк описывает 4 кнопки.
Фреймворк может быть и не плох но вот эта статья выглядит как анти-реклама.
Четыре кнопки и три подписи. Чтобы не вводить людей в заблуждение и дать мне повод посмеяться тоже, покажите, как будет выглядеть разметка подобного UI с аналогичной стилистикой на другой разметке. Вам же, очевидно, есть, с чем сравнивать!?
Я сам выбираю фреймворк для мобильной разработки. Xamarin даже не рассматриваю. Но от Kivy подобное описание UI скорее отталкивает. И оно явно не проще чем jsx.
особенно в кроссплатформенности?
и что с датчиками телефона? положение, компас…
что со стыковкой нативного кода? т.е. я хочу вызывать свинговые функции под яблоком, джаву под андроидом и виндовое апи под виндой. никто же, надеюсь, не верит что получится жить полностью абстрагируясь от специфики платформы?
Kivy поддерживает все нативные коммуникации телефона. Тач, мультитач, синий зуб, компас. Да, полностью абстрагироваться от платформы не получится. В любом случае приходится смотреть, на какой платформе запущен код, если вы, например, хотите использовать камеру в своём приложении.
Скажем, блютус-чат и считывание параметров браслета-напульсника с ble?
В следующей статье обязательно приведу примеры работы с синим зубом, думаю, другим тоже будет интересно.
заранее спасибо.
Хорошо. Впрочем, я уже сейчас могу сказать, что проблем с BLE на Android нет никаких. А насчет iOS… Разве там есть возможность пользоваться синим зубом?
Вот как с таким уровнем знания ...
Вы, очевидно, знакомы со всеми доступными API обеих платформ, не так ли?! :D
Разумеется, нет. Ну, так, в отличие от вас, я и не делаю таких громких заявлений, одновременно показывая, что не разбираюсь в теме
То есть, все-таки не разбираетесь в теме независимо от того делаете вы какие-то заявления или нет, я правильно понимаю?! Будем дальше пинать воздух?
Мне нужен пример работающего проекта, платформенно независимый, на вашем фреймворке и вашем языке (питон у вас? ну пусть питон и будет), который умеет работать с BLE.
Описание процесса сборки этого проекта под андроидом и под яблоком. Причем в последнем варианте так же сильно интересует процесс сборки и подписания вашего изделия в xcode временными ключами разработчика. И последнее не менее важно, потому что я собирал на огрызке проекты на LibGDX и C++\Qt — и в обоих случах сценарий стыковки проекта с механизмами подписания был не самым тривиальным и разным — потому очень интересует как это делать у вас.
Ждем от вас публикации.
Спасибо.
ЗЫ: и да, демки работы с BLE на C++\Qt я вчера таки собрал и запустил на огрызке. огрызок правда 5-й или 4-й, но на халяву другого не досталось). Теперь ход за вами — ждем аналогичной демки на Kivy.
Чуть подробнее о недостатках.
1) Собственный DSL для создания интерфейса который в ИДЕ и текстовых редакторах имеет максимум подсветку синтаксиса (автодополнение, какие-либо еще полезные плюшки не видел). При сравнении с Xamarin, JS-based фреймворках это очень солидный проигрыш. Опытных людей это не отпугнет. Не опытных — отпугнет. Плюс — это влияет на скорость разработки, что в наше время тоже очень важный фактор.
2) У js фреймворков чаще всего есть консольная утилита для создания проектов, запуска проектов и т.п. Насчет Xamarin — не знаю. Что по этому поводу может сказать Kivy? И если, что то может сказать, то где это есть в документации? (спойлер — некоторое время назад ответ был ничего не может сказать/ нужно искать, тщательно искать, что то самому)
3) Сборка проекта. См. предыдущий пункт, только тут еще накладываются особенности питона. Гугл так и пестрит вопросами «Как собрать питон программу под Виндовс?», «Не могу собрать питон программу под виндовс?». Может это все кривые руки у людей, но все же.
4) Некоторые баги проекта, которые висят достаточно долго без исправлений, причем ощутимые баги которые не исправляются долго, по тем или иным причинам (я знаю, что этим страдают все), но есть конкретный пример, когда баг висел три года и возможно был исправлен костылем, предотвращающим ошибку.
Самым главным недостатком я считаю пожалуй собственный DSL, в коде парсера которого разбираются далеко не все основные разработчики.
Из хорошего — можно использовать большинство библиотек питона без каких-либо проблема (написанные с использование C++ и т.п. нужно дополнительно обработать), работает написанное дело весьма неплохо, красивые вещи получить можно, есть написанные вещи которые работают в реальных условиях и работают весьма стабильно, и люди довольны выбором инструмента для написания.
Подводя итог — киви не взлетел. У реакт натива и js-based вещей есть огромное множество js разработчиков, популярность самого языка и неверное простота работы и дешевизна рабочей силы, крупные компании которые это понимают, с xamarin — похожая ситуация, только тут Майкрософт сильнее постарался. А что есть у киви?
По поводу Реакт натива (js) и Xamarin (.Net). Это все другие экосистемы, со своими особенностями. Они пытаются делать что-то кросплатформенное, ну и питон тоже хочет. Тут вон посмотрим на котлин, где разработчики языка быстро поняли, что нужно, чтобы на их языке могли писать под все, go тудаже. Каждый язык — своя экосистема, и переход между ними может быть сложен и болезненен.
Лидером считаю js, несмотря на его бардак с библиотеками (тот же питон имеющий свои особенности в этом плане смотрится гораздо лучше), в частности особенности reacta когда полноценное приложение c react-router, redux, самое минимальное, может быть размазано по куче файлов, в которых постороннему человеку разобраться сложно (с реактом пытался начать дружить раза 3).
Автору желаю не сдаваться в его нелегком деле.
Собственный DSL для создания интерфейса который в ИДЕ и текстовых редакторах имеет максимум подсветку синтаксиса (автодополнение, какие-либо еще полезные плюшки не видел).
Да? А я вот использую плагин в PyCharm для автодополнения — https://github.com/kivy/kivy/wiki/Setting-Up-Kivy-with-various-popular-IDE's
2) У js фреймворков чаще всего есть консольная утилита для создания проектов, запуска проектов и т.п.
Пожалуйста — https://github.com/HeaTTheatR/CreatorKivyProject
В начале статьи об этом писалось
Некоторые баги проекта, которые висят достаточно долго без исправлений, причем ощутимые баги которые не исправляются долго, по тем или иным причинам (я знаю, что этим страдают все), но есть конкретный пример, когда баг висел три года и возможно был исправлен костылем, предотвращающим ошибку.
Назовите такие баги, а то я пять лет использую Kivy и аж интересно стало.
Автору желаю не сдаваться в его нелегком деле.
Автор не сдается. Причина того, что Kivy не так популярен среди других фреймворков — пиар. Семь человек, которые пилят Kivy с 2011 года явно не имеют такой материальной поддержки на раскрутку своего проекта, как 'дети' Microsoft и Facebook — Xamarin и React Native.
Во всех своих статьях я рассказываю, что с помощью Kivy можно реализовать приложение в два раза быстрее и с меньшим количеством сил/людей/инструментов, чем на React Native и Xamarin с идентичным функционалом. На платформы я не 'наезжал'. На фреймворки — да. И, опять же, зачем вы врете себе и людям: то, что описано в этой статье — это не Hello, world.
Под платформами я и имел в виду фреймворки :)
Приложение с тремя анимированными кнопками и реакцией на нажатие на них… это гораздо ближе к Hello World, чем к реальным приложениям.
Ну люди не обязательно читают все статьи. Я вот читал только эту.
Спасибо. Я изменю формат своих статей.
Приложение с тремя анимированными кнопками и реакцией на нажатие на них...
А вы хотели, чтобы я привел пример создания полноценного приложения от и до? Пожалуйста, предложите такое приложение и мы сделаем эксперимент: Kivy VS React Native/Xamarin. Думаю, читателям будет интересно.
Грубо говоря, если я щас на формсах напишу такой же пример, при этом любому WPF-нику он будет понятнее, чем ваш код, просто банально в силу более привычного синтаксиса и почти того же фреймворка, то я докажу что Xamarin — фреймворк №1? Нет, я просто напишу анимированные кнопки, не более того :)
Я только за. Найти бы напарника для такого эксперимента, который согласился бы взяться за разработку на другом фреймворке.
положили, просто напишите на Kivy Todo лист и положите туда
Kivy — фреймворк для кроссплатформенной разработки №1