Предлагаю совместный проект
Правила форума
Информация о разделе и рекомендации по созданию тем: viewtopic.php?f=18&t=1036
Информация о разделе и рекомендации по созданию тем: viewtopic.php?f=18&t=1036
Re: Предлагаю совместный проект
Схема такая - программист мне говорит - на сайте должно быть вот это и вот это и вот в таком виде. Например, мой текст, который приложение должно скачать, может лежеть на серваке:
1. Как файл (с нужным расширением);
2. Как HTML-текст (с нужным оформлением);
3. Как XML-текст - с нужными тегами.
4....
Вот программист мне и должен сказать, как ему это надо...мне-то один хрен как делать, я могу текст отформатировать в xml-ку...тут все от программиста зависит. Для простоты - я могу даже не использовать всякие движки, а текст исключительно в виде физическом виде хранить, т.е. на серваке будет лежать готовая страница, а не собираться из базы...Я ж говорю - как программисту проще, так и сделаю
1. Как файл (с нужным расширением);
2. Как HTML-текст (с нужным оформлением);
3. Как XML-текст - с нужными тегами.
4....
Вот программист мне и должен сказать, как ему это надо...мне-то один хрен как делать, я могу текст отформатировать в xml-ку...тут все от программиста зависит. Для простоты - я могу даже не использовать всякие движки, а текст исключительно в виде физическом виде хранить, т.е. на серваке будет лежать готовая страница, а не собираться из базы...Я ж говорю - как программисту проще, так и сделаю
Re: Предлагаю совместный проект
Так вот, програмист тебе говорит: на сайте должна быть реализована SOAP-служба, на входе получате дату-время, а на выходе выдаёт список ресурсов, которые были изменены с этого времени. Реализуй, опубликуй WSDL, -- тогда и обращайся к внешним программитам чтобы они для тебя что-то написали.
Re: Предлагаю совместный проект
ээ...а нафига такие сложности???
что-то мне подсказывает, что можно обойтись много более простыми методами - получить данные одного единственного файла по адресу сайта...а в приложении уже сохранить содержимое в базу и отобразить...
А то, что есть новые данные - я это могу руками в этом же файле написать - указать дату
Тогда, при нажатии в приложении "Обновить" телефон получит файл, увидит, что он более новый, чем последний в базе/не более новый, и соответственно сохранит/не сохранит
Может конечно я ошибаюсь, но выше принцип был, как я понял, именно такой (что советовали)
Сайт не будет отображаться сайтом, это чисто для приложения адрес будет
что-то мне подсказывает, что можно обойтись много более простыми методами - получить данные одного единственного файла по адресу сайта...а в приложении уже сохранить содержимое в базу и отобразить...
А то, что есть новые данные - я это могу руками в этом же файле написать - указать дату
Тогда, при нажатии в приложении "Обновить" телефон получит файл, увидит, что он более новый, чем последний в базе/не более новый, и соответственно сохранит/не сохранит
Может конечно я ошибаюсь, но выше принцип был, как я понял, именно такой (что советовали)
Сайт не будет отображаться сайтом, это чисто для приложения адрес будет
Re: Предлагаю совместный проект
Оно неправильно тебе подсказывает.powercat писал(а):ээ...а нафига такие сложности???
что-то мне подсказывает, что можно обойтись много более простыми методами - получить данные одного единственного файла по адресу сайта...а в приложении уже сохранить содержимое в базу и отобразить...
В общем: с тебя API, а после этого -- продолжим разговор.
Это несерьёзно.powercat писал(а): А то, что есть новые данные - я это могу руками в этом же файле написать - указать дату
Для того чтобы увидеть, что файл более новый тоже нужен API.powercat писал(а): Тогда, при нажатии в приложении "Обновить" телефон получит файл, увидит, что он более новый,
powercat писал(а): чем последний в базе/не более новый, и соответственно сохранит/не сохранит
Может конечно я ошибаюсь, но выше принцип был, как я понял, именно такой (что советовали)
Сайт не будет отображаться сайтом, это чисто для приложения адрес будет
Каждому из подключённых клиентов ты должен выдавать _разные_ данные. Поэтому так как ты говоришь не получится.
Если клиент запришиват от тебя список ресурсов, которые были изменены, например с 05 февраля 2011 года -- ты должен отобразить для этого клиента список объектов, которые с тех пор изменились или добавились.
А другой клиент попросит тебя выдать ему данные, например с 23 апреля 2012 года.
Re: Предлагаю совместный проект
Нет, немного не так...
Приложение будет работать так - кнопка Обновить. При нажатии на нее - получение информации с сервера. Если база при этом обновилась (файл был с датой, отличной от последней в базе), то приложение уведомляет, что есть новая инфа. Нет - нет. Это для каждого клиента...нет разницы - все работает через базу...В любой момент клиент может читать базу.
И почему - несерьезно?? Я иду по простому пути, зачем мне сложности?
Кнопа Обновить - скачка файла - сравнение данных даты с базой - сохранение/несохранение - уведомление юзера...Зачем еще API городить-то???
Что из этой цепочки нереализуемо так, как я написал?
Приложение будет работать так - кнопка Обновить. При нажатии на нее - получение информации с сервера. Если база при этом обновилась (файл был с датой, отличной от последней в базе), то приложение уведомляет, что есть новая инфа. Нет - нет. Это для каждого клиента...нет разницы - все работает через базу...В любой момент клиент может читать базу.
И почему - несерьезно?? Я иду по простому пути, зачем мне сложности?
Кнопа Обновить - скачка файла - сравнение данных даты с базой - сохранение/несохранение - уведомление юзера...Зачем еще API городить-то???
Что из этой цепочки нереализуемо так, как я написал?
Re: Предлагаю совместный проект
Потому что велосипед. Всё уже давно изобретено. Есть RSS-подписки и RSS-ридеры. Есть SOAP и WSDL -- всё уже придумано и разработано. А то что ты предлагаешь -- это прошлый век.powercat писал(а):Нет, немного не так...
Приложение будет работать так - кнопка Обновить. При нажатии на нее - получение информации с сервера. Если база при этом обновилась (файл был с датой, отличной от последней в базе), то приложение уведомляет, что есть новая инфа. Нет - нет. Это для каждого клиента...нет разницы - все работает через базу...В любой момент клиент может читать базу.
И почему - несерьезно??
Это тебе только кажется, что ты идёшь по простому пути. Просто по нему ты ещё ни разу не ходил.powercat писал(а): Я иду по простому пути, зачем мне сложности?
Ну, например, ты не описал то, как структурируется информация в твоём файле. Что-конкретно должна показывать прога?powercat писал(а): Кнопа Обновить - скачка файла - сравнение данных даты с базой - сохранение/несохранение - уведомление юзера...Зачем еще API городить-то???
Что из этой цепочки нереализуемо так, как я написал?
Во вторых, ты не учитываешь время разбора XML на стороне клиента.
В третьих, ты не учел эффект кэширования данных на стороне хостера.
В четвёртых, как по-твоему клиент будет подписываться на интересующие его темы?
Поверь, люди не зря придумали web-сервисы (SOAP, RSS и пр...).
Re: Предлагаю совместный проект
ему всего лишь нужно что бы сервер отдавал один json файлик а андроид его уже парсил и делов то...
R.id.team
Политика на форуме запрещена
Политика на форуме запрещена
- Mikhail_dev
- Сообщения: 2386
- Зарегистрирован: 09 янв 2012, 14:45
- Откуда: Самара
Re: Предлагаю совместный проект
Соглашусь с Tamachi. Мнимая простота.
Если конечно на стороне сервера крутится Java EE, то тут целое поле для развёртывания тяжелой и малой артиллерии (Entity Persistence, Hibernate, JSF, MDB. Всё на RMI).
Усложним задачу. Передаём три файлика. Один изменился, второй новый, третий удалился. post запрос с параметрами? Это не то. Как на счет XML в POST запрос в виде SOAP? Самое оно. Сам только сегодня говорил с бородатыми людьми Java. В принципе заверили что в таком контексте задачи лучше так. Немного коряво, но надеюсь суть передал.ему всего лишь нужно что бы сервер отдавал один json файлик а андроид его уже парсил и делов то...
Если конечно на стороне сервера крутится Java EE, то тут целое поле для развёртывания тяжелой и малой артиллерии (Entity Persistence, Hibernate, JSF, MDB. Всё на RMI).
Последний раз редактировалось Mikhail_dev 01 май 2013, 11:01, всего редактировалось 1 раз.
Re: Предлагаю совместный проект
Можно конечно и на Java c использованием RMI -- работать будет.
Но при этом ты будешь вынужден писать клиентские приложения _только_на_Javа!
А ведь хотелось бы написать клиентов, которые не требуют установки JVM на клиентском компе!
Например, в среде Delphi (ныне Embarcadero) есть встроенный мастер, позволяющий написать собственный SOAP-клиент
меньше чем за минуту: всё делается мышкой, писать почти ничего не надо!
А для RMI в Делфях, как и везде ничего нет. Поэтому не рекоммендую привязываться к Java. Вл-первых: из пушки по воробьям; Во-воторых: сильно ограничишь себе набор клиентских приложений, способных стучаться к твоему серверу.
Не верь мифу о том, что Java кроссплатформенна!
P.S.
У SOAP часто наблюдается такой побочный эффект:
Как только ты опубликуешь свою WSDL-ссылку, программисты со всего света начнут её тестировать и писать под неё клиентские программы (потому что любая IDE обязательно позволяет это делать легко!). А на планете с 5-миллиардным населением всегда найдутся 2-3 миллиончика программистов (совсем немного, правда?), которые быстренько напишут по программке (на самых разных язаках и платформах). В общем, если уверен, что твой сервак это выдержит -- то для тебя это самый быстрый путь к популярности!
Но при этом ты будешь вынужден писать клиентские приложения _только_на_Javа!
А ведь хотелось бы написать клиентов, которые не требуют установки JVM на клиентском компе!
Например, в среде Delphi (ныне Embarcadero) есть встроенный мастер, позволяющий написать собственный SOAP-клиент
меньше чем за минуту: всё делается мышкой, писать почти ничего не надо!
А для RMI в Делфях, как и везде ничего нет. Поэтому не рекоммендую привязываться к Java. Вл-первых: из пушки по воробьям; Во-воторых: сильно ограничишь себе набор клиентских приложений, способных стучаться к твоему серверу.
Не верь мифу о том, что Java кроссплатформенна!
P.S.
У SOAP часто наблюдается такой побочный эффект:
Как только ты опубликуешь свою WSDL-ссылку, программисты со всего света начнут её тестировать и писать под неё клиентские программы (потому что любая IDE обязательно позволяет это делать легко!). А на планете с 5-миллиардным населением всегда найдутся 2-3 миллиончика программистов (совсем немного, правда?), которые быстренько напишут по программке (на самых разных язаках и платформах). В общем, если уверен, что твой сервак это выдержит -- то для тебя это самый быстрый путь к популярности!
- Mikhail_dev
- Сообщения: 2386
- Зарегистрирован: 09 янв 2012, 14:45
- Откуда: Самара
Re: Предлагаю совместный проект
А почему это java не кросплатформенная?? Как я узнал, у java с soap все хорошо, кстати.
Re: Предлагаю совместный проект
я бы с вами согласился если бы у него стояла мега задача, но ему нужно всего лишь передать один файл =)
R.id.team
Политика на форуме запрещена
Политика на форуме запрещена
Re: Предлагаю совместный проект
Теоретически, она кроссплатформенна.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: Предлагаю совместный проект
Ну, допустим, android-клиент получил этот файл. И что дальше? Эту инфу надо как-то показать пользователю?rezak90 писал(а):я бы с вами согласился если бы у него стояла мега задача, но ему нужно всего лишь передать один файл =)
Плоским текстом? Или инфа будет как-то структурирована? Если инфа структурирована -- то спецификацию формата -- в студию!
Re: Предлагаю совместный проект
это json, конечно структурирована, распарсил - отобразил, если нужно то ещё в бд занёс.
R.id.team
Политика на форуме запрещена
Политика на форуме запрещена
Re: Предлагаю совместный проект
По производительности -- json значительно интереснее чем XML. Быстрее парсится, больше вмещается.rezak90 писал(а):это json, конечно структурирована, распарсил - отобразил, если нужно то ещё в бд занёс.
Re: Предлагаю совместный проект
Ну там ведь наверняка будет не одна статья, а несколько, рубрики и пр...rezak90 писал(а):это json, конечно структурирована, распарсил - отобразил, если нужно то ещё в бд занёс.
Re: Предлагаю совместный проект
Как клиент узнает, что настало время скачивать обновлённый файл?
Он, что, должен периодически считывать какой-то другой файл, в котором будет указано время последнего обновления?
Он будет тоже в JSON?
Он, что, должен периодически считывать какой-то другой файл, в котором будет указано время последнего обновления?
Он будет тоже в JSON?
Re: Предлагаю совместный проект
Обычный POST-запрос раз в час с uts последней синхронизации, если есть новые данные отдает json с новой меткой uts, если нет, то пустоту.
Re: Предлагаю совместный проект
Резак полностью прав - задача - скачка 1! файла, распарсивание и загрузка текста из него в базу.
Никаких рубрик, т.к. это (я написал выше) не САЙТ для интернета, а сайт-сервер для приложения. Никто на него заходить, чтобы посмотреть инфу - не будет. Я просто буду выкладывать текст, оформленный так, как скажет программист, на сервак...и будет что-то типа адреса для скачки мойсайт.ru/мойфайл.xml
Как будет обновляться - клиент тыкает в кнопку Обновить. Пример - прога DVPic - получение картинок с нескольких сайтов...вряд ли там есть то, что вышенаписано ))) я так понимаю - есть страница с картинками, она скачивается и помещается в базу. При следующей скачке старые картинки удаляются...
Никаких рубрик, т.к. это (я написал выше) не САЙТ для интернета, а сайт-сервер для приложения. Никто на него заходить, чтобы посмотреть инфу - не будет. Я просто буду выкладывать текст, оформленный так, как скажет программист, на сервак...и будет что-то типа адреса для скачки мойсайт.ru/мойфайл.xml
Как будет обновляться - клиент тыкает в кнопку Обновить. Пример - прога DVPic - получение картинок с нескольких сайтов...вряд ли там есть то, что вышенаписано ))) я так понимаю - есть страница с картинками, она скачивается и помещается в базу. При следующей скачке старые картинки удаляются...
Re: Предлагаю совместный проект
powercat
Мы все тут толкуем тебе об одном, недооценивай себя и пиши сам. =)
Мы все тут толкуем тебе об одном, недооценивай себя и пиши сам. =)