Комментарии 20
Но зачем? В том же iOS есть системное приложение «Find Friends», которое делает ровно то же самое. Думаю, и в Android есть что-то подобное.
Но ведь в Telegram есть ровно то что вам нужно!
1. «Да, я знаю, что сейчас таких приложений довольно много (даже в Google Maps недавно появился подобный функционал), и можно было использовать какое-то готовое решение, но мне было интересно написать что-то свое». Хобби у меня такое.
2. В Телеграме, насколько я понимаю, эта функция ограничена по времени, и сделать ее постоянно работающей нельзя. Хотя, может быть, я и ошибаюсь.
2. В Телеграме, насколько я понимаю, эта функция ограничена по времени, и сделать ее постоянно работающей нельзя. Хотя, может быть, я и ошибаюсь.
Максимум на 8 часов, потом нужно заново разрешать.
Нельзя сделать перманентным.
Нельзя сделать перманентным.
НЛО прилетело и опубликовало эту надпись здесь
Абстрагируясь от деталей реализации, хочу поделиться реальным опытом, что лучше всего такие трекеры гео позиции реализовывать на SMS сообщениях. Интернет слишком нежная субстанция в реальной жизни.
Насколько я знаю, в iOS штатными средствами доступ к SMS получить нельзя. А в условиях большинства российских городов интернет сейчас есть практически везде, где есть сотовый сигнал.
Я конечно прошу прощения НО:
1) Задача была поставлена как «следить за геолокацией ребенка». Вам не кажется что есть гораздо более изящные способы? Я просто не могу понять, как и зачем Вам пришло использовать в голову заметки во Вконтакте?
2) Из любой статьи должен быть хоть какой то вывод или новое знание. Здесь же его абсолютно нет. Есть только ужасный пример «забивания гвоздей в землю с помощью замороженной рыбы».
3) Просто оставлю это здесь. Фукнционал доступен больше 5 лет от Android, также поддерживается на iOS
4) Мне кажется что развернуть сервер с парочкой методов на том же самом Express было бы гораздо проще (Ну строчек 20 бы заняло) и вы бы не зависели от 3rd party libraries
5) Заключение что «из Google play приложение было удалено» — не самый лучший знак
6) Пожалуй самое последнее, если пишите Pet-project то не нужно каждый раз стараться рассказать об этом IT сообществу.
7) Если вносите изменения в 3rd party libraries, то пожалуй стоит задумать над сохранением предыдущего функционала
8) Товарищ майор, хорошая попытка трекать в реальном времени
1) Задача была поставлена как «следить за геолокацией ребенка». Вам не кажется что есть гораздо более изящные способы? Я просто не могу понять, как и зачем Вам пришло использовать в голову заметки во Вконтакте?
2) Из любой статьи должен быть хоть какой то вывод или новое знание. Здесь же его абсолютно нет. Есть только ужасный пример «забивания гвоздей в землю с помощью замороженной рыбы».
3) Просто оставлю это здесь. Фукнционал доступен больше 5 лет от Android, также поддерживается на iOS
4) Мне кажется что развернуть сервер с парочкой методов на том же самом Express было бы гораздо проще (Ну строчек 20 бы заняло) и вы бы не зависели от 3rd party libraries
5) Заключение что «из Google play приложение было удалено» — не самый лучший знак
6) Пожалуй самое последнее, если пишите Pet-project то не нужно каждый раз стараться рассказать об этом IT сообществу.
7) Если вносите изменения в 3rd party libraries, то пожалуй стоит задумать над сохранением предыдущего функционала
8) Товарищ майор, хорошая попытка трекать в реальном времени
1. В статье написано, как и зачем.
2. В статье написано, какое новое знание из нее можно почерпнуть. Например, для тех, кто хочет посмотреть, как писать Android-сервисы на Qt, есть живой рабочий пример.
3. Отвечено неоднократно и в самой статье (конкретно про Google Maps, да), и в предыдущих моих комментариях другим людям, не вижу смысла повторяться.
4a. Какие 3rd party libraries вы имеете в виду?
4b. Вот тогда бы я точно был товарищем майором с непрозрачным для пользователя сервером :) И к тому же зависел бы еще и от этого сервера.
5. В статье написано, почему именно оно было удалено.
6. Если у этого pet project открытые исходники, из которых интересующиеся могут что-то новое почерпнуть для себя — почему нет? Например, я вижу, что на данный момент статья в закладках у 34 человек, значит, хотя бы 34 человека решили, что могут из этого проекта что-то почерпнуть для себя. Не так плохо.
7. Какой именно «предыдущий функционал» и в каких именно «3rd party libraries» я не сохранил?
8. Паранойя излечима :)
2. В статье написано, какое новое знание из нее можно почерпнуть. Например, для тех, кто хочет посмотреть, как писать Android-сервисы на Qt, есть живой рабочий пример.
3. Отвечено неоднократно и в самой статье (конкретно про Google Maps, да), и в предыдущих моих комментариях другим людям, не вижу смысла повторяться.
4a. Какие 3rd party libraries вы имеете в виду?
4b. Вот тогда бы я точно был товарищем майором с непрозрачным для пользователя сервером :) И к тому же зависел бы еще и от этого сервера.
5. В статье написано, почему именно оно было удалено.
6. Если у этого pet project открытые исходники, из которых интересующиеся могут что-то новое почерпнуть для себя — почему нет? Например, я вижу, что на данный момент статья в закладках у 34 человек, значит, хотя бы 34 человека решили, что могут из этого проекта что-то почерпнуть для себя. Не так плохо.
7. Какой именно «предыдущий функционал» и в каких именно «3rd party libraries» я не сохранил?
8. Паранойя излечима :)
3rd party — VK API
— if (mCanceled) return;
+ if (mErrorOccured) return; mErrorOccured = true;
Вот вам не кажется что здесь вы все таки изменили функционал, который отвечал за cancel request'а? И что ваш новый функционал сработает только после получения второго исключения? То есть по сути вы добавили игнорирование исключений если их больше чем одно.
— if (mCanceled) return;
+ if (mErrorOccured) return; mErrorOccured = true;
Вот вам не кажется что здесь вы все таки изменили функционал, который отвечал за cancel request'а? И что ваш новый функционал сработает только после получения второго исключения? То есть по сути вы добавили игнорирование исключений если их больше чем одно.
1. Ну, как сказать. Это официальный SDK от ВК.
2. Конечно, изменил. В этом и суть. Раньше provideError() при отмене пакетного запроса просто сразу выходил, и не вызывал пользовательские обработчики onError() для упакованных в него подзапросов, хотя по описанию в коде VKRequest.cancel() он должен это делать («Cancel current request. Result will be not passed. errorBlock will be called with error code»). В общем, вам надо бы самому попробовать, как работает cancel() в случае пакетного запроса с моей правкой и без нее, тогда вам будет не «казаться», а вы будете точно знать, что происходит в том и в другом случае.
Насчет «игнорирования исключений, если их больше, чем одно» — если вы посмотрите код повнимательнее, то вы убедитесь, что VKBatchRequest изначально (почему-то) устроен так, что у него, так сказать, «одна ошибка на всех», то есть, если при выполнении какого-то подзапроса из пакета происходит ошибка, то она возвращается всем подзапросам, при этом остальные не успевшие выполниться подзапросы «тихо» прибиваются через вызов cancel(). Но сделано это было не совсем корректно — если cancel() вызывается специально, а не в результате ошибки в подзапросе, то обработчики ошибок не вызываются вовсе, что какбе нарушает контракт в описании принципа работы VKRequest.cancel(). Именно эту проблему я и исправлял, потому что я в своем коде рассчитывал на исполнение этого контракта (в iOS-версии это работает так, как и положено).
2. Конечно, изменил. В этом и суть. Раньше provideError() при отмене пакетного запроса просто сразу выходил, и не вызывал пользовательские обработчики onError() для упакованных в него подзапросов, хотя по описанию в коде VKRequest.cancel() он должен это делать («Cancel current request. Result will be not passed. errorBlock will be called with error code»). В общем, вам надо бы самому попробовать, как работает cancel() в случае пакетного запроса с моей правкой и без нее, тогда вам будет не «казаться», а вы будете точно знать, что происходит в том и в другом случае.
Насчет «игнорирования исключений, если их больше, чем одно» — если вы посмотрите код повнимательнее, то вы убедитесь, что VKBatchRequest изначально (почему-то) устроен так, что у него, так сказать, «одна ошибка на всех», то есть, если при выполнении какого-то подзапроса из пакета происходит ошибка, то она возвращается всем подзапросам, при этом остальные не успевшие выполниться подзапросы «тихо» прибиваются через вызов cancel(). Но сделано это было не совсем корректно — если cancel() вызывается специально, а не в результате ошибки в подзапросе, то обработчики ошибок не вызываются вовсе, что какбе нарушает контракт в описании принципа работы VKRequest.cancel(). Именно эту проблему я и исправлял, потому что я в своем коде рассчитывал на исполнение этого контракта (в iOS-версии это работает так, как и положено).
что VKBatchRequest изначально (почему-то) устроен так, что у него, так сказать, «одна ошибка на всех»
Может быть ключевое слово «Batch» о чем то должно о чем то подсказать?
Да я в общем-то не против такого подхода, но если бы я писал реализацию этого волшебного ключевого слова, я бы, пожалуй, сделал несколько по-другому: ошибка возвращается только тем подзапросом, в процессе выполнения которого она произошла, остальные (неуиноуатые) возвращают VK_CANCELED. Ну, как написали — так написали, в принципе, вариант от ВК тоже имеет право на существование, может быть, там действительно у них трудно отделить мух от котлет и виноватые подзапросы от не очень виноватых.
6. Эта статья полезнее 90% материалов на хабре, почему нет?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Как я делился местоположением через ВК API