Дмитрий Гукетлев

Acer A500 на маркете от 17

В наличии usb хост, слот для флэшки, большое сообщество, официальный и кастомный ICS. (У меня кастом от fguy если что )

мне кажется можно еще упростить решение:

0. запоминаем текущее значение. допустим ноль.

1. Идем вправо, считая шаги пока не дойдем до нуля, при этом прошли A шагов
2. Ставим вместо нуля единицу
3. Идем на А шагов влево (на исходную)
4. Если там 1 (значение изменилось) то N=A, если там 0 то идем на пункт 1

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

Распишите подробнее. Я тоже сейчас занимаюсь изобретением «велосипеда которого еще никогда не было». Может мы одно и тоже делаем, ну или похожее.

Честно говоря, я уже немного подзабыл пхп, но если мне изменяет память при разрыве соединения апач\другой вэб сервер убьет поток с пхп скриптом. По крайней мере при настройках по-умолчанию. Я намекаю на то, что если вы и найдете способ убить соединение, то уверены ли вы что Апач не убьет ваш скрипт?

Если вам нужно сделать асинхронную обработку, вставьте в конец страницы невидимый img, а src ему ссылку на скрипт. Страница будет загружена, пользователь доволен а обработка пойдет в фоне. Но тут нет гарантии, что пользователь не закроет браузер пока ваша обработка не кончится (картинка не «загрузится»). Можете ему прогресс бар какой аяксом показывать. (Один скрипт, на который ссылка в картинке, пилит что-то в фоне и пишет прогресс в базу, другой его пользователю по аяксу отдает). А вообще все эти серверные обработки на PHP вещь неблагодатная. Лучше всего заведите табличку, в которую пишите все что надо асинхронно выполнить, и пусть каждые 10 секунд по cron на сервере запускается тот же php (хотябы через wget специального урла) и делает все асинхронное. Последнее решение наиболее стабильное. И избавляет от необходимость держать открытым браузер.

НЕ ПИШИТЕ КАПСОМ. ЭТО ВСЕХ БЕСИТ. ДАЖЕ ЕСЛИ СДЕЛАНО С ПОМОЩЬЮ TEXT-TRANSFORM: UPPERCASE;

От себя посоветую ИУ-6 и АК-5. Одно и тоже только АК в Реутове, проходной бал ниже. МГТУ :)

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

Посмотрите планшетный гугл, на мой вкус отличный пример. тыц

Можете заказчику показать и убедить его.

Можно и нужно. Не сложно.
Пины наверно не сконфигурировал. У каждого пина на мк есть много функций, нужно выбирать какие ты хочешь использовать, выставляя биты конфигурации (обычно ide предоставляет для этого удобный интерфейс). Авр студия например. Ну или в даташите посмотри какие биты надо выставить чтобы включить пин который ты хочешь на gpio.
Кроме того обычно есть режимы работы ноги (1=+питания или 1=земля) это тоже надо выставить.

И лучше диоды через токоограничительный резистор подключать. А то и ногу можно спалить.

Искренне хотел вам помочь на за 5 минут не понял чего вы всетаки хотите.
Думаю проблема в том, что вам надо исподьзовать join'ы и джойнить все к счету, это должно решить проблему дублей.

А вообще названия полей вырвиглазные, читать неприятно. За одно Schet.shet вас тот кто будет поддерживать этот код возненавидит, уж используйте одно название.

И вообще начните с чтения книг, это скучно но полезно.

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

> Но С как я слышал платно работает с другими БД, а не с MS SQL и не стабильно.
хрень какая-то. www.mysql.com/downloads/connector/net/ все бесплатно, стабильно. Другой вопрос, что всякие плюшечки c# типа LINQ с mysql не работают.

> C#+MS sql. Но php сайт будет с нуля. Я буду писать. Никогда не писал на php для работы с ms sql.
с точки зрения php разницы минимум. Вместо одной функции вызывать другую, а вообще сайт должен быть абстрагирован от БД, и должен быть уровень-прослойка, позволяющий мигрировать с одной бд на другую. Вопрос только в том что сам SQL у MS SQL сервера немного отличается от MySQL. Вы его видимо не знаете.

Про яву не скажу, т.к. не пишу на ней.

Вообще сам факт того, что вы хотите из вашего приложения долбиться на удаленную базу (ту же с которой работает сайт) странный. Что будете делать если в агенстве недвижимости порт 3306 (или какой там у mysql) закрыт (а так чаще всего и есть, закрыто все кроме 80)? А если у них инет через прокси, причем не SOCKS5, а HTTP (а так чаще всего и есть)? Что вы со своей архитектурой будете делать когда захотите права доступа к разным объектам проверять? Как вы на уровне БД запретите юзеру править одни строки в таблице и разрешите править другие? Что будете делать когда понадобится структуру бд изменить? Переустанавливать все 100500 развернутых клиентов потому что там захардкожены уже кривые запросы, а на время переустановки вся система встанет (бд уже обновили, а клиенты еще нет)?

Повторюсь — единственное правильное решение сделать на сайте API и дергать его из приложения. Если бы все писали на c# мог бы вам посоветовать Web Service сделать, а с php вам придется самому стандарт взаимодействия скорее всего изобретать. Не мудрствуя лукаво можете просто гонять XML между сайтом и программой. Программа отправляет POST'ом XML с параметрами запроса, получает XML с ответом, обработка XML есть и в c# и в php. Или json можете использовать, но лучше XML он в c# лучше поддерживается. Такая архитектура снизит связность частей системы, добавит дополнительные уровни абстракции, развяжет вам руки для последующего развития.

Лучше помоему сделать файловые менеджер полностью копирующий Far или Total comander. Удобней же :-)

Desire S
Android 2.3
встроенный браузер — нет звука
Opera mobile — нет звука.

Про выгрузку страниц из фона вам правильно написали. Подумайте о ЦА вашей разработки. Я бы не стал этим пользоваться.

Промучался все выходные. Решил что адекватное решение только одно — продать MacBook, купить другой ноут :-)

Еще советую походить вот сюда:
stackoverflow.com/
www.askdev.ru/

Не пиар. Просто сам там часто бываю, да и в выдаче гугла они на первых местах.

Нууу было уже вроде как

translate.google.com/translate_tts?ie=UTF-8&q=%D1%82%D0%B5%D0%BA%D1%81%D1%82%20%D0%B2%20%D0%B0%D0%B4%D1%80%D0%B5%D1%81%20%D0%BF%D1%80%D1%8F%D0%BC%D0%BE%20%D0%B1%D1%83%D0%BA%D0%B2%D0%B0%D0%BC%D0%B8&tl=ru

Вот тут склеивают:
habrahabr.ru/blogs/python/115091/

True Launch Bar бесплатна для жителей бывшего СССР. Удовлетворяет всем вашим требованиям. Вот так выглядит:

ответ кроется в понимании http протокола. Давайте по частям:

1) передача сторонний сайт — ваш сайт. Тут все просто, сайты написанные на php в общем случае взаимодействуют по http. Есть какие-то экзотические варианты с сокетами в php но по моему надо использовать инстурмент сообразно его предназначению. Итак к делу. Сторонний сайт делает на ваш сайт http запрос, предавая в post (или гет) необходимую информацию. Скорее всего защищая её передачей хэш суммы с некотрой известной только сайтам солью. Например так:
your-site.ru/api/setNumber?num=10

2) Передача ваш сайт-ваше серверное приложение. самая сложная часть. Секрет кроется в том, что возможности php по работе с хостовой системой очень ограничены. Не уверен что php сможет послать например сообщение другому процессу на серверной системе. Тут обмен может быть реализован например так: php запускает какую-нибудь микропрограмму с параметрами, которая передает программе-серверу информацию, например послав системное сообщение (это правда черевато проблемами безопасности, разрешать php запуск программ довольно опасно). Либо php пишет информацию в некотрую БД а программа-сервер постоянно эту БД просматривает на предмет наличия новой информации.

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

Теперь поехали назад:
1) клиентское приложение — серверное приложение
Уже обсуждалось. У нас есть открытый сокет, по нему и отправляем.

2) серверное приложение — ваш сайт.
А вот приложению отослать информацию вашему сайту очень просто, достаточно сделать из серверного приложения http запрос на ваш сайт.

3) ваш сайт — сторонний сайт
снова просто — http запрос из вашего php скрипта на на сторонний сайт

Обратите внимание, что если для передачи «туда» все элементы цепочки важны: сторонний сайт скорее всего может сделать только http запрос, значит нужен ваш сайт который его примет. Ваш сайт не сможет держать сокет и послать информацию в программу клиент — нужна ваша программа сервер. То при походе обратно можно смело исключать любой из пунктов: ваша программа сервер может сама, без помощи вашего сайта, сделать запрос на сторонний сайт. Больше того программа клиент сама может сделать запрос на сторонний сайт и вообще можно выкинуть из обратного пути вашу программу-сервер и ваш сайт. Естественно все это надо защищать шифрованием от чтения и солями от подделки. (как подумайте сами, все довольно просто :) )

Тут уже надо смотреть из организации системы. Я бы оставил программу-сервер как основной обработчик апи, а ваш сайт сделал бы максимально простым с единственной функцией передачи информации в программу сервер.

Это если говорить о вашей схеме: в жизни скорее всего «ваш сайт» вообще не существует, а «программа сервер» имеет модуль апача или сама по себе слушает соответствующий порт и отвечает на http запросы. Чтобы исключить затык с передачей информации из php в программу сервер. Это место будет все время глючить. Т.к. php для этого банально не предназначен. А в случае реализации с опросом БД будет дополнительная задержка.