la_coste

uses  Androidapi.JNI.GraphicsContentViewText, Androidapi.JNI.JavaTypes, FMX.Helpers.Android, Androidapi.JNI.Net;   procedure TForm1.Button3Click(Sender: TObject); var   OpenLinkIntent: JIntent; begin OpenLinkIntent := TJIntent.JavaClass.init(TJIntent.JavaClass.ACTION_VIEW); OpenLinkIntent.setDataAndType(StrToJURI('file: ///sdcard/inhk.files/index.html'), StringToJString('text/html')); SharedActivity.startActivity(OpenLinkIntent); end; Именно) 
 
Вот такой код получился
 
Написал строчку в прошлом посте, почему то не отобразилась.

Из предполагаемых вариантов действий для устранения ошибки:
 
Четко указать системе тип данных "text/html", тем самым выявив наше намерение, что нужно отправить запрос программе, которая умеет обрабатывать данные именно этого типа.
OpenLinkIntent.setType(StringToJString('text/html')); Еще советуют убрать один слэш из трех после "file:"
 
Или попробовать варианты, которые есть на StackOverflow: http://stackoverflow.com/questions/7009452/how-to-launch-browser-to-open-local-file

Если говорить о размере приложения. То первоначально нужно понять, что входить в состав пакета? Затем определить, что нужно и не нужно?
 
Давайте посмотрим на примере состав пакета небольшого Андроида приложения, написанного в RAD Studio XE5 Delphi. В качестве примера, я взял приложение PhotoEditorDemo, доступный на официальном Open Source проекте примеров RAD Studio XE5
 
Это пример кроссплатформенного простого фоторедактора:
Описание примера: http://docwiki.embarcadero.com/CodeExamples/XE5/en/FMX.Mobile.PhotoEditorDemo_Sample_(Delphi) Исходники: http://sourceforge.net/p/radstudiodemos/code/HEAD/tree/branches/RadStudio_XE5_Update/FireMonkeyMobile/Delphi/PhotoEditorDemo/ Размер сжатого приложения
Собираем приложение и смотрим на результирующий пакет PhotoEditorDemo.apk (Он располагается в директории .\Android\Debug\PhotoEditorDemo\bin относительно корня проекта).
 
После сборки приложения его размер ~6 760 КБ (в зависимости от Debug or Release сборки). Это размер сжатого пакета нативного приложения.
 
Размер распакованного приложения
Если мы распакуем ZIP архиватором этот файл, то увидим его содержание:

В распакованном виде, пакет занимает 21,7 МБ.
 
Состав пакета
Что же входит в его состав:
lib - место хранения собранных натиных библиотек приложения. Поскольку приложение нативное, то оно работает на основании библиотеки .so. res - место хранения ресурсов приложения (картинки, иконки и тд) META-INF - хранение подписи приложения, контрольные суммы файлов ресурсов (картинок, звуков и т.д.) AndroidManifest.xml - манифест приложения (расширенный аналог VersionInfo в Windows) classes.dex - файл с java реализацией дополнительного функционала FireMonkey. resources.arsc - таблица ресурсов. В этом файле собраны xml-описания всех ресурсов. Самый значительный вклад в размер пакета вносят:
libPhotoEditorDemo.so (20 060 КБ) - непосредственно сам бинарник приложения classes.dex (1 948 КБ) - частичная реализация FireMonkey на java. Размер самого приложения большой потому, что включает в себя полностью все Delphi библиотеки, которые используется FireMonkey. А это:
RTL Хедеры для доступа к Android API Нативные стили для Android (три стиля - 1х, 1.5x, 2х, 3х скалирования экрана). Каждый стиль содержит исходную png картинку нативного стиля. Фильтры и эффекты FireMonkey Вся остальная реализация FireMonkey. Довольно большой набор того, что нужно включить в пакет и тяжело выбросить.
 
Если говорить о приложении написанном в Eclipse, то приложение включает в себя только часть пользовательского кода. И размер мал за счет того, что весь Android API находится перманентно на самом устройстве (не в пакете).
 
Если бы используемая часть библиотек FireMonkey находилась на каждом устройстве, то размер приложения сократился бы раза в четыре. 
 
Вывод
Размер установочного пакета приложения, написанного на FireMonkey не большой для нативных приложений порядка 6 760 КБ для реализации простого фоторедактора (Хотя для кого-то это может быть много). В установленном виде приложение занимает от 20 000 КБ. Основная причина полная интеграция используемых библиотек в пакет приложения. Вероятность уменьшить этот размер маловероятна. Однако увеличение функционала приложения не так сказывается на дальнейший рост приложения.
 
Можно попробовать сделать усеченные библиотеки, сократить функциональность. Но это не даст ощутимого уменьшения результирующего размера приложения. 
 
На сколько важен размер приложения для конкретной работы приложения каждый заказчик решает сам.
 
P.S. Цель этого ответа дать подробный ответ о причинах такого размера, а не попытка вызвать обсуждение на тему сравнения сред разработки. Каждый framework обладает своими достоинствами и недостатками. И выбор средства разработки диктуется совокупностью требования заказчика. 

Не за что, обращайтесь.

Спасибо всем) Опробовал 2 способа, все работает)     

Добрый вечер,
 
Тут есть два способа:
Работа с Deployment менеджером. Он довольно подробно описан на Embarcadero Doc Wiki: http://docwiki.embarcadero.com/RADStudio/XE5/en/Deployment_Manager Работа через менеджер ресурсов и их получение через ResourceStream. Этот способ описал MyDelphiPw в сообщении выше тут. 1. Deployment Manager
Специальная настройка проекта, которая позволяет указать, какие файлы нужно включить в состав пакета (Андроид) или бандла (iOS). Суть его работы простая, вы указываете какие файлы с вашего компьютера нужно перенести на устройство (в какое место). А далее работаете с ними из приложения так, как при обычной работе с файлами под Windows.
 
На мобильных платформах нужно учесть специфику возможных местоположений файла. Пакет/Бандл (приложение) не допускает изменения внутренних файлов, потому что подписывается сертификатом. Поэтому теоретически при изменении файлов приложения, вы нарушаете целостность подписи. Именно по этому файлы внутри пакета/бандла доступны только на ЧТЕНИЕ.
 
Однако, мобильные платформы предлагают широкий круг специальных мест для хранения (временные папки, песочницы, документы, карточка памяти и тд) изменяемых файлов (например файл локальной базы данных, или настройки в ini файле и тд).
 
Описание всех вариантов местоположений с описанием путей есть в записе TPath (RTL): http://docwiki.embarcadero.com/RADStudio/XE5/en/Standard_RTL_Path_Functions_across_the_Supported_Target_Platforms. 

Общие действия для использования менеджера развертывания такие:
1. Открываем менеджер развертывания: Системное Меню -> Project -> Deployment.

2. Выбираем в верхнем выпадающем меню платформу и конфигурацию сборки.

3. Нажимаем кнопку добавить файл и выбираем нужный файл.
 
4. Указываем местоположение файла, куда он должен поместиться после развертывания приложения на устройстве. Тут есть особенность, если файл нужен только на чтение, то пути менять не надо. Если возможна ситуация, когда файл может быт изменен, то файл нужно поместить под iOS в Startup\Documents\ (регистр важен)

Под Андроид в assets\internal (регистр важен) - для внутреннего доступа из пакета приложения или assets - для внешнего доступа

5. Получаем пути к расположению файлов:
Под iOS:
TPath.Combine(TPath.GetDocumentsPath, 'filename') Под Андроид:
TPath.Combine(TPath.GetDocumentsPath, 'filename') { Внутренний доступ} TPath.Combine(TPath.GetSharedDocumentsPath, 'filename') { Внешний доступ } Полезные ссылки
Подробное руководство по добавлению файлов для iOS: http://docwiki.embarcadero.com/RADStudio/XE5/en/Creating_an_iOS_App#Loading_and_Deploying_Files Подробное руководство по добавлению файлов для Android: http://docwiki.embarcadero.com/RADStudio/XE5/en/Creating_an_Android_App#Loading_and_Deploying_Files

Да, можно.
В файл проекта dpk добавляем строку
program YouSoft; {$R 'resource.res' 'resource.rc'}  в файле resource.rc создаем такое содержимое:
YouRes RCDATA .\Resources\твой_файл.txt и далее в программе загружать примерно так:
var Stream: TResourceStream; begin Stream:= TResourceStream.Create(hInstance, 'YouRes', RT_RCDATA); try //Работаем с потоком finally Stream.Free; end;  Как-то так. Удачи!