greenpixdev / hitsandroid Goto Github PK

Задача: сделать блоки проверки вхождения регулярного выражения в строке и поиск первого вхождения в строке (как делать узлы и блоки, см. #29).

1) Scratch online (Web):

• Императивный, последовательность выполнения команд
• Обычные блоки
  https://scratch.mit.edu/
  

2) ScratchJr (Android):

• Императивный, последовательность выполнения команд
• Блоки в виде пазлов
  https://play.google.com/store/apps/details?id=org.scratchjr.android&hl=ru&gl=US
  

3) Blueprint (Unreal Engine 4)

• Функциональный (поправьте, если нет)
• Элементы связаны потоками данных и линиями вызова
• Удобнее пользователю для планшетов и телефонов (субъективное мнение Ромы)
• Более абстрактный и расширяемый (напишу об этом в отдельной issue)
• Есть проблемы в реализации с последовательностью выполнения команд
  https://www.youtube.com/watch?v=1W5ozPoJkt8&ab_channel=UnrealEngineRus
  

Когда я соединяю пин с пином, у которого задана константа, то приложение крашается

1. Задача: набросать 2 варианта макета приложения

• Scratch (вертикальная ориентация)
• Blueprint (вертикальная и горизонтальная ориентация)

2. Придумать и набросать макет смеси предыдущих двух вариантов

Результаты отправить сюда

Есть ветка Вани feature/lines, где есть вьюшка с отрисовкой линии.
Нужно интегрировать её с пинами у блоков

Общее:

• Императивный визуальный язык программирования
• Алгоритмическая сложность реализации: Легко (баллов меньше)

Что поддерживает оригинал?

• События в качестве входных точек
  
• Объявление глобальных переменных (целые и вещественные числа, текст и boolean)
  
  
• Арифметические операторы в виде блоков
  
• Условия if, else, а также логические операторы
  
• Циклы while, for
  
  
• Прерывания ("ждать n секунд")
  
• Объявление и вызов своих процедур (функций нет)
  
• Списки в качестве структуры данных
  
  

Преимущества:

• Легко реализуется, т.к. императивный (т.е. последовательное выполнение команд), можно провести аналогии с обычными языками программирования
• Простой дизайн, который можно совершенствовать
• 100% успеем сделать

Недостатки:

• Хорошо смотрится только на вертикальной ориентации телефона
• Нет организации потоковых данных (это черный конверт)
• Большинство сделает ИМЕННО этот вариант, а значит нам не удивить Змеева и Лидию
• Переменные глобальные. Можно добавить область видимости, но это ещё больше сделает код нечитабельным, а дизайн хуже.
• Вложенность аргументов выглядит очень плохо, когда аргументы сложные (пример в скриншоте). На экран не влезит.
  

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

Не забываем, что мы делаем черный конверт.

Крашается

Одна из сложнейших задач интерпретатора.

Задача: сделать кастомный тип переменных, у которого внутри могут быть поля (и методы по возможности)

Наследование вообще под звездочкой.

Задача: сделать сохранение кода в файл и возможность записывать в Intent android'а, а также загрузку кода.

Один из вариантов - сделать сериализацию всех объектов. Этот вопрос нужно изучить (если что, писать Роме)

Сериализовывать нужно все классы от интерфейса AxolotSource

В интерпретатор уже заложен механизм многопоточности, т.к. у каждого стека есть свой стек.

Задача: сделать узел асинхронности

• Запретить пользователю создавать переменную с уже существующим именем (сообщать это пользователю через toast)
• Если пользователь не задал имя для переменной, то нужно сгенерировать уникальное имя для этой переменной (var1, var2,...)
• Запретить изменение EditTextView после создания переменной
• В соответствующем EditTextView после создания переменной будет хранится название этой переменной

Общее:

• Функционально-императивный визуальный язык программирования
• Алгоритмическая сложность реализации: Сложно (баллов больше)

Что поддерживает оригинал?

• События в качестве входных точек
  
• Объявление глобальных переменных
  • Boolean (true/false)
  • Целые числа
  • Вещественные числа
  • Строки
  • Vector (x,y,z)
  • Rotation (x,y,z)
  • Transform (x,y,z)
  • Свои структуры (structure), классы (class), интерфейсы (interface) и перечисления (enum)
    
    
• Арифметические операторы в виде блоков и текстовых выражений
  
  
• Условия if else в виде ветвления, а также логические операторы
  
• Циклы while foreach в виде ветвления
  
  
• Объявление и вызов своих процедур и функций
  
  
• Различные структуры данных (массивы, множества и словари)
  

Принцип работы непоследовательных команд:

• По сути у нас есть граф блоков, по которому нам нужно пройти
• Задача состоит в том, чтобы просто обойти наше дерево по определенном правилам
• Если нам нужен какой-то параметр в функции, то мы просто уходим в глубину
  

Преимущества:

• Хорошо смотрится как вертикальной, так и горизонтальной ориентации телефона
• Есть организация потоковых данных (черный конверт)
• Мало человек сделает этот вариант (ну или доделает до конца), так как он сложнее, чем Scratch. Потенциальный шанс набрать очень много баллов.

Недостатки:

• Переменные глобальные. Можно добавить область видимости, но это ещё больше сделает код нечитабельным, а дизайн хуже.
• Проблема с последовательностью выполнения команд. В этом нет ничего страшного, но непонятно, как быть с петлями.
  
• Если допускать существование функций с парой выводов, то непонятно, как сделать, чтобы функция вызывался только ОДИН раз, но при этом возвращала все результаты. Если опираться на принцип работы, то функция вызывается столько же раз, сколько и выводов.
  

На вход должна подаваться строка, на выход float число (как делать узлы и блоки, см. #29).

Переменные берешь из scope (для этого его надо немного изменить)

interface Scope {
    
    val variables: Map<String, Variable>

}

class GlobalScope : Scope {

    override val variables: MutableMap<String, Variable> = mutableMapOf()

}

Потом просто фильтруешь нужные тебе переменные и закидываешь к себе в интерпретатор мат. выражений

val map = scope.variables
    .filterValues { it.type == Type.INT || it.type == Type.Float }
    .filterKeys { /* проверка названий переменных */ }
    .mapValues { it.value.value }
    .filterValuesNotNull()

На вход строка мат. выражения и мапа с переменными. Тебе надо еë распарсить (в польскую запись, например) и посчитать результат мат. выражения. Мини интерпретатор для мат. выражений, короче

Тута делай как угодно, для меня лишь сделай интерфейс с функцией

interface MathInterpreter {

    fun calcExpression(expression: String, variables: Map<String, Double>): Double

}

Там должны быть операторы:

• Скобки ()
• /
• ℅
• Побитовое или |
• Побитовое и &
• Побитовый XOR ^ (или функция xor, если ^ оставить для степени)
• Побитовое дополнение ~
• Побитовые сдвиги >> и <<
• Побитовый сдвиг с переносом >>>
• sin
• cos
• tan
• arcsin
• arccos
• arctan
• log
• ln
• lg
• sqrt
• И прочее по твоему усмотрению

Задачи:

• Реализовать глобальные переменные
• Реализовать базовые нативные процедуры (вывод в консоль, присваивание переменной значения и т.д.)
• Реализовать базовые нативные функции (получение значения переменной, преобразование типов и т.д.)
• Реализовать базовые нативные узлы для управления веткой (разветвление if-else, последовательность выполнения sequence)
• Реализовать глобальные функции, процедуры и макросы
• Реализовать объявление функций, процедур и макросов
• Реализовать вызов функций, процедур и макросов
• Написать макросы while, for, for-break, increment на нашем же языке.
• Реализовать классы и объекты
• Наследование?)))
• Многопоточность?))))

Чистый код:

• Это касается жизненного цикла android приложения и ООП. Разобраться, как писать код НЕЛЬЗЯ и как НУЖНО его писать, чтобы Лидия была в восторге от нас.

По фичам:

1. В нашем приложении будет несколько окон (или же страничек/менюшек):

• файловый менеджер,
• менюшка с визуальными блоками (элементами)
• сам графический редактор
• ввод/вывод (консоль)
  Разобраться, как сделать, чтобы можно было листать окна в телефоне (вправо/влево ну и вверх/вниз):

2. Понять, как сделать так, чтобы при повороте телефона экран переворачивался, а наше приложение подстраивалось (т.е. в вертикальной ориентации приложение будет показывать нам графические элементы иначе, нежели в горизонтальной ориентации)
3. Разобраться, как сделать несколько тем (темную и светлую)
4. У нас в графическом редакторе может быть много блоков. Ооочень. Надо понять, как сделать увеличение пальчиками на телефоне.

Какие-либо выводы закрепляй сюда

1. Добавить к PinView (pin_item.xml) поле для ввода.
   Это поле может иметь 1 из 4 типов данных. Разрешаю определения типа сделать через when

• Boolean - выглядит как галочка, сделать прослушку на изменение галочки с TODO, по умолчанию false
• Int - поле ввода для целых чисел, сделать прослушку на изменение галочки с TODO, по умолчанию 0
• Float - поле ввода для дробных чисел, сделать прослушку на изменение галочки с TODO, по умолчанию 0.0
• Для остальных (else) - поле ввода строки, сделать прослушку на изменение галочки с TODO, по умолчанию пустая строка
  Это поле должно становиться невидимым, если пин соединен! Сделаете это через visiable (или как там), не через removeView(). ЧТОБЫ РАЗМЕР БЛОКА НЕ УМЕНЬШАЛСЯ!
  Плюсы - нет ООП и проше
  Минусы - сложнее кликнуть по полю ввода

2. Сделать отдельный блок, но вы НЕ делаете его! Вы делаете только PinView.
   Конкретно: PinView должен быть abstract, оставляете там общую логику (методы, свойства). Не забудьте удалить из PinView PinItemBinding.
   Далее создаете 2 новых вью, которые наследуют PinView (соответственно и два новых xml) и там будет различие только в том, что в обычных вьюшках будет их название (пинов), а в константных вьюшках будет поле для ввода (и его аналогично как в первом пункте).
   Плюсы - это выглядит более правильным
   Минус - тогда у нас несоединенные пины ввода (например в print string пин text) будет ломаться во время выполнения нашей программе (будут ошибки, и приложение падает)

• сделать темную тему
• стили всех вьюшек

Что нужно пофиксить:

• При изменении размера блока BlockView, линия EdgeView не изменяется
  
• Имя переменной должно быть уникальным, иначе приложение падает. Причем оно должно по умолчанию генерироваться для новых переменных.
  
• Сделать выполнение программы в отдельном потоке, чтобы приложение не зависало

Потом распишу)

Наш интерпретатор работает очень медленно.

Варианты оптимизации:

• Заменить hashmap в зависимостях у узлов на массив (легко)
• Вернуться к от сервисов к самоисполняющейся структуре (средне)
• Минимизировать количество проектов, сделать минимум элементарных шагов в invoke у узлов. При этом как-то эти проверки сохранить?!?! (сложно)
• Заменить hashmap в стеке на массив и на этапе компиляции индексировать названия переменных (очень сложно)