Евгений Абросимов говнокода написать везде можно много и со вкусом. согласитесь минимум - все что надо и ничего лишнего, простой - ничего лишнего, все ясно сразу, так что тут ==, но не ===
@Petroveg конечно использую, но совсем в редких случаях, когда мне лень написать класс для этого. Считаю, что стили должны быть в стилях, а не в js.
Иначе для добавления функционала, правки текущего да и просто отладки, приходится пользоваться поиском по файлам js, и не факт что объект передаваемый в $().css() не был изменен в процессе.
@sl1m_dogg нет, для этого нужны behaviors (классы поведения) которые будут содержать валидацию при создании/добавлении/изменении и прочих нужны операциях
причем все это еще можно прицепить к модели событий, чтобы не мучаться с ручными вызовами
@davidnum95 как я сказал выше - этого вполне достаточно, я опишу общий алгоритм, т.к. не помню всех деталей работы по дроид.
все банально - запуск приложения - подключаетесь к бд, выполняете проверку на наличие таблицы одной из тех что вам надо. - таблицы нет - значит это первый запуск приложения и данные необходимо внести.
данные придется хранить внутри приложения, в каком угодно виде (файл, или в памяти) но удобнее имхо будет в файле *.sql, так вы просто считаете файл и сделаете запрос к бд.
@kolpak
1. у технологии есть(или были) вопросы к быстродействию, видимо вы не так понимаете, мой рецепт будет отличаться по производительности от обычного браузера не более чем на 2% т.к. в приложении больше ничего нету кроме перехода по адресу.
но тормоза вы получите конечно, но не из-за phonegap, ведь обычный сайт - не мобильное приложение, я гарантирую вам это(что тормоза будут). писалось бы изначально под моби - было бы все ок. (тут не только верстка имеется ввиду)
размещение в аппсторе - ну были слухи, 1 написал остальные подхватили, не стоит верить им, по работе проблем не замечал
про Phonegap написал, т.к. исходя из вопроса, я понял что вы бы смогли написать данное приложение именно на нем, но не знаете куда копать.
ок, есть еще + 1 вариант, берете по примеру из каждой сдк: дроида, ios...
удаляете содержимое через Android Studio, Xcode. т.е. мышкой убераете елементы, а не файлы в проекте.
кидаете на приложение WebView, (UIWebView) указываете в опциях адрес - вуаля, супер производительное приложение для просмотра сайта.
странный вы человек, не разбираетесь, а думаете что медленно будет работать, хотите других технологий, а их в аппстор пропустят? а они не будут тормозить? удачи вам
@sprosvirnin запутанно как то получается, немного странный код у вас видимо. а как насчет такого: добавьте в класс где константа, метод-гетер который бы возвращал нужную вам константу
@IgorO2 ну насчет периодов, тут еще я бы поспорил.
лучше конечно бы сделать корреляцию с временем года, т.к. ассоциации у людей обычно с количеством света от солнца и его положением на момент.
а насчет 1 часа дня, это опечатка, исправил
@adrianovalexey отправили свои комменты, а потом прошла синхронизация.
- для этого надо хранить дату создания елемента, загружать на сервер можно будет в любом порядке, ведь при отображении можно сортировать по дате.
честно - я что то не пойму в чем сложность синхронизации историй поездок, т.к. видимо я пока плохо понял суть.
как я понимаю двое могут вместе в офллайне вести маршрут, а затем загрузить на сервер отчет, и тут возникает проблема? я конечно плохо понял идею, но ведь отчеты от каждого пользователя уникальны, а даже если и не так, супруги вели не зная друг о друге, то все равно, это не беда, ведь поидее под каждым чекином, фоткой можно отобразить комент пользователя, описание, отчет, и прочее.
если логика отображения другая, стоит подумать как лучше отобразить это дело, но я вот все равно никак не найду чего то такого, где возникнет конфликт мержа.
@adrianovalexey
1. Можно более конкретный пример, не понимаю в чем проблема мержа когда данные приходят, ведь они никак не придут одновременно.
Пришли данные от 1 записали. Пришли данные от 2 - записали. Если есть что то специфическое - перед запись проверяйте на существование, и вносите изменения, но как мержить уже вам решать.
Главная роль? Где то я уже такое слышал, и мне совсем такая терминология не нравится. Оффлайн приложения на "тонком" клиенте не сделаешь, "толстый" клиент - ок, но хватит ли производительности для функционала? - Вывод: стоит найти золотую середину для конктретного случая, так что если ищете помощи, рассказывайте суть, рассказать нельзя - думайте сами.
2. Лог изменений? На сервере - нет, на сервере только логи, с сутью: время, событие, данные, результат. На клиенте, разве что вы разрабатываете IDE или рисовалку или офисный пакет, в общем везде где нужен лог изменений.
Иначе логи или не писать (на клиенте все же накладно хранить много логов), или сливать время от времени на сервер, если вы собираете статистику.
