Страница 2 из 3

Re: Предлагаю совместный проект

Добавлено: 30 апр 2013, 12:19
powercat
Схема такая - программист мне говорит - на сайте должно быть вот это и вот это и вот в таком виде. Например, мой текст, который приложение должно скачать, может лежеть на серваке:
1. Как файл (с нужным расширением);
2. Как HTML-текст (с нужным оформлением);
3. Как XML-текст - с нужными тегами.
4....

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

Re: Предлагаю совместный проект

Добавлено: 30 апр 2013, 13:08
Tamachi
Так вот, програмист тебе говорит: на сайте должна быть реализована SOAP-служба, на входе получате дату-время, а на выходе выдаёт список ресурсов, которые были изменены с этого времени. Реализуй, опубликуй WSDL, -- тогда и обращайся к внешним программитам чтобы они для тебя что-то написали.

Re: Предлагаю совместный проект

Добавлено: 30 апр 2013, 13:30
powercat
ээ...а нафига такие сложности???
что-то мне подсказывает, что можно обойтись много более простыми методами - получить данные одного единственного файла по адресу сайта...а в приложении уже сохранить содержимое в базу и отобразить...
А то, что есть новые данные - я это могу руками в этом же файле написать - указать дату

Тогда, при нажатии в приложении "Обновить" телефон получит файл, увидит, что он более новый, чем последний в базе/не более новый, и соответственно сохранит/не сохранит

Может конечно я ошибаюсь, но выше принцип был, как я понял, именно такой (что советовали)

Сайт не будет отображаться сайтом, это чисто для приложения адрес будет

Re: Предлагаю совместный проект

Добавлено: 30 апр 2013, 14:29
Tamachi
powercat писал(а):ээ...а нафига такие сложности???
что-то мне подсказывает, что можно обойтись много более простыми методами - получить данные одного единственного файла по адресу сайта...а в приложении уже сохранить содержимое в базу и отобразить...
Оно неправильно тебе подсказывает.
В общем: с тебя API, а после этого -- продолжим разговор.
powercat писал(а): А то, что есть новые данные - я это могу руками в этом же файле написать - указать дату
Это несерьёзно.
powercat писал(а): Тогда, при нажатии в приложении "Обновить" телефон получит файл, увидит, что он более новый,
Для того чтобы увидеть, что файл более новый тоже нужен API.
powercat писал(а): чем последний в базе/не более новый, и соответственно сохранит/не сохранит

Может конечно я ошибаюсь, но выше принцип был, как я понял, именно такой (что советовали)

Сайт не будет отображаться сайтом, это чисто для приложения адрес будет


Каждому из подключённых клиентов ты должен выдавать _разные_ данные. Поэтому так как ты говоришь не получится.

Если клиент запришиват от тебя список ресурсов, которые были изменены, например с 05 февраля 2011 года -- ты должен отобразить для этого клиента список объектов, которые с тех пор изменились или добавились.

А другой клиент попросит тебя выдать ему данные, например с 23 апреля 2012 года.

Re: Предлагаю совместный проект

Добавлено: 30 апр 2013, 14:40
powercat
Нет, немного не так...
Приложение будет работать так - кнопка Обновить. При нажатии на нее - получение информации с сервера. Если база при этом обновилась (файл был с датой, отличной от последней в базе), то приложение уведомляет, что есть новая инфа. Нет - нет. Это для каждого клиента...нет разницы - все работает через базу...В любой момент клиент может читать базу.

И почему - несерьезно?? Я иду по простому пути, зачем мне сложности?
Кнопа Обновить - скачка файла - сравнение данных даты с базой - сохранение/несохранение - уведомление юзера...Зачем еще API городить-то???
Что из этой цепочки нереализуемо так, как я написал?

Re: Предлагаю совместный проект

Добавлено: 30 апр 2013, 23:33
Tamachi
powercat писал(а):Нет, немного не так...
Приложение будет работать так - кнопка Обновить. При нажатии на нее - получение информации с сервера. Если база при этом обновилась (файл был с датой, отличной от последней в базе), то приложение уведомляет, что есть новая инфа. Нет - нет. Это для каждого клиента...нет разницы - все работает через базу...В любой момент клиент может читать базу.
И почему - несерьезно??
Потому что велосипед. Всё уже давно изобретено. Есть RSS-подписки и RSS-ридеры. Есть SOAP и WSDL -- всё уже придумано и разработано. А то что ты предлагаешь -- это прошлый век.
powercat писал(а): Я иду по простому пути, зачем мне сложности?
Это тебе только кажется, что ты идёшь по простому пути. Просто по нему ты ещё ни разу не ходил.
powercat писал(а): Кнопа Обновить - скачка файла - сравнение данных даты с базой - сохранение/несохранение - уведомление юзера...Зачем еще API городить-то???
Что из этой цепочки нереализуемо так, как я написал?
Ну, например, ты не описал то, как структурируется информация в твоём файле. Что-конкретно должна показывать прога?
Во вторых, ты не учитываешь время разбора XML на стороне клиента.
В третьих, ты не учел эффект кэширования данных на стороне хостера.
В четвёртых, как по-твоему клиент будет подписываться на интересующие его темы?

Поверь, люди не зря придумали web-сервисы (SOAP, RSS и пр...).

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 00:22
rezak90
ему всего лишь нужно что бы сервер отдавал один json файлик а андроид его уже парсил и делов то...

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 01:13
Mikhail_dev
Соглашусь с Tamachi. Мнимая простота.
ему всего лишь нужно что бы сервер отдавал один json файлик а андроид его уже парсил и делов то...
Усложним задачу. Передаём три файлика. Один изменился, второй новый, третий удалился. post запрос с параметрами? Это не то. Как на счет XML в POST запрос в виде SOAP? Самое оно. Сам только сегодня говорил с бородатыми людьми Java. В принципе заверили что в таком контексте задачи лучше так. Немного коряво, но надеюсь суть передал.
Если конечно на стороне сервера крутится Java EE, то тут целое поле для развёртывания тяжелой и малой артиллерии (Entity Persistence, Hibernate, JSF, MDB. Всё на RMI).

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 07:50
Tamachi
Можно конечно и на Java c использованием RMI -- работать будет.
Но при этом ты будешь вынужден писать клиентские приложения _только_на_Javа!

А ведь хотелось бы написать клиентов, которые не требуют установки JVM на клиентском компе!

Например, в среде Delphi (ныне Embarcadero) есть встроенный мастер, позволяющий написать собственный SOAP-клиент
меньше чем за минуту: всё делается мышкой, писать почти ничего не надо!
А для RMI в Делфях, как и везде ничего нет. Поэтому не рекоммендую привязываться к Java. Вл-первых: из пушки по воробьям; Во-воторых: сильно ограничишь себе набор клиентских приложений, способных стучаться к твоему серверу.
Не верь мифу о том, что Java кроссплатформенна!

P.S.
У SOAP часто наблюдается такой побочный эффект:
Как только ты опубликуешь свою WSDL-ссылку, программисты со всего света начнут её тестировать и писать под неё клиентские программы (потому что любая IDE обязательно позволяет это делать легко!). А на планете с 5-миллиардным населением всегда найдутся 2-3 миллиончика программистов (совсем немного, правда?), которые быстренько напишут по программке (на самых разных язаках и платформах). В общем, если уверен, что твой сервак это выдержит -- то для тебя это самый быстрый путь к популярности!

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 09:58
Mikhail_dev
А почему это java не кросплатформенная?? Как я узнал, у java с soap все хорошо, кстати.

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 10:39
rezak90
я бы с вами согласился если бы у него стояла мега задача, но ему нужно всего лишь передать один файл =)

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 11:34
Tamachi
no-- писал(а):А почему это java не кросплатформенная?? Как я узнал, у java с soap все хорошо, кстати.
Теоретически, она кроссплатформенна.
Но мой опыт показывает, что реально, это очень редко получается.
Из нескольких сотен Java-приложений, с которыми я сталкивался за последние 15 лет реально-кроссплатформенными можно назвать только 2.

Здесь я не учитываю всякий мелкий софт, использующий только верхушку Java-пирамиды.

В развитии большинства коллективов разработчиков на Java (из тех, что мне приходилось наблюдать)
всегда можно выделить следующие фазы:

1. Этап эйфории. Все всем очень довольны. Фанатеют от Java, набирают штат сотрудников, получают финансирование.

2. Сдача первого этапа первого заказа первому заказчику. Эийфория.

3. Получение новых требований от заказчика. И вот тут-то как правило и начинаются проблемы.
Вдруг выясняется, что выбранная на первом этапе технология, не подходит для реализации требований закахчика (например, потребовалась рекурсивная связь в SOAP-клиенте. Раньше все работало, а теперь разваливается из-за того, что заказчик очень агрессивно настаивает на введении рекурсивных связей.
И вот тут-то и приходит первое понимание проблемы). Типовой ответ разработчика заказчику звучит примерно так: "Если бы Вы нас заранее предупредили, что Вам потребуются рекурсивные ссылки, то мы бы выбрали протокол REST". А типовой ответ заказчика разработчику такой: "Ну так исправьте Вашу ошибку...."
И так далее и все в том же духе.

4. Тупик. Заказчик отказыватеся платить за "изменение архитектуры". Разработчик не может использовать существующую архитектуру из-за нереализованности в Java некоторых заявленных в спецификациях вещей.

5. Привлекается программист от компании Sun или Oracle. Ему наглядно демонстрируют неработоспособность заявленного Java-кода. И задают вопрос: "Что мы делаем не так?". Квалифицированный Java-разработчико от Sun разводит руками и говорит примерно следующее: "Мы не смогли реализовать полную поддержку протокола SOAP потому что у нас не хватало людей и часть персонала мы перекинули на разработку более современного протокола REST, над которым мы сейчас работаем". На вопрос разработчиков: "А как же спецификация?" специалист от Sun ответил так: "Ну так спецификацию пишем не мы. Спецификацию пишет компания Sun! А мы только пишем реализацию. Но у нас не хватает людей. А на сайте компании Sun черным по белому написано: принимайте AS IS!!!" .

6. Программисты поставлены в трудную ситуацию, они ограничены сроками, у них урезано финансироваие и архитектура, которую они используют не позволяет двигаться дальше. А расходы на смену архитектуры очень велики: заказчик не готов их оплатить. В результате пишется _платформенно_зависимый_ код, о чём разумеется не говорится заказчику. К тому времени, когда заказчик об этом догадается, программисты уже получат свои денежки и вопрос будет закрыт.

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


Кстати, второй причиной является нежелание большинства хостинг-провайдеров поднимать на своих хостах Java.

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 11:45
Tamachi
rezak90 писал(а):я бы с вами согласился если бы у него стояла мега задача, но ему нужно всего лишь передать один файл =)
Ну, допустим, android-клиент получил этот файл. И что дальше? Эту инфу надо как-то показать пользователю?
Плоским текстом? Или инфа будет как-то структурирована? Если инфа структурирована -- то спецификацию формата -- в студию!

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 11:48
rezak90
это json, конечно структурирована, распарсил - отобразил, если нужно то ещё в бд занёс.

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 12:17
Tamachi
rezak90 писал(а):это json, конечно структурирована, распарсил - отобразил, если нужно то ещё в бд занёс.
По производительности -- json значительно интереснее чем XML. Быстрее парсится, больше вмещается.

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 12:19
Tamachi
rezak90 писал(а):это json, конечно структурирована, распарсил - отобразил, если нужно то ещё в бд занёс.
Ну там ведь наверняка будет не одна статья, а несколько, рубрики и пр...

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 12:25
Tamachi
Как клиент узнает, что настало время скачивать обновлённый файл?
Он, что, должен периодически считывать какой-то другой файл, в котором будет указано время последнего обновления?
Он будет тоже в JSON?

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 13:06
neoksi
Обычный POST-запрос раз в час с uts последней синхронизации, если есть новые данные отдает json с новой меткой uts, если нет, то пустоту.

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 13:09
powercat
Резак полностью прав - задача - скачка 1! файла, распарсивание и загрузка текста из него в базу.
Никаких рубрик, т.к. это (я написал выше) не САЙТ для интернета, а сайт-сервер для приложения. Никто на него заходить, чтобы посмотреть инфу - не будет. Я просто буду выкладывать текст, оформленный так, как скажет программист, на сервак...и будет что-то типа адреса для скачки мойсайт.ru/мойфайл.xml

Как будет обновляться - клиент тыкает в кнопку Обновить. Пример - прога DVPic - получение картинок с нескольких сайтов...вряд ли там есть то, что вышенаписано ))) я так понимаю - есть страница с картинками, она скачивается и помещается в базу. При следующей скачке старые картинки удаляются...

Re: Предлагаю совместный проект

Добавлено: 01 май 2013, 13:11
neoksi
powercat
Мы все тут толкуем тебе об одном, недооценивай себя и пиши сам. =)