|
|
|
Клиентское приложение
|
|||
|---|---|---|---|
|
#18+
Добрый день! Появилась необходимость в клиенстком приложение для двухзвенной системы управление предприятием. Для этого решено создать аппликейшн-сервер для мобильных клиентов. Набросал его на дельфийной DataSnap REST. Начал создавать в еклипсе клиента. Немного побаловался - все работает. Но возникло несколько вопросов: 1. Куда сложить всю логику, косающуюся REST? в Аппликейшн или создавать отдельный сервис? 2. Т.к. нужны callback-механизмы, соответственно, как отслеживать ситуации, когда коннект отвалился? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2015, 12:54 |
|
||
|
Клиентское приложение
|
|||
|---|---|---|---|
|
#18+
БезИмени1. Куда сложить всю логику, косающуюся REST? в Аппликейшн или создавать отдельный сервис? а что имеется в виду под Аппликейшн? Класс наследник android.app.Application? а под сервисом? Логику складывать в отдельный класс. Откуда она будет вызываться, из приложения или сервиса (андроид-сервиса) зависит от постановки задачи. БезИмени2. Т.к. нужны callback-механизмы, соответственно, как отслеживать ситуации, когда коннект отвалился? опять же таки, зависит от постановки задачи. можно использовать гугловский Cloud Messaging (там все свое), если это не приемлимо, реализовывать свой велосипед ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2015, 14:29 |
|
||
|
Клиентское приложение
|
|||
|---|---|---|---|
|
#18+
сервис, и механизмы общения между ним и активити/фрагментами а сервис уж пускай всей сетевой логикой занимается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2015, 20:23 |
|
||
|
Клиентское приложение
|
|||
|---|---|---|---|
|
#18+
БезИмениДобрый день! Появилась необходимость в клиенстком приложение для двухзвенной системы управление предприятием. Для этого решено создать аппликейшн-сервер для мобильных клиентов. Набросал его на дельфийной DataSnap REST. Начал создавать в еклипсе клиента. Немного побаловался - все работает. Но возникло несколько вопросов: 1. Куда сложить всю логику, косающуюся REST? в Аппликейшн или создавать отдельный сервис? 2. Т.к. нужны callback-механизмы, соответственно, как отслеживать ситуации, когда коннект отвалился? 1. Аппликейшн (проще) 2. ХЗ, зависит от реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 03:25 |
|
||
|
Клиентское приложение
|
|||
|---|---|---|---|
|
#18+
В 1-м вопросе согласен. С т.з. отладки application проще. Если его грамотно разделить UI и логику, потом можно написать и сервис, отдав туда отлаженный функционал. Второе - callback не всегда лучший способ общения. Часто встречаются задачи с довольно интенсивным обменом, они с какой-то частотой все-равно лазят на сервер. Тогда вообще нет смысла делать обратный канал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 16:39 |
|
||
|
Клиентское приложение
|
|||
|---|---|---|---|
|
#18+
krapotkinВ 1-м вопросе согласен. С т.з. отладки application проще. Если его грамотно разделить UI и логику, потом можно написать и сервис, отдав туда отлаженный функционал. ну так, а если проще, зачем городить огороды. проще - значит надежнее! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 21:37 |
|
||
|
|
start [/forum/topic.php?fid=13&gotonew=1&tid=1331452]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 254ms |
| total: | 404ms |
| 0 / 0 |
