Забавно, но чуть более 10 лет назад я более-менее успешно занимался разработой подобного такого же устройства.
Было даже 2 рабочих прототипа устройства. Ну, и, естетсвенно, софт…
Сейчас просто оставлю тут вот это фото:
… и вот эту анимашку:
Я с удовольствием напишу о своем детище более подробно, если это будет интересно Хабра-сообществу.
Yandex! IT-гигант! Статейкой такие воспоминания навеяли…ностальгия.
Живу сейчас я, значит, в Мск. Раз в 2-3 месяца езжу на родину, к родителям. На машине. Около 1К км в один конец. Родители, зная, что я в пути, порой переживают, как там я в дороге, особо, когда погода не располагает. Периодически звонят и интересуются, где я.
Еще в 9м году посетила идея реализовать трекер, так чтобы родственники могли узнать, где я в данный момент нахожусь, обновив определенную страницу в браузере дома на компе.
Как и многие проекты, создаваемые в одиночку и отчасти ради процесса создания, этот тянулся более года (да, и трекер – это была лишь малая часть функционала).
Платформа была J2ME (хотя и Android'ы уже имелись в доступе). Целевые девайсы распространенные, доступные, GPS естесно не имели.
LAC и CellID отдавались лучше всего на Samsung. SE в основной массе отдавали данные с каким-то отличиями от необходимых (точно не помню, но вопросы были). Nokia S40, как правило, вообще ничего не давали без сертификата trusted-разработчика. Ну, и т.д.
У операторов появились безлимитные тарифные опции для Интернета.
Дорога на родину занимает, как правило, 10++ часов.
Данные о реальном местоположении брались с разных источников (в т.ч. www.opencellid.org/api). Координаты отправлялись на сервер, где с отметкой времени попадали в БД. В браузере результат выглядел следующим образом:
Проект был заброшен – эксперименты дали положительные результаты, но дальше бесперспективно, тем более что имелось (имеется?) немало юридических моментов. Хотел было даже IT-гиганту предложить решение, но как-то отпало…
Уважаемый, Yandex, так может, сделаете что-то подобное? Или не положено?
Конролировать, не в смысле знать, где человек сейчас, а в смысле направлять народ куда надо Гуглу: флешмобы там всякие, о проведении которых будут знать только в Гугл,… или там с салон, для покупки нового гуглофона, или в обход магазинов Эпл :)
Халивар в комметах, причем, в основном не о тонких и толстых клиентах, а о нативных и кроссплатформенных вариантах решения.
Абсолютно тонкий клиент для современной мобилы (wireless device) должен иметь функционал тач-экрана, связанного с удаленным сервером.
Задачи такого тонкого клиента сводятся к следующей последовательности:
1. Получить инфу от сервера (может быть даже в виде целых скринов);
2. Отобразить полученную инфу;
3. Получить инфу по тачам юзера;
4. Отправка тачей на сервер.
Как правило, по мере утолщения клиента последовательно появляются следующие фичи:
1. Вместо целых скринов брать от сервера и отображать контент описательного характера (это ж HTML!)
2. Отправлять на сервер не тачи с экрана, а инфу о взаимодействию юзера с активными элементами GUI
3. Уметь кешировать для дальнейшего использования некоторые данные от сервера (для разгрузки канала и сервера)
4. Производить «тяжелые» операции с кешированными данными
5. Быть все более функционально автономным от сервера
6. Отправлять на сервер результаты вычислений (для хранения и/ли многопользовательского использования)
А вот на чем написан такой клиент — это уже другой вопрос.
Если кроссплатформа позволяет написать продукт, удовлетворяющий всем требованиям, то ее выбор будет весьма оправдан, ведь это, как правило, менее трудозатратный вариант.
Но даже самая крутая кроссплатформа, как и любое универсальное решение может иметь свои ограничения (например, по ресурсоемкости/скорости или по кастомизации GUI), которые могут нивелировать в ноль плюсы ее применения.
И вот тут-то становится явным, что без натива — никуда.
И еще, имхо, кроссплатформенные тонкие клиенты лучше всего подходят для прототипирования (в широком смысле) решения, т.к. это не трудоемко.
Для серьезных, «устоявшихся» решений скорее всего потребуется толстый нативный клиент, Но далеко на каждый проект доживает до такого этапа.
подобноготакого же устройства.Было даже 2 рабочих прототипа устройства. Ну, и, естетсвенно, софт…
Сейчас просто оставлю тут вот это фото:
… и вот эту анимашку:
Я с удовольствием напишу о своем детище более подробно, если это будет интересно Хабра-сообществу.
Живу сейчас я, значит, в Мск. Раз в 2-3 месяца езжу на родину, к родителям. На машине. Около 1К км в один конец. Родители, зная, что я в пути, порой переживают, как там я в дороге, особо, когда погода не располагает. Периодически звонят и интересуются, где я.
Еще в 9м году посетила идея реализовать трекер, так чтобы родственники могли узнать, где я в данный момент нахожусь, обновив определенную страницу в браузере дома на компе.
Как и многие проекты, создаваемые в одиночку и отчасти ради процесса создания, этот тянулся более года (да, и трекер – это была лишь малая часть функционала).
Платформа была J2ME (хотя и Android'ы уже имелись в доступе). Целевые девайсы распространенные, доступные, GPS естесно не имели.
LAC и CellID отдавались лучше всего на Samsung. SE в основной массе отдавали данные с каким-то отличиями от необходимых (точно не помню, но вопросы были). Nokia S40, как правило, вообще ничего не давали без сертификата trusted-разработчика. Ну, и т.д.
У операторов появились безлимитные тарифные опции для Интернета.
Дорога на родину занимает, как правило, 10++ часов.
Данные о реальном местоположении брались с разных источников (в т.ч. www.opencellid.org/api). Координаты отправлялись на сервер, где с отметкой времени попадали в БД. В браузере результат выглядел следующим образом:
Проект был заброшен – эксперименты дали положительные результаты, но дальше бесперспективно, тем более что имелось (имеется?) немало юридических моментов. Хотел было даже IT-гиганту предложить решение, но как-то отпало…
Уважаемый, Yandex, так может, сделаете что-то подобное? Или не положено?
В любом случае, больше спасибо за статью.
Абсолютно тонкий клиент для современной мобилы (wireless device) должен иметь функционал тач-экрана, связанного с удаленным сервером.
Задачи такого тонкого клиента сводятся к следующей последовательности:
1. Получить инфу от сервера (может быть даже в виде целых скринов);
2. Отобразить полученную инфу;
3. Получить инфу по тачам юзера;
4. Отправка тачей на сервер.
Как правило, по мере утолщения клиента последовательно появляются следующие фичи:
1. Вместо целых скринов брать от сервера и отображать контент описательного характера (это ж HTML!)
2. Отправлять на сервер не тачи с экрана, а инфу о взаимодействию юзера с активными элементами GUI
3. Уметь кешировать для дальнейшего использования некоторые данные от сервера (для разгрузки канала и сервера)
4. Производить «тяжелые» операции с кешированными данными
5. Быть все более функционально автономным от сервера
6. Отправлять на сервер результаты вычислений (для хранения и/ли многопользовательского использования)
А вот на чем написан такой клиент — это уже другой вопрос.
Если кроссплатформа позволяет написать продукт, удовлетворяющий всем требованиям, то ее выбор будет весьма оправдан, ведь это, как правило, менее трудозатратный вариант.
Но даже самая крутая кроссплатформа, как и любое универсальное решение может иметь свои ограничения (например, по ресурсоемкости/скорости или по кастомизации GUI), которые могут нивелировать в ноль плюсы ее применения.
И вот тут-то становится явным, что без натива — никуда.
И еще, имхо, кроссплатформенные тонкие клиенты лучше всего подходят для прототипирования (в широком смысле) решения, т.к. это не трудоемко.
Для серьезных, «устоявшихся» решений скорее всего потребуется толстый нативный клиент, Но далеко на каждый проект доживает до такого этапа.