Android как тонкий клиент

Планшет как тонкий клиент к ПК?

от смотрите. берем стационарный ПК, выкидываем монитор, клавиатуру, мышь. оставляем лишь системный блок, да колонки.

берем планшет, опционально (ибо линуксоид как никак) подключаем к нему клавиатуру и заходим на свой ПК планшетом — получается тонкий клиент. м?

я хотел монитор вообще купить, но подумал, может уже на планшет перейти.

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

из минусов, как я вижу, на планшете будет какой-нибудь Android, а это значит — никакой гибкости настройки интерфейса. или. а можно ли вообще иксы пробросить на планшет и работать в них?

ощщем, отговорите от дурной затеи.

Судя по тексту — нет. Отговорить просит.

Еще ты не видишь его небольшие размеры, что для десктопа явный минус, и вообще неудобность работы с этой доской.

Больше всего добивает скролинг, когда цепляюсь через TeamViewer к десктопам. Должна работать прокрутка двумя пальцами, но в реальности это жутко неудобно. Приходится всё время искать компромисс между масштабом и размером окон.

Ресурс планшета слишком быстро потратится.

ощщем, отговорите от дурной затеи

Долгая работа с интерфейсом для манипуляторов на сенсорном экране сделает из тебя УГ

Займись чем-нибудь полезным для себя

И всё-таки, может будешь ставить тэг «спуфно»?

Это просто. Нужно просто рассказать ему, что они больше 50 баксов стоят.

Это просто. Нужно просто рассказать ему, что они больше 50 баксов стоят.

Не, не подходит. Он найдёт за 40.

алсо, в моем бложике вы можете узнать откуда пошло это слово. =)

я хотел монитор вообще купить, но подумал, может уже на планшет перейти.

Как же достали эти попытки заменить все планшетом, и телефон и ТВ и ПК.

На планшетах работать невозможно — факт, разве что под «работой» считать втентаклик и одноглазников с птичками, в лучшем случае текст набрать получится.

Android
никакой гибкости настройки интерфейса

тебя где-то нае^H обманули

Идея, в принципе, интересная. Но есть «но» и их несколько. Во-первых, иксы ты не пробросишь (нужен рут и полностью OSS совместимый планшет, а таких немного). Во-вторых, как уже заметили выше, разрешение экрана на самом планшете — придётся искать как минимум 1280х800, а в идеале 1920х1200, чтоб ваш экран стационарника полностью помещался на экране планшета (в такие плашеты стоят значительно дороже монитора для основной системы). Ну и в довесок, много половых отношений с тонкой настройкой этого всего в одну систему, т.к. гнать интерактивную картинку по вай-фаю с необходимыми задержками тот ещё секс.

из минусов, как я вижу, на планшете будет какой-нибудь Android, а это значит — никакой гибкости настройки интерфейса. или. а можно ли вообще иксы пробросить на планшет и работать в них?

На ведроиде нет иксов как системообразующего компонента. А ставить туда X-сервер с настройкой терминальной системы — так лучше поставить мощный ПК и туда через иксы ходить, настроив ещё и VirtualGL.

и заходим на свой ПК планшетом — получается тонкий клиент. м?

Источник

Тонкий клиент для Android где найти?

Мобильный клиент, по сути, представляет собой некоторую «оболочку», которая может запустить то или иное прикладное решение. При этом функциональность запускаемых прикладных решений может сильно отличаться друг от друга. В то же время магазин приложений AppStore, требует, чтобы приложение, опубликованное в магазине, не меняло значительно свою функциональность после публикации.

Поэтому мы не публикуем мобильный клиент как отдельное универсальное приложение. Мобильный клиент поставляется вместе с мобильной платформой в виде набора исполняемых файлов. На основе этих файлов разработчик должен собрать приложение, которое будет работать на мобильном устройстве. Процедуры сборки и публикации приложений, что для мобильной платформы, что для мобильного клиента, схожие. Используется один и тот же инструмент – сборщик мобильных приложений.

Чтобы мобильный клиент, публикуемый в магазин приложений, имел фиксированную функциональность, при его сборке необходимо указать конкретные конфигурации, с которыми будет работать это приложение. В процессе работы мобильный клиент проверяет, что используется только одна из заданных конфигураций и без существенных изменений. Это специальная защита для того, чтобы мобильный клиент, который опубликован для определенных конфигураций, не мог работать с другими конфигурациями. Как показывает практика, пользователям удобно, чтобы одно мобильное приложение соответствовало какой-то одной конфигурации, или схожим конфигурациям.

Источник

Мобильный терминальный клиент, как зарождалась идея

Как создавался Российский тонкий клиент и к чему все привело.

В те времена, когда красный флаг уже перестал развеваться над нашей Родиной, на дворе шел 2012 год. Я работал в одном Российском системном интеграторе, где занимал двойную должность «Руководителя ИТ отдела» и «Руководителя ИТ проектов». Время было веселое, отличная команда профессионалов, которая всегда слаженно работала, хотя и не так все было просто. Можно долго перечислять имена и фамилии людей, которые работали плечом к плечу со мной, но сдавать агентов КГБ, не буду, не имею такой привычки.

В один прекрасный день, солнце было в зените, а небо было ясное, руководство пребывало в хорошем настроении и на очередном совещании было решено, сделать свой прорывной проект на российском ИТ рынке, на дворе 2012 год! В то время еще не говорили об импортозамещении, видимо, общий вектор руководство понимало, а может и просто удачное стечение обстоятельств. Как говорится в девизе ВДВ: «Никто кроме нас!». Данный девиз витает во всем интеграторе, особенно когда один из руководителей идет по коридору! Спасибо судьбе, что я работал с таким руководителем, после этого опыта работать везде не так сложно 🙂

Так вот с этим девизом и взялись за дело! Было решено, что руководить проектом буду я, т.к. на плечах голова изобретателя, умею писать ТЗ, а так же есть опыт слаженного руководства несколькими командами разработчиков, ну и, конечно, умею аналитически мыслить и договариваться в сложных ситуациях.

Аплодисменты – это все я.

Началось все с того, что я запросил на тестирование у основных вендеров существующие тонкие клиенты: HP, Dell WYSE (T10, T50, ZXO), Kraftway Kredo, Тонк 1501 и т.д. Тестировались тонкие клиенты на технические и интерфейсные возможности для пользователей, администраторов, удобство, настройки и т.д.

Для тестирования было установлено ПО на удаленном сервере:

• Microsoft Office (Excel, Word, PowerPoint);
• Microsoft Outlook;
• 1C Предприятие;
• Microsoft Dynamics CRM;
• Microsoft Sharepoint Workspace;
• USB Network Gate;
• Microsoft Lync;
• Microsoft SQL Server 2008;
• Microsoft System Center 2012 (Software Center);
• ViPNet;
• и многое другое.

После окончания тестирования, было решено сделать на базе Российского железа и урезанной OS Linux наш тонкий клиент, так и получилось.

Техническое задание писал как «видел». Руководство, коллеги, партнеры, много раз пытались меня переубедить, что каких-то моментов не нужно делать дабы упростить. Слава Богу, за этот тернистый путь, удалось сделать именно так, как я написал в первых версиях технического задания. Как всегда, все потом забыли, что говорили об обратном развитии проекта.

В итоге за пол года работы, был сделан тонкий клиент с возможностью одновременной работы в основных средах виртуализации по протоколам: ICA, PCoIP, RDP, x11, VNC.

Сейчас подобных устройств на рынке много, но история не об этом…

В это же самое время у меня родилась очередная идея!

Весна 2013 года, первый визуальный набросок идеи.

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

Нужна только док-станция для мобильного телефона и периферийные устройства. Страница из моей презентации.

Начал прорабатывать идею детально, из чего должен состоять «Мобильный терминальный клиент», что он должен уметь, сколько нужно денег на реализацию, есть ли патенты на подобные решения. Благо были отличные помощники, которые верили в мои идеи! Все люди встретившиеся на пути не случайно, что-то давали мне, какими-то идеями я делился с ними. За этот опыт огромная благодарность всем!

Был подготовлен бизнес-план, краткая презентация, общее понимание сколько минимум нужно денег, сколько специалистов и времени на реализацию. Должен был получиться динамичный SturtUp! Начал искать деньги по частным инвесторам. Многие участники, с которыми встречался, задают тон на Российском рынке ИТ и сейчас. Почти каждый говорил что-то новое и интересное по данному проекту, находил тонкие места с реализацией, продажами и т.д. После каждой встречи, приходилось что-то добавлять или менять в презентации и бизнес-плане. На поиски инвестора я отвел себе пол года, решил, если не получится найти, то кто-то подобный проект уже придумает и приступит к реализации. Патент регистрировать не стал, до нахождения финансов, у меня был уже один патент, но об этом в следующий раз.

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

Итог, я ушел заниматься другими ИТ делами и мысленно отпустил данный проект.

Первым через 3 года был реализован подобный проект у Microsoft.

Еще одну реализацию на днях увидел у коллеги «по цеху», на базе Hewlett-Packard (HP).

Вот краткая история по очередной идее, которая не была реализована мной. Если будет интересны идеи еще, которые много лет назад крутились в голове, но реализованы не мной – напишу.

Уверен, таких изобретателей много, придумали, но не смогли реализовать в силу ряда причин…

Источник

Использование Android устройства в качестве тонкого UI для С++ программ

Хочу поделиться с сообществом проектом, которым я потихоньку занимаюсь последние несколько месяцев.

Предисловие

Создание системы, позволяющей реализовывать в С++ программах подключаемый UI на базе android устройств. При этом хотелось минимизировать зависимости пользовательского С++ кода от сторонних библиотек, а так же абстрагировать его от протокола передачи данных. Система должна состоять из двух частей: С++ библиотеки и android приложения.

Архитектура системы

Система имеет клиент-серверную архитектуру, где в качестве клиентов выступают android устройства, сервером является пользовательская программа. Коммуникация между ними осуществляется при помощи TCP/IP сокетов. Для реализации протокола общения была создана библиотека TAU.

Основные задачи, за которые отвечает библиотека:

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

Библиотека состоит следующих пространств имён:

tau::communications_handling — отвечает за формирование пакетов, парсинг данных пришедших от клиента, вызов обработчиков в пользовательском коде. Всё, что происходит между моментами подключения и отключения клиента контролируется кодом классов из этого пространства имён.

tau::layout_generation — содержит функциональность, позволяющую создавать json-структуры, описывающие расположение и поведение элементов пользовательского интерфейса. Эти данные затем отправляются на клиент и он отображает соответствующий UI.

tau::util — содержит различную вспомогательную функциональность, которая не обязательна для использования библиотеки в пользовательском С++ проекте, однако зачастую оказывается полезна. Классы в этом пространстве имён — единственные, которые могут использовать сторонние библиотеки или нестандартные расширения компилятора. Поэтому, здесь находятся классы, отвечающие за работу с TCP/IP сокетами — это платформозависимый код. Сейчас есть две реализации сетевого общения: на базе boost::asio и C++/CLI. Вынос реализации всех сетевых вызовов за пределы tau::communications_handling позволяет пользователю библиотеки при желании написать всю сетевую часть самостоятельно.

tau::common — содержит классы, используемые из других частей библиотеки (они выведены сюда, чтобы не было зависимостей между tau::layout_generation и tau::communications_handling)

Использование. Пример №1 — hello, world

Демонстрацию использования библиотеки начнём с простейшего примера, в котором на экран будет просто выведено приветствующее сообщение. Вот как будет выглядеть пользовательский код в нашем случае:

Основной класс, который содержит всю пользовательскую логику, взаимодействующую с клиентским устройством (MyEventsDispatcher) должен быть отнаследован от tau::util::BasicEventsDispatcher. В нём переопределены 2 метода из базового класса: onClientConnected() и packetReceived_clientDeviceInfo(). Первый вызывается в момент подключения клиента. Второй метод будет выполнен, когда на сервер придёт информация о клиентском устройстве после подключения (первый пакет после подключения отправляется клиентом).

В нашем случае первый метод тривиален — он только выводит информационное сообщение на консоль. Во втором методе сервер отправляет клиенту лэйаут (layout) — данные о том, какой интерфейс должен быть отображён на клиенте.

Весь код, отвечающий за передачу данных по сети находится в main(). В данном случае, для реализации коммуникации используется библиотека boost::asio. В пространстве имён tau::util есть соответствующие абстракции, что делает данный пример максимально компактным. Использование boost необязательно — любая реализация TCP/IP сокетов может быть довольно легко использована вместе с библиотекой.

Компиляция

В качестве примера, для компиляции будем использовать g++. В нашем случае команда будет следующей:

Как видно, компилятору передаётся несколько дополнительных параметров:

• include path до исходников библиотеки (опция -I $LIBRARY_LOCATION)
• дополнительные библиотеки, необходимые для boost::asio (опции -lboost_system -pthread -lboost_thread)
• объявления дополнительных макросов, указывающих, каким образом мы компилируем библиотеку в нашем проекте (-D TAU_HEADERONLY -D TAU_CPP_03_COMPATIBILITY)

Данный набор опций — самый общий вариант сборки, который позволят включить библиотеку в любой проект с минимальными усилиями.

От них всех можно при желании избавиться. Если использовать библиотеку внутри проекта, не нужно указывать -I $LIBRARY_LOCATION и -D TAU_HEADERONLY. Для компиляторов, совместимых с C++11, опция -D TAU_CPP_03_COMPATIBILITY не нужна. Зависимость от boost::asio имеет только сетевая часть, которую довольно легко можно переписать без зависимостей.

После компиляции и запуска, сервер начинает слушать на порту 12345.

Запускаем клиент на телефоне, создаём соединение и подключаемся к нему для отображения сообщения. Вот, как это будет выглядеть (я запускал сервер на удалённом компьютере через PuTTY, а клиент запускался в эмуляторе):

Данный пример не предусматривает передачу и получение дополнительных уведомлений между клиентом и сервером, поэтому давайте перейдём к следующему примеру.

Пример №2 — более развёрнутая демонстрация возможностей системы

В данном примере мы добавим в нашем сервере несколько различных элементов, научимся получать от них уведомления, изменять их состояние и переключать страницы.

Код сервера будет выглядеть так:

Все изменения по сравнению с предыдущим примером были сделаны в классе MyEventsDispatcher. Были добавлены следующие методы-обработчики событий от клиента:

• обработчик события нажатия кнопки packetReceived_buttonClick. ID кнопки передаётся методу в качестве параметра.
• обработчики пакетов, передающих значения переменных от клиента к серверу: packetReceived_boolValueUpdate, packetReceived_intValueUpdate, packetReceived_floatPointValueUpdate, packetReceived_textValueUpdate
• обработчик события смены отображаемой страницы с элементами packetReceived_layoutPageSwitched

Кроме того, соответственно изменился лэйаут, отправляемый клиенту при подключении.

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

Все команды будут отправляются клиенту из обработчика нажатий кнопок packetReceived_buttonClick() (естественно, это не обязательно делать там, но так проще и нагляднее).

Каждой из команд соответствует пакет, передаваемый от сервера клиенту. Формирование и отправка этих пакетов происходит при вызове специальных методов, определённых в BasicEventsDispatcher:

• sendPacket_resetLayout() — замена всего лэйаута
• sendPacket_requestValue() — запрос значения переменной в одном из инпутов
• sendPacket_updateBooleanValue(), sendPacket_updateIntValue(), sendPacket_updateFloatPointValue, sendPacket_updateTextValue() — изменение значения переменных в инпутах
• sendPacket_changeElementNote() — изменение какого-либо read-only текста (текст на кнопках, чекбоксах, лейблах)
• sendPacket_changeShownLayoutPage() — переключение на другую страницу с элементами
• sendPacket_changeElementEnabledState() — переключение активного статуса элементов (неактивные элементы отображаются, но с ними нельзя взаимодействовать)

Вот как работает данный пример:

Как видно, для каждого действия на клиентском устройстве, на сервере выполняется соответствующий код. Когда меняются значения элементах пользовательского ввода, сервер получает уведомление о новом значении переменной в этом элементе. В обработчике нажатий кнопок различные пакеты отправляются от сервера клиенту (тип пакета зависит от того, какая из кнопок была нажата). В этом примере также показано, как работает переключение страниц. Разбиение лэйаута на страницы позволяет группировать элементы в соответствии их функциям. На экране клиента всегда отображена только одна из страниц, что уменьшает загруженность интерфейса.

Пример №3 — что-нибудь полезное

Последний на сегодня пример — частичная реализация одной из задач, для которой я начал этот проект. Это простейший эмулятор клавиатурного ввода для windows (использует winapi-функцию SendInput()).

Код этого примера лежит у меня на гитхабе. Тут приводить его не буду — он ничего нового в использовании библиотеки не демонстрирует по сравнению со вторым примером. Тут приведу только демо его работы:

Код данного примера легко расширить под более сложные задачи эмуляции клавиатурного ввода.

Эпилог

Вместо заключения, хочу обратиться к сообществу. Нужна ли подобная система? Не изобретаю ли я очередной велосипед? Что нужно описать более детально? В каком направлении нужно развиваться дальше?

Мне сейчас приходят в голову следующие пути развития (они почти полностью ортогональны, поэтому хотелось бы расставить приоритеты):

Источник