EA
Никакой портянки нативного краша
Size: a a a
2020 September 11
DS
Instant run пишет incompatible api level. Что не так? sdk 29
DS
I
Dmitry Sokolov
Instant run пишет incompatible api level. Что не так? sdk 29
а на девайсе какой Android?
I
Должен быть 8+
DS
Должен быть 8+
На старой андроид студио с 5+ работало
I
Dmitry Sokolov
На старой андроид студио с 5+ работало
мб это был Instant Run? Apply Changes это другое
I
по-другому работает
DS
мб это был Instant Run? Apply Changes это другое
ну Apply Changes же заменил Instant Run?
I
Dmitry Sokolov
ну Apply Changes же заменил Instant Run?
ну да. И стал Android 8+
DS
Печально
B
Привет, такой вопрос. Насколько плохой является практика использования callback’ов в качестве параметров метода Presenter? Это к ситуации, когда мне нужно выполнить действие с данными, после того, как они загрузились.
И если это bad practice, то какой подход стоит использовать в таких случаях?
Вот теоритический пример
interface SomeView {
fun onDataLoaded(data: MyData, postAction: (MyData) -> Unit)
}
interface MyPresenter {
fun loadSomeData(postAction: (MyData) -> Unit)
}
class MyPresenterImpl : MyPresenter {
private var view: SomeView? = null
override fun loadSomeData(postAction: (MyData) -> Unit) {
val data = mockData()
view?.onDataLoaded(data, postAction)
}
private fun mockData() = MyData(null)
}
И если это bad practice, то какой подход стоит использовать в таких случаях?
Вот теоритический пример
interface SomeView {
fun onDataLoaded(data: MyData, postAction: (MyData) -> Unit)
}
interface MyPresenter {
fun loadSomeData(postAction: (MyData) -> Unit)
}
class MyPresenterImpl : MyPresenter {
private var view: SomeView? = null
override fun loadSomeData(postAction: (MyData) -> Unit) {
val data = mockData()
view?.onDataLoaded(data, postAction)
}
private fun mockData() = MyData(null)
}
NM
похоже на MVVM-архитекутру
NM
если это MVP то interface SomeView должен содержать методы для задания состояния вьюшек, которые быдет вызывать презентер когда у него появятся данные
AY
похоже на MVVM-архитекутру
По-моему вообще ничем на MVVM не мохоже, а вот на MVP - самое оно.
AY
Привет, такой вопрос. Насколько плохой является практика использования callback’ов в качестве параметров метода Presenter? Это к ситуации, когда мне нужно выполнить действие с данными, после того, как они загрузились.
И если это bad practice, то какой подход стоит использовать в таких случаях?
Вот теоритический пример
interface SomeView {
fun onDataLoaded(data: MyData, postAction: (MyData) -> Unit)
}
interface MyPresenter {
fun loadSomeData(postAction: (MyData) -> Unit)
}
class MyPresenterImpl : MyPresenter {
private var view: SomeView? = null
override fun loadSomeData(postAction: (MyData) -> Unit) {
val data = mockData()
view?.onDataLoaded(data, postAction)
}
private fun mockData() = MyData(null)
}
И если это bad practice, то какой подход стоит использовать в таких случаях?
Вот теоритический пример
interface SomeView {
fun onDataLoaded(data: MyData, postAction: (MyData) -> Unit)
}
interface MyPresenter {
fun loadSomeData(postAction: (MyData) -> Unit)
}
class MyPresenterImpl : MyPresenter {
private var view: SomeView? = null
override fun loadSomeData(postAction: (MyData) -> Unit) {
val data = mockData()
view?.onDataLoaded(data, postAction)
}
private fun mockData() = MyData(null)
}
Если хотите можете попробовать MVVM, а именно передавать данные через LiveData и подписываться на них во Fragment'e/Activity, таким образом можно уйти от callback`ов
RR
Ребята привет)
Есть вот такое поле в Entity
подскажите какой метод нужно написать, чтобы room не ругался, что это не примитив?
@SerializedName("genre_ids")
val genreIds: List<Int>Есть вот такое поле в Entity
подскажите какой метод нужно написать, чтобы room не ругался, что это не примитив?
B
Если хотите можете попробовать MVVM, а именно передавать данные через LiveData и подписываться на них во Fragment'e/Activity, таким образом можно уйти от callback`ов
Я бы с радостью и, где могу, перехожу. В данном случае уже просто есть готовый класс, в который не хотелось бы вносить много изменений, ради одного метода
Поэтому интересует - плохо это, хорошо или же так просто есть.
Ибо, с точки зрения, утечек никаких быть не должно, если вовремя detach'ить вью от презентера
Поэтому интересует - плохо это, хорошо или же так просто есть.
Ибо, с точки зрения, утечек никаких быть не должно, если вовремя detach'ить вью от презентера
NM
Ребята привет)
Есть вот такое поле в Entity
подскажите какой метод нужно написать, чтобы room не ругался, что это не примитив?
@SerializedName("genre_ids")
val genreIds: List<Int>Есть вот такое поле в Entity
подскажите какой метод нужно написать, чтобы room не ругался, что это не примитив?
Описать TypeConverter для списка интов https://developer.android.com/training/data-storage/room/referencing-data
NM
Я бы с радостью и, где могу, перехожу. В данном случае уже просто есть готовый класс, в который не хотелось бы вносить много изменений, ради одного метода
Поэтому интересует - плохо это, хорошо или же так просто есть.
Ибо, с точки зрения, утечек никаких быть не должно, если вовремя detach'ить вью от презентера
Поэтому интересует - плохо это, хорошо или же так просто есть.
Ибо, с точки зрения, утечек никаких быть не должно, если вовремя detach'ить вью от презентера
где вызывается
presenter.loadSomeData() почему нужен именно callback?