Google Web Toolkit (GWT) + Google App Engine (GAE) + отсоединенная персистентность данных
Может не быть универсально жизнеспособного решения, но следующее работало над некоторыми сборками (но не над другими):
Intent intent = new Intent(Intent.ACTION_GET_CONTENT);
intent.addCategory(Intent.CATEGORY_OPENABLE);
Uri uri = Uri.parse("content://com.android.externalstorage.documents/document/primary%3AAndroid%2Fdata%2Fmy.app%2Ffiles");
intent.setData(uri);
intent.setType("*/*");
intent.putExtra("android.provider.extra.INITIAL_URI", uri);
intent.putExtra("android.content.extra.SHOW_ADVANCED", true);
startActivityForResult(intent, 42);
uri должен быть content URI для [113 ] провайдер. Путь URI - /document/primary%3A, за которым следует путь файловой системы к папке для запуска. Путь должен быть относительно корня общего хранилища (т. Е. Удалить ведущий /sdcard/ или эквивалентный на устройстве и убедиться, что результат не начать с косой черты) и сбежал.
Вызов Intent#setData() не помогает установить местоположение по умолчанию (в отличие от некоторых сторонних файловых менеджеров), но предотвращает отображение нежелательных провайдеров хранения (таких как Галерея и Музыка).
Дополнительный android.provider.extra.INITIAL_URI устанавливает начальный URI, но это может не работать до API 26 (хотя он работает на некоторых разновидностях Android).
Из-за android.content.extra.SHOW_ADVANCED хранилище устройства становится доступным в качестве поставщика (в противном случае, в зависимости от разновидности Android, может потребоваться, чтобы пользователь выбрал его или не было доступно вообще).
10 ответов
Awhile ago I wrote a post Using an ORM or plain SQL?
This came up last year in a GWT application I was writing. Lots of translation from EclipseLink to presentation objects in the service implementation. If we were using ibatis it would've been far simpler to create the appropriate objects with ibatis and then pass them all the way up and down the stack. Some purists might argue this is Bad™. Maybe so (in theory) but I tell you what: it would've led to simpler code, a более простой стек и большая производительность.
, что в основном соответствует вашим наблюдениям.
Но, конечно, это не вариант с Google App Engine, так что вы в значительной степени застряли, имея слой перевода между объектами на стороне клиента и вашим JPA Сущности.
Сущности JPA довольно жесткие, поэтому они не подходят для отправки туда-сюда между клиентом. Обычно при этом вам нужны маленькие кусочки от нескольких сущностей (таким образом, в итоге получается какой-то объект значения уровня представления). Это ваш путь вперед.
, поскольку GWT в конечном итоге компилируется в JavaScript, для автономного хранения потребуется один из немногих доступных сервисов. Наиболее известны магазины HTML5 и Gears (оба используют SQLite!). конечно, ни один из них не имеет широкого распространения, поэтому вам придется убедить своих пользователей либо использовать современный браузер, либо установить малоизвестный плагин. если пользователь не соблюдает требования, обязательно перейдите к пригодному для использования подмножеству
You can consider using JSON. GWT has necessary API to parse & generate JSON string in the client side. You get a lot of JSON API for server side. I tried with google-gson, which is fine. It converts your JSON string to POJO model and viceversa. Hope this helps you providing a decent solution for your requirement
Попробуйте использовать http://gilead.sourceforge.net/
У Рэя Кромвеля есть временный взлом . Я пробовал, работает.
Это заставляет вас использовать Transient вместо Detachable entity, потому что GWT не может сериализовать скрытый Object [], используемый DataNucleus; Это означает, что объекты, которые вы отправляете клиенту, нельзя вставить обратно в хранилище данных, вы должны получить фактический объект хранилища данных и скопировать обратно в него все постоянные поля. Метод Рэя использует отражение для перебора методов, получения методов getBean () и setBean () и применения объекта setBean () с getBean () вашего временного объекта gwt.
Вы должны стремиться использовать JDO, JPA isn На данный момент это не намного больше, чем класс-оболочка. Чтобы использовать этот прием, у вас должны быть методы получения и установки для каждого постоянного поля, с использованием ПРАВИЛЬНОГО синтаксиса getBean и setBean для каждого поля "bean". Что ж, ПОЧТИ ПРАВИЛЬНО, поскольку предполагается, что все геттеры будут начинаться с «get», когда по умолчанию используется логическое поле «is».
Я исправил эту проблему и опубликовал комментарий в блоге Рэя, но он ожидает утверждения, и я не уверен, что он его разместит. По сути, я реализовал аннотацию @GetterPrefix (prefix = MethodPrefix.IS) в пакете org.datanucleus, чтобы расширить его работу.
Если она не публикуется, и это проблема, напишите x_AT_aiyx_DOT_info по электронной почте Re: @GetterPrefix для JDO, и я пришлю вам исправление.
Я исправил эту проблему и опубликовал комментарий в блоге Рэя, но он ожидает утверждения, и я не уверен, что он его опубликует. По сути, я реализовал аннотацию @GetterPrefix (prefix = MethodPrefix.IS) в пакете org.datanucleus, чтобы расширить его работу.Если она не публикуется, и это проблема, отправьте электронное письмо x_AT_aiyx_DOT_info Re: @GetterPrefix для JDO, и я пришлю вам исправление.
Я исправил эту проблему и опубликовал комментарий в блоге Рэя, но он ожидает утверждения, и я не уверен, что он его опубликует. По сути, я реализовал аннотацию @GetterPrefix (prefix = MethodPrefix.IS) в пакете org.datanucleus, чтобы расширить его работу.Если она не публикуется, и это проблема, напишите x_AT_aiyx_DOT_info по электронной почте Re: @GetterPrefix для JDO, и я пришлю вам исправление.
Попробуйте . Это модуль для сериализации основных типов GAE и отправки их клиенту GWT.
В настоящее время я использую шаблон DTO (DataTransferObject). Не обязательно как чистая и много больше шаблонов, но GAE все еще требует достаточное количество шаблонов на данный момент. ;)
У меня есть Domain Object mapped (обычно) один на один с DTO. Когда клиенту нужна информация о Домене, DAO(DataAccessObject) выкашливает DTO представление объекта Домена и посылает его по проводу. Когда DTO возвращается, я передаю DAO, которая затем обновляет все соответствующие Объекты Домена.
Очевидно, что это не так чисто, как передача Доменных Объектов напрямую по проводу, но ограничения реализации JDO компании GAE и процесса сериализации GWT означают, что это самый чистый способ для меня в настоящее время.
Что относительно того, чтобы непосредственно использовать хранилище данных API для загрузки и хранения объекты области POJO?
Это должно быть сопоставимо с подходом DTO, значением, например, что необходимо вручную обработать все поля (если вы не используете приемы как основанная на отражении автоматизация), в то время как это должно дать вам больше гибкости и полного доступа ко всем функциям Datastore.
Недавно я обнаружил Objectify , который разработан как замена JDO. У него пока нет большого опыта, но его проще использовать, чем JDO, он кажется более легким и утверждает, что позволяет обойти необходимость в DTO с помощью GWT, хотя я еще не пробовал эту конкретную функцию.
Я тоже использую Objectify, и он мне очень нравится. Вам все еще придется немного потанцевать с методами pre/postLoad для перевода, например, текста в строку и обратно.