barcode

аутсорсинг: где брать разработчиков для Android (iPhone)?

есть идея, которая пока не подкреплена финансированием :)
Поэтому, я публикую идею (которая ничего не стоит), в надежде, что кому-то станет интересно реализовать её в каком-то виде, без начальных вложений. Честно говоря, нас для для пробы идеи вполне устроит LGPL, а может даже вообще библиотека в бинарниках с документацией как её использовать. Но если вдруг решимся заказывать готовое решение, то возможны варианты:
- что-то типа BSD-like, и мы дальше развиваем это сами, не трогая вас (или трогая на отдельных условиях за отдельные деньги)
- партнерские соглашения: если мы продаём систему, и заказчик хочет в дополнение к ней клёвую штуку с телефонами - мы направляем его к вам, за некие небольшие комиссионные.

Идея очень простая, но ожидается много возни на стороне телефонов.

Дано:
* некое большое хранилище кучи данных
* человек с телефоном на платформе Android или iPhone (9:1).
* перед человеком штрихкод. Сейчас это Code 128, но думаю, не суть важно.
Нужно:
* включить фотокамеру телефона, дать человеку сфотографировать штрихкод.
* со значением из штрихкода и логином:паролем (взятым из конфига на телефоне) сходить в хранилище и получить там данные
* удобно отобразить их на экране телефона.

Где возня, спросите вы? Данных много. Если, например, распечатать один "документ", в удобной для человека форме, это получается почти лист А4 (если мелким кеглем, можно впихнуть на А5). Данные иерархичны и элегантно засовываются в XML. От нас их можно получать уже в таком виде, но я не уверен, что это будет хорошей идеей. Сырые данные хранятся в RDBMS. И в ближайшее время это не изменится.

Чего бы хотелось в первом чтении и без денег: да хоть чего-нибудь рабочего :)
Например вот, чтоб сказали:
* вот приложение, ставите на телефон.
* вот сервер, вот, в текстовом файле данные. Единица информации - одна строка.
* вот список пользователей и хеши их паролей, в другом текстовом файле.
* вот утилита расчета хеша
мы берем это всё, ставим, и пробуем. Заводим пользователей, меняем данные, подсовываем разные штрихкоды. Играемся-смотрим, смотрим-играемся. Думаем над вашими условиями продолжения сотрудничества.

Проблема с яблофоном в том, что приложения видимо нужно будет прогонять через AppStore, что выглядит не очень приятно.
На стороне сервера у нас:
* Win32, Win64
* Java
но ничего не догма, разумеется. Главное понимать, что требование "сервер на Linux, код на С++" увеличивает цену решения по нескольким пунктам, а значит снижает либо привлекательность для заказчика, либо доход разработчика. Может увеличить настолько, что это вообще не получится продать.

На вопросы вида "вы там что, совсем с ума по сходили?" сразу отвечаю - Да, мы совсем :)

Предложения со сроками и возможными суммами строго по адресу bormotov@gmail.com

Вопросы уточняющие задачу можно спрашивать в каментах. Каменты будут видны всем. Правда, не обещаю что отвечу на все вопросы до момента формализации отношений.
Tags: , , ,
я бы для начала упростил задачу.
Скажем распознавание сделать на машинке, а на сервак отправлять стандартный http Post, и ответ открывать в браузере. Тогда вопрос показа данных целиком ложится на браузер и веб что гораздо проще в плане создания/модификации.
можно и так, мне в целом без разницы.

Разе что в таком раскладе, не http, а https, но думаю это уже не суть совершенно. Плюс, не забываем. что на стороне сервера, нужно уметь не просто статику отдавать, а сходить куда-то в базу за данными.
это в любом случае пришлось бы делать на стороне сервера. Но тут технологии давно разработаны.
это понятно, я к тому, что взять любой готовый httpd и отдать статику не проканает даже для пилотной версии.
php скорее всего отказать сразу.
asp - в пилотной (бесплатной) части устроит, дальше вопрос формы взаимоотношений и цены.