Вот именно. Плюс из-за этого ещё ругают Java мол многословный язык. А вот разработчики Spark доказали что можно и на Java писать лаконично и понятно, если просто не писать всякую лишнюю ерунду. У них на сайте есть примерчик REST API с использованием Sql2o, вообще нормально получается по-моему.
Эти исходники с весны лежат в сети, изменений никаких пора. Павел же написал, любая официальная информация по TON только на сайте telegram.org, все остальное не настоящее.
Вы попробуйте потратить хотябы 2000. Чтобы потратить 12000 надо тренироваться много лет каждый день, начиная с 2000.
Обычному среднестатистическому человеку очень сложно будет потратить даже 2000, очень сложно. Потратить 12000 он просто не сможет никак, ни физически, ни психолоически.
Проблема логистики тут как раз основная. Чтобы построить что-то где-то надо материалы, техника и люди. Все это можно привезти по железной дороге, это самый дешевый метод доставки грузов по суше, самый дешевый. Независимо от тягового локомотива, просто потому что дорога ровная. При налчиии уже существующей железной дороги провести переллельно высоковольтную линию в сто раз проще чем без дороги.
Но это не главное, главное что в buildRequest передается функция которую надо вызвать, и список параметров которые надо передать. Это просто непонятный сложный вызов функции.
Если бы buildRequest возвращал Request и не выполнял его сразу, а например куда-то складывал для последующего выполнения — это имело бы смысл. Но для простого вызова функции так усложнять незачем, по-моему.
Такая кажущаяся общей функция на самом деле нифига не общая и не решает никаких задач. вы также туда передаете api::request1 и api::request2 и параметры к ним, просто в очень непонятном и причудливом виде.
Надо просто сделать класс TokenApi, который будет вызывать эти же функции но добавлять токен
class TokenApi(private val api: Api, private val prefs: SharedPreferences) {
suspend fun request1(last: Long, autoView: Boolean): Answer1 {
val res = api.request1(last, autoView, headers())
saveToken(res)
return res?.body()
}
suspend fun request2(id: Long): Answer2 {
val res = api.request2(id, headers())
saveToken(res)
return res?.body()
}
private val TOKEN_KEY = "Token"
private val ID_KEY = "ID"
fun headers(): Map<String, String> {
return mapOf(
TOKEN_KEY to prefs.getString(Constants.Preferences.SP_TOKEN_KEY, ""),
ID_KEY to prefs.getLong(Constants.Preferences.SP_ID, -1).toString()
)
}
fun saveToken(res) {
val newToken = res?.headers()?.get(TOKEN_KEY)
val newID = res?.headers()?.get(ID_KEY)?.toLong()
if (newToken.notNull() && newID.notNull()) {
prefs.edit()
.putString(TOKEN_KEY, newToken)
.putLong(ID_KEY, newID)
.apply()
}
}
}
...
try {
val tApi = new TokenApi(api, prefs)
val answer1 = tApi.request1(1, false)
val answer2 = tApi.request2(1234)
} catch (e: Exception) {
viewState.showError(e.message.toString())
} catch (e: InterruptedException) {
viewState.showError(e.message.toString())
} finally {
viewState.hideProgress()
}
Вот и все, проще и понятнее чем мудреж с дженериками
Я совсем не разбираюсь в ж/д экономике, мне просто кажется что в Советском Союзе и России строили/строят контактные сети, отому что это самый дешевый вариант в долгосрочной перспективе
Конечно все это надо делать. Я просто имел в виду, что при наличии ж/д это все сделать намного проще, чем прокладывать линию электропередачи где-нить в лесу в горах.
В целом то что поезд ходит по 5 раз в день туда/сюда это хорошо, техника работает, а не простаивает. Есть только сомнения, будут ли успевать заряжаться батареи в таком режиме.
Ну а коли уж государство за все платит тут да, можно делать что угодно. Купить пять локомотивов на батареях, например, которые будут 60% времени стоять и заряжать батареи, вместо одного дизельного, который ходит постоянно.
До этого был прибит.
напишите, а то tom-то так и не создался
Обычному среднестатистическому человеку очень сложно будет потратить даже 2000, очень сложно. Потратить 12000 он просто не сможет никак, ни физически, ни психолоически.
Но это не главное, главное что в buildRequest передается функция которую надо вызвать, и список параметров которые надо передать. Это просто непонятный сложный вызов функции.
Если бы buildRequest возвращал Request и не выполнял его сразу, а например куда-то складывал для последующего выполнения — это имело бы смысл. Но для простого вызова функции так усложнять незачем, по-моему.
Надо просто сделать класс TokenApi, который будет вызывать эти же функции но добавлять токен
Вот и все, проще и понятнее чем мудреж с дженериками
возвращает Answer?, логично чтобы buildRequest возвращал Request, не?
Ну а коли уж государство за все платит тут да, можно делать что угодно. Купить пять локомотивов на батареях, например, которые будут 60% времени стоять и заряжать батареи, вместо одного дизельного, который ходит постоянно.
Я — так не думаю. Уверен, руководство ж/д определенно хорошо умеет считать.
Строительство целой железной дороги под один состав это тоже подтверждает.