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

Netspirit, посмотри пожалуйста ЛС.

Доброго дня! Большое спасибо разработчикам этого пакета! Недавно начал его изучение и столкнулся с небольшой проблемой, не хватает простенького примера сохранения фотографий в файл с компонента Camera.

Здравствуйте! Начал вот изучать пакет Android, уже пол программы написал и столкнулся с проблемой в компоненте Environment, такое впечатление что код для точек с которых выдаются данные по директориям просто не добавляется в исходник на java, причем import-ы добавляются, а точки нет. Вот код примера, при компиляции выдает сразу ошибку:
[javac] Compiling 4 source files to F:\Redirect\HiAsm\Elements\android\code\result\bin\classes
[javac] F:\Redirect\HiAsm\Elements\android\code\result\src\hiasm\hiasmproject\HiasmMain.java:22: error: illegal start of expression
[javac] adlg3.setMessage(.concat("/KGR"));
[javac] ^
Т.е. как бы нету Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_...).concat("/KGR")


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

Там в StrCat не предусмотрена обработка, когда на вход подаются неконвертируемые в строку данные.
Поправил, выложу на SVN (когда тот будет доступен, либо архивом).
А суть такая. Компонент Environment выдаёт каталоги не в виде их пути, а в виде объекта File. Этот объект представляет собой объект файловой системы (файл, каталог). Работа с таким объектом ведется, например, в компоненте File. А компонент FileOperations имеет отдельные точки для указания пути строкой, либо объекта типа File. Из объекта File можно получить путь в виде строки, из строки можно сконструировать объект File. Пока что эти два подхода используется попеременно. Более оптимальный вариант ещё не выработан. Неэффективно работать с путями в виде строки - будет лишняя конвертация в File и обратно.


В твоем случае из объекта File нужно получить путь, типа так:

Спасибо за ответ и за схемку, тогда сразу спрошу то ради чего я начал мучать компонент Environment - а как создать папку в каталоге полученном из Environment? Вот получили мы строку добавили к ней /KGR и теперь надо например с помощью doMakeDir компонента hFile создать папку, но там на входе должен быть класс File явы... Тобишь обратная конвертация снова нужна... В hFile есть точка File, но как засунуть в его mfile новый путь в виде строки (точка данных Path используется только в doOpen)? Я подозреваю создание новой папки решается как то через другие компоненты.
После того как я задал предыдущий вопрос и долго изучая hFile и hEnvironment я вообщем то допер про класс File, почитал про него и сваял эксперементальный вариант этих компонент которые используют пути в виде строк на выходе этих компонент в классе HiasmMain получается вот так:
mfile4= new File(Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS).getAbsolutePath().concat("/KGR"));
boolean mdr4 = mfile4.mkdirs();
Все вроде бы верно (если смотреть полученный путь он верен) и как в других примерах на java для класса File, но... в BlueStack (стандартный эмулятор не запускается - AMD? Win7) mdr4 всегда false и папка не создается, кстати все примеры работы с файлами тоже выдают ошибку. Подозрение что нет прав, если смотреть manifest.xml в Code/Result там вроде нет вообще раздела вида
uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"...
Подскажите что не так? Надо руками вписывать? компоненты перебирал вроде нет ничего типа permisson sаmakacd-да (ссылка из первого поста на его компоненты не работает...) ни типа manifest...

--- Добавлено в 2017-03-31 18:28:16

Добавил в свой вариант hFile
PermissionRequired('android.permission.WRITE_EXTERNAL_STORAGE'), по аналогии с компонентом браузера и все заработало по крайней мере со строковым вариантом.
Но как же все-таки создавать новую папку с нужным путем с помощью стандартных компонент (все-таки переписывать даже эти два компонента под себя не конструктивно как то)?
И как другие обходятся без PermissionRequired в стандартных компонентах при работе с файловой системой? Каким компонентом можно рулить правами доступа к ресурсам телефона?

Редактировалось 1 раз(а), последний 2017-03-31 18:28:16

А если посмотреть на метод doOpen, то это и есть

То-есть, подаешь путь, делаешь doOpen, получаешь объект File на выходе с точки File. А к нему уже применяешь mkdirs(), а точнее, в компоненте File уже есть метод doMakeDir)

Ну, а с добавлением разрешений ты разобрался. Я, правда, не помню, почему компоненты работы с файлами не прописывают никаких разрешений - что-то я упустил.

Хех я тоже это вчера обнаружил, когда дописывал свой "велосипед" (свои варианты компонентов file и Environment), шел снизу вверх по файлу и когда дошло до модификации этой функции увидел что она оказывается просто переменную класса File создает...
По-моему большинство людей вжисть не догадаются что doOpen это не открытие файла, а создание файловой переменной )), это можно узнать только открыв исходних и зная java + FTCG. Может doOpen переименовать в doCreateFileVar, а GetStreams в doOpen?
Выложи пожалуйста поправленный компонент Environment здесь. Чтобы не ждать SVN... Ну или хотя бы что там надо дописать.

А там ничего не правилось - разве что полностью переделывать для какой-то новой концепции. StrCat поправлен на SVN.

Нужна справка. Но описание метода doOpen, по-моему, достаточно информативное. И у компонента FileReadWrite тоже. Есть и пример.

Ну ладно вам виднее , но отождествление смыслов открыть и создать, даже на разных языках путает...
У FileReadWrite точка более понятно подписана - указание конкретного типа сразу настораживает и заставляет задуматься . Меня кстати поставило в тупик в том числе то что у компонента File выведены точки c типом File и у других компонентов таких точек нет (у Environment в подписях не указывается что это не строка, поэтому по инерции думаешь что строка),
у FileReadWrite указан тип RandomFileAccess и опять у других компонент таких точек нету... интуитивно непонятно что куда тыкать, пример для FileReadWrite открыл ну да вроде так и так, а примера для папки нет и пошли эксперементы.

Да, я сам лез в код, чтобы вспомнить что оно там выдаёт. Поправлю.
Да, не очень понятно. Вообще, сложно было изучать Java/Android, а затем переключаться в режим HiAsm, не имея полной картины компонентов.

Понятно что сложно, любое проектирование многоступенчато. И вы уже проделали титаническую работу и вообщем-то все работает. Это здорово, потому что альтернатива для меня например - это писать на питоне и танцевать с бубном на бульдозере чтобы там apk файл собрать, а для бульдозера ставить виртуалку, линукс на нее. А тут все в одном и места мало занимает.
А мне как человеку со стороны, который яву не знает, но знает другие языки, да и раньше пользовался hiasm оказалось трудно разобраться без посторонней помощи (пришлось таки разбираться с явой), переделывать компоненты по старинке (как с пакетом delphi когда надо что-то нестандартное сделать) а если взять человека который в языков вообще не знает...
По-моему хорошо бы вообще избавить эти компоненты от точек данных со специфическими типами - пусть будут только строки, да в каждой точке будут создаваться новые экземпляры объектов класса File или RandomFileAccess, ну и пусть ведь есть сборщик мусора, память при объектно-ориентированной модели языка экономиться - у экземпляра ведь наверно и будет только эта строка с путем или именем файла. Зато несведущему пользователю будет понятно - что вот этот кубик ассоциируется с этим файлом путь к которому занесен в одну точку сверху кубика, а имя в другую. Поставил кубик вписал путь и имя подвел точку к создать, потом к открыть и пишешь данные, да это избыточно будет но в открыть можно просто делать проверку на то что сам файл есть на диске (а не то что файловая переменная есть) и давать ошибку, тогда пользователю будет понятно что если есть ошибка то наверно путь неправильный и файла нет или там разрешений нет поэтому файл не создается.
Ведь у hiasm уровень абстракции получается выше чем у целевого языка, он должен как бы изолировать пользователя от отличий разных языков (для меня то что используются различные целевые языки pascal или java не должно быть заметно при пользовании hiasm), я так понимаю идея hiasm была в том чтобы мог писать человек не знающий языков программирования, но может нарисовать алгоритм на листочке.
Это все ИМХО, спасибо за помощь , начал бороться с потоками почему-то если заводишь точку в Tab сверху с OutputStream дает ошибку при компиляции, а если вне tab все сделать без ошибок, а тут bluestack начал требовать приложения установить, жму установить а он не ставит и так по кругу, придется пробовать genymotion. Наверно надо будет ланчер доделывать чтобы он в него приложения установить мог?

Я думал об этом. И не только я - поэтому был сделан кодогенератор FTCG.
Проблема в том, что система Android и так по своей природе неповоротлива. Да ещё и выполняется на слабых устройствах. А описанный тобой подход добавит ещё больше тормозов.
Конечно, возможны варианты. Например, благодаря FTCG мы можем использовать несколько типов данных: как в компоненте FileOperations - отдельные точки для строки и для готового объекта, либо одна точка, которая сама определяет тип поданных на неё данных (в некоторых компонентах так и сделано). И здесь вообще нет ограничений - что автору компонента больше нравиться, так и делает. Я в этом плане для себя точки не ставил - предполагал, что пакет будет ещё значительно перерабатываться, в т.ч., в плане сокращения количества типов данных, передаваемых между компонентами. Просто пакет ещё далеко не сформировался.

Ещё одна трудность - вот ты сделал компонент, который работает с файлом в виде строкового пути. А теперь представь, что существует некий тип данных, который не имеет строкового представления - те же InputStream/OutputStream и их наследники, Canvas, Bitmap и т.п. Эти объекты могут даже не создаваться автором компонента - он их получает готовыми из других объектов. И как с ними можно работать кроме того, чтобы в одном компоненте давать ссылку на них, а в остальные - передавать. Максимум - это как можно чаще каждый раз создавать/уничтожать, что нерационально.

Наверно. Если для него есть командная строка, то можно добавить аналогично BlueStacks. Только для автоматического определения его наличия на компьютере и добавления в список доступных эмуляторов он должен прописывать себя в реестре. Иначе в лаунчер придётся просто добавить параметры и кнопку типа "Установить в genymotion" (можно в лаунчер вкладки добавлять для разных таких эмуляторов).

Редактировалось 3 раз(а), последний 2017-04-03 15:18:44

Netspirit, сам думал об обобщённых типов данных (да и в принципе, не раз мы это обсуждали ). К примеру, если Canvas и Bitmap всё же как-то можно объединить (например, при первом запросе на редактирование Bitmap создавать instance Canvas-a, а после всех процедур уничтожать Canvas), то со стримами есть непонятки. На данный момет, проще всего будет объединить Input/Output streams, создав общий интерфейс взаимодействия с потоком. Но непонятно, нужна ли така вещь, как byte[], всё же много элементов принимают этот тип на входе. Пока, как я вижу, именно эта вещь мешает создания единого типа для работы с BLOB. А в целом проскакивали идеи, что для типов, которые не возможно представить в строковом виде (к примеру, View), можно использовать числовое представление. Обычному пользователю такие числа можно представлять как "идентификаторы". Но уже наперёд я вижу сложности при управлении такими объектами в памяти, ибо надо как-то знать, когда нужно выгрузить объект из какого-то глобального object registry. Да и вообще не понятно, целеобразна ли эта идея

Редактировалось 1 раз(а), последний 2017-04-03 18:56:22

  Объединение или слияние типов должно быть обусловлено только инструментами, которые предоставляет целевой язык и конечно же архитектурой пакета. Если у вас предположим есть класс для работы с данными в файле, памяти, сети (ftp, http - не важно), где угодно еще и у них есть общий предок, то должен быть один тип у точек. Если у них нет общего предка, но работа с ними абсолютно идентична, то вы должны сделать класс обертку для всех источников данных.

  Если встречается ситуация, как в примере выше (т.е. есть к примеру Canvas и есть Bitmap, который напрямую не предоставляет канву для рисования, но может это сделать через внешний класс или вызов одного из своих методов), то лучше всего выходить из такой ситуации следующим образом: в элементах, которые рисуют на Canvas отправлять "наверх" информацию о том, какой именно интерфейс требуется от точки и если Bitmap видит, что от него запрашивают Canvas, то он может его сам создать и вернуть то, что от него просят. При такой реализации для пользователя все будет прозрачно и усложнение коснется только кода элементов. В одном из пакетов на FTCG таким образом имитировался интерфейс массива и элементы могли предоставлять точку Array не имея массива в реализации кода целевого языка вообще (правда назвать это хорошей практикой нельзя - все же лучше писать классы обертки).