В перфектния свят на Android основният език на Java е наистина модерен, ясен и елегантен, можете да пишете по-малко, като правите повече и всеки път, когато се появи нова функция, разработчиците могат да я използват, като увеличат версията в Градле . Чрез създаването на хубаво приложение, функцията изглежда напълно проверима, разширяема и поддържаема. Нашите дейности не са твърде големи и сложни, можем да променим източниците на данни от базата данни в мрежата, без твърде много разлики и т.н. Звучи добре, нали? За съжаление, в света на Android това не е идеално. Google продължава да се стреми към съвършенство, но всички знаем, че идеалните светове не съществуват. Затова трябва да си помогнем на това велико пътешествие в света на Android.
Kotlin е основен играч в света на Android. Но може ли да замени Java? Какво е Kotlin и защо трябва да го използвате?
И така, първият език. Мисля, че Java не е майсторът на елегантността или яснотата и не е нито модерен, нито изразителен (и предполагам, че сте съгласни). Недостатъкът е, че под Android N все още сме ограничени до Java 6 (включително някои малки части от Java 7). Разработчиците също могат да прикачат RetroLambda да използвате ламбда изрази във вашия код, което е много полезно при използване RxJava . На върха на Android N можем да използваме част от по-новата функционалност Java 8, но все пак това е старата тежка Java. Много често чувам [разработчици на Android] (https://www.toptal.com/android) да казват „Иска ми се Android да поддържа по-хубав език, както iOS прави с Swift“. Ами ако ви кажа, че можете да използвате много хубав и прост език, с нулева защита, ламбда и много други нови функции? Добре дошли в Котлин.
Какво е Kotlin?
Котлин е нов език (понякога известен като Swift за Android), разработен от екипа на JetBrains и сега е в неговата версия 1.0.2. Това, което го прави полезен при разработката на Android е, че се компилира в JVM байт код и може да се компилира и с JavaScript. Той е напълно съвместим с Java и Kotlin код може просто да се конвертира в Java код и обратно (има плъгин от JetBrains). Това означава, че Kotlin може да използва всякакви рамки, библиотеки и др., Написани на Java. В Android той е интегриран от Gradle. Ако имате съществуващо приложение за Android и искате да внедрите нова функция в Kotlin, без да пренаписвате цялото приложение, просто започнете да пишете в Kotlin и ще работи.
Но кои са „страхотните нови функции“? Позволете ми да изброя няколко:
Параметри на име и незадължителни функции
Fecha de crear Diversión(day: Int, month: Int, year: Int, hour: Int = 0, minute: Int = 0, second: Int = 0) { print('TEST', '$day-$month-$year $hour:$minute:$second') } Можем да извикаме метода Дата на създаване По различни начини
Fechacreación(1,2,2016) prints: ‘1-2-2016 0:0:0’ Fechacreación(1,2,2016, 12) prints: ‘1-2-2016 12:0:0’ Fechacreación(1,2,2016, minute = 30) prints: ‘1-2-2016 0:30:0’ Нулева сигурност
Ако променлива може да бъде нула, кодът няма да се компилира, освен ако не го принудим. Следният код ще има грешка: nullable Var може да бъде нула:
var nullableVar: String? = “”; nullableVar.length; За да компилираме, трябва да проверим дали е нула или не:
if(nullableVar){ nullableVar.length } Или дори по-кратко:
nullableVar?.length По този начин, ако nullableVar е null, нищо не се случва. В противен случай можем да маркираме променливата като ненулируема, без въпросителен знак след тип:
var nonNullableVar: String = “”; nonNullableVar.length; Този код се компилира и ако искаме да присвоим null на non-NullableVar, компилаторът ще покаже грешка.
Операторът Elvis също е много полезен:
var stringLength = nullableVar?.length ?: 0 Така че, когато nullableVar е null (така че nullableVar? .Length води до null), stringLength ще има стойност 0.
Изменяеми и неизменяеми променливи
В горния пример използвам където при дефиниране на променлива. Това е променливо, можем да го преназначим, когато пожелаем. Ако искаме тази променлива да бъде неизменна (в много случаи трябва), използваме часа (като стойност, а не променлива):
каква е функцията на финансовия директор?
val immutable: Int = 1 След това компилаторът няма да ни позволи да се пренастроим към неизменяем.
Ламбди
Всички знаем какво е ламбда, така че тук ще покажа как можем да го използваме в Kotlin:
button.setOnClickListener({ view -> Log.d('Kotlin','Click')}) Или ако функцията е единственият или последният аргумент:
button.setOnClickListener { Log.d('Kotlin','Click')} Разширения
Разширенията са много полезна езикова функция, благодарение на която можем да „разширим“ съществуващите класове, дори когато са окончателни или нямаме достъп до техния изходен код.
Например, за да получим стойност за редактиране на текстов низ, вместо да пишем editText.text.toString () всеки път, когато можем да напишем функцията:
fun EditText.textValue(): String{ return text.toString() } Или дори по-кратко:
fun EditText.textValue() = text.toString() И сега, с всеки екземпляр на EditText :
editText.textValue() Или можем да добавим свойство, което връща същото:
var EditText.textValue: String get() = text.toString() set(v) {setText(v)} Претоварване на оператора
Понякога е полезно, ако искаме да добавяме, умножаваме или сравняваме обекти. Kotlin позволява претоварване на: двоични оператори (плюс, минус, plusAssign, диапазон и др.), Оператори на масиви (get, set, get range, set range) и равни и унарни операции (+ a, -a и др.) .
Клас данни
Колко реда код трябва да внедрите потребителски клас в Java с три свойства: копиране, равно, хеш код Y. toString ? В Kotlin ви трябва само един ред:
Usuario de Clase de Datos(nombre del val: String, apellido del val: String, edad del val: Int) Този клас данни предоставя методите jednak (), hashCode () и copy (), а също toString (), което отпечатва Потребителя като:
Usuario(nombre=John, apellido=Doe, edad=23) Класовете данни предоставят и някои други полезни функции и свойства, които могат да се видят в документацията на Kotlin.
Разширения Anko
Използвайте Нож за масло или разширения за Android, нали? Какво ще стане, ако дори не е необходимо да използвате тази библиотека и след деклариране на изгледите в XML, просто я използвате от кода по нейния идентификатор (както при XAML в C #):
loginBtn.setOnClickListener{} import kotlinx.android.synthetic.main.activity_main.* Kotlin има много полезни [разширения Anko] (https://github.com/Kotlin/anko) и с това не е нужно да казвате на неговата активност какво представлява loginBtn , вие го знаете просто като 'импортирате' xml:
interface CreateUserView : View { fun showEmptyNameError() /* show error when name is empty */ fun showEmptySurnameError() /* show error when surname is empty */ fun showUserSaved() /* show user saved info */ fun showUserDetails(user: User) /* show user details */ } В Anko има много други полезни неща, включително начинаещи дейности, средни дейности и т.н. Това не е основната цел на Anko - тя е проектирана да създава лесно оформления на кода. Така че, ако трябва да създадете оформление за програмиране, това е най-добрият начин.
Това е само кратък преглед на Kotlin. Препоръчвам да прочетете блога на Антонио Лейва и неговата книга - Kotlin за разработчици на Android , и разбира се официалния сайт на Kotlin.
Какво е MVP и защо?
Хубав, мощен и ясен език не е достатъчен. Много е лесно да пишете разхвърляни приложения на всички езици без добра архитектура. Разработчиците на Android (главно тези, които тепърва стартират, но и по-напредналите) често дават на Activity отговорността за всичко около тях. Дейността (или фрагмент или друг изглед) изтегля данни, записва за изпращане, представя ги, отговаря на потребителски взаимодействия, редактира данни и управлява всички дъщерни изгледи. . . И много пъти много повече. Това е твърде много за обекти, които са толкова нестабилни като Дейности или Фрагменти (просто завъртете екрана и Дейността казва „Чао ...“).
Много добра идея е да изолирате отговорностите на мненията и да ги направите възможно най-глупави. Изгледите (дейности, фрагменти, персонализирани изгледи или каквото и да е представяне на данни на екрана) трябва да носят единствената отговорност за управлението на техните подпрегледи. Изгледите трябва да имат водещи, които комуникират с модела и им казват какво да правят. Това накратко е моделът Model-View-Presenter (за мен трябва да бъде кръстен Model-Presenter-View за да покаже връзките между слоевете).
'Хей, знам за нещо подобно и се казва MVC!' - не мислите ли? Не, MVP не е същото като MVC. В модела MVC вашият изглед може да комуникира с модела. Докато използвате MVP, вие не допускате никаква комуникация между тези два слоя, единственият начин Изглед може да общува с Модел е през Водещ . Единственият, който Изглед знам за Модел това може да бъде структурата на данните. Изглед знаете как например да покажете Потребител , но не знае кога. Ето един прост пример:
Гледката знае, че „аз съм дейност, имам две EditTexts и бутон. Когато някой щракне върху бутона, трябва да кажа на водещия и да предам стойностите на EditTexts . И това е, мога да спя до следващото щракване или водещият да ми каже какво да правя ”.
Водещ той знае, че някъде е изглед и знае какви операции може да извърши този изглед. Също така знаете, че когато получите два низа, трябва да създадете потребителя от тези два низа и да изпратите данни на модела, за да ги запишете, и ако той спести успешно, кажете на изгледа „Показване на информация за успеха“.
Моделът знае само къде са данните, къде трябва да бъдат запазени и какви операции трябва да бъдат извършени върху данните.
Приложенията, написани в MVP, са лесни за тестване, поддръжка и повторна употреба. Чистият водещ не трябва да знае нищо за платформата Android. Това трябва да е чист клас (или Kotlin, в нашия случай) Java. Благодарение на това можем да използваме повторно нашия водещ в други проекти. Също така можем лесно да напишем модулни тестове, като тестваме отделно Модел , Изглед Y. Водещ .
css въз основа на размера на екранаМоделът MVP води до по-добра и по-малко сложна кодова база, като поддържа потребителския интерфейс и бизнес логиката наистина отделни.
Малко отклонение: MVP трябва да бъде част от Чиста архитектура на чичо Боб за да направят приложенията още по-гъвкави и добре проектирани. Ще се опитам да пиша за това следващия път.
Примерно приложение с MVP и Kotlin
Това е достатъчно теория, нека видим малко код! Е, нека се опитаме да създадем просто приложение. Основната цел на това приложение е да създаде потребител. Първият екран ще има два EditTexts (първи и последен) и бутон (Save). След въвеждане на собственото и фамилното име и щракване върху „Запазване“, приложението трябва да покаже „Потребителят е запазен“ и да премине към следващия екран, където се показват запазените име и фамилия. Когато първото или фамилното име са празни, приложението не трябва да запазва потребителя и след това показва грешка, показваща какво не е наред.
Първото нещо, което трябва да направите след създаването на проекта Android Studio е да конфигурирате Kotlin. Ти трябва инсталирайте приставката Kotlin и след рестартиране, в Инструменти> Kotlin можете да кликнете върху „Конфигуриране на Kotlin в Project“. IDE ще добави зависимости Kotlin към Gradle. Ако имате някакъв съществуващ код, можете лесно да го конвертирате в Kotlin (Ctrl + Shift + Alt + K или Encode> Convert Java File to Kotlin). Ако нещо не работи и проектът не се компилира или Gradle не вижда Kotlin, можете да проверите кода на приложението, наличен в GitHub.
Kotlin не само добре си взаимодейства с Java рамки и библиотеки, но ви позволява да продължите да използвате повечето от същите инструменти, с които вече сте запознати.Сега, когато имаме проект, нека започнем със създаването на първия ни изглед: Създаване на потребителски изглед . Този изглед трябва да има функциите, споменати по-горе, за да можем да напишем интерфейс за това:
interface View Както можете да видите, Kotlin е подобен на Java в декларирането на функции. Всички са функции, които не връщат нищо, а последните имат параметър. Това е разликата, типът параметър идва след името. Интерфейсът View не е Android: това е нашият прост, празен интерфейс:
interface Presenter { var view: T? fun onDestroy(){ view = null } } Интерфейсът на Водещ Basic трябва да има свойство тип изглед и поне в метода (например onDestroy), където това свойство ще бъде зададено като null:
interface CreateUserPresenter: Presenter { fun saveUser(name: String, surname: String) } Тук можете да видите друга характеристика на Kotlin: можете да декларирате свойства на интерфейсите и също да внедрите методи там.
Нашите CreateUserView трябва да общуват с CreateUserPresenter . Единствената допълнителна функция, от която се нуждае този водещ, е saveUser с два низ аргумента:
data class User(val name: String, val surname: String) Също така се нуждаем от дефиниция на Model - споменато е по-рано в типа клас:
class CreateUserPresenterImpl(override var view: CreateUserView?): CreateUserPresenter { override fun saveUser(name: String, surname: String) { } } След декларирането на всички интерфейси можем да започнем да изпълняваме.
CreateUserPresenter ще бъде внедрен през CreateUserPresenterImpl :
CreateUserPresenterImpl(override var view: CreateUserView?) Първият ред с дефиниция на клас:
class MainActivity : AppCompatActivity(), CreateUserView { private val presenter: CreateUserPresenter by lazy { CreateUserPresenterImpl(this) } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) saveUserBtn.setOnClickListener{ presenter.saveUser(userName.textValue(), userSurname.textValue()) /*use of textValue() extension, mentioned earlier */ } } override fun showEmptyNameError() { userName.error = getString(R.string.name_empty_error) /* it's equal to userName.setError() - Kotlin allows us to use property */ } override fun showEmptySurnameError() { userSurname.error = getString(R.string.surname_empty_error) } override fun showUserSaved() { toast(R.string.user_saved) /* anko extension - equal to Toast.makeText(this, R.string.user_saved, Toast.LENGTH_LONG) */ } override fun showUserDetails(user: User) { } override fun onDestroy() { presenter.onDestroy() } } Това е конструктор, ние го използваме за присвояване на свойството view, дефинирано в интерфейса.
Основна дейност , което е наше CreateUserView изпълнение, се нуждае от препратка към CreateUserPresenter :
теория на цветовете за графични дизайнери
private val presenter: CreateUserPresenter by lazy { CreateUserPresenterImpl(this) } В началото на примера дефинираме нашия водещ:
override fun saveUser(name: String, surname: String) { val user = User(name, surname) when(UserValidator.validateUser(user)){ UserError.EMPTY_NAME -> view?.showEmptyNameError() UserError.EMPTY_SURNAME -> view?.showEmptySurnameError() UserError.NO_ERROR -> { UserStore.saveUser(user) view?.showUserSaved() view?.showUserDetails(user) } } } Определя се като неизменяем (val) и се създава от мързелив делегат, който ще бъде назначен за първи път, когато е необходим. От друга страна, ние сме сигурни, че няма да е нула (без въпросителна след дефиницията).
Когато потребителят щракне върху бутона Запазване, View изпраща информацията до презентатора със стойности EditTexts. Когато това се случи, потребителят трябва да бъде запазен, затова трябва да внедрим метода saveUser в Presenter (и някои от функциите на модела):
enum class UserError { EMPTY_NAME, EMPTY_SURNAME, NO_ERROR } object UserStore { fun saveUser(user: User){ //Save user somewhere: Database, SharedPreferences, send to web... } } object UserValidator { fun validateUser(user: User): UserError { with(user){ if(name.isNullOrEmpty()) return UserError.EMPTY_NAME if(surname.isNullOrEmpty()) return UserError.EMPTY_SURNAME } return UserError.NO_ERROR } } Lo más interesante aquí es *UserValidator.* Mediante el uso de la palabra objeto, podemos crear una clase *Singleton*, sin preocupaciones de hilos, constructores privados y así sucesivamente. Adicionalmente: en el método validateUser (usuario), existe con (usuario) {} expresión. El código dentro de dicho bloque se ejecuta en contexto de objeto, se pasa con el nombre y el apellido son las propiedades del Usuario. También hay otra pequeña cosa. Todo el código anterior, de enum a *UserValidator*, la definición se coloca en un archivo (la definición de clase de usuario también está aquí). Kotlin no te obliga a tener cada clase pública en un solo archivo (o nombre de la clase exactamente como archivo). Por lo tanto, si tienes algunos fragmentos cortos de código relacionados con (clases de datos, extensiones, funciones, constantes - Kotlin no requiere clase para función o constante), puedes colocarlos en un solo archivo en lugar de propagarlos a través de todos los archivos del proyecto. Cuando un usuario se guarda, nuestra aplicación debería mostrarlo. Necesitamos otra vista: puede ser cualquier vista de Android, vista personalizada, fragmento o actividad. Elige la Actividad. Por lo tanto, vamos a definir la interfaz de*UserDetailsView*. Puede mostrar al usuario, pero también debe mostrar un error cuando el usuario no está presente: ~~~ kotlin interface UserDetailsView { fun showUserDetails(user: User) fun showNoUserError() } Когато се създаде потребител, той се изпраща на UserValidator за да проверите валидността му. След това въз основа на резултата от валидирането се извиква подходящият метод. Конструкцията when () {} е същата като switch / case в Java. Но е по-мощен - Kotlin позволява използването не само на enum или int в ‘case’, но и на диапазони, низове или типове обекти. Трябва да съдържа всички възможности или да има израз. След това покрийте всички стойности на UserError.
Когато използвате изглед? .showEmptyNameError () (с въпросителен знак след изгледа), ние се предпазваме от NullPointer Изгледът може да бъде заменен в метод onDestroy , и с тази конструкция нищо няма да се случи.
Когато потребителски модел няма грешки, той съобщава на UserStore запазете го и след това кажете на View да покаже успех и да покаже подробности.
Както бе споменато по-горе, трябва да приложим някои основни неща:
interface UserDetailsPresenter: Presenter { var user: User? } След това UserDetailsPresenter. Трябва да има свойство на потребителя:
class UserDetailsPresenterImpl(override var view: UserDetailsView?): UserDetailsPresenter { override var user: User? = null set(value) { field = value if(field != null){ view?.showUserDetails(field!!) } else { view?.showNoUserError() } } } Този интерфейс ще бъде внедрен през UserDetailsPresenterImpl . Трябва да презапишете собствеността на потребителя. Всеки път, когато това свойство е присвоено, потребителят трябва да бъде актуализиран в изгледа. Можем да използваме a сетер свойство за това:
class UserDetailsActivity: AppCompatActivity(), UserDetailsView { private val presenter: UserDetailsPresenter by lazy { UserDetailsPresenterImpl(this) } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_user_details) val user = intent.getParcelableExtra(USER_KEY) presenter.user = user } override fun showUserDetails(user: User) { userFullName.text = '${user.name} ${user.surname}' } override fun showNoUserError() { toast(R.string.no_user_error) finish() } override fun onDestroy() { presenter.onDestroy() } } Прилагането UserDetailsView , UserDetailsActivity , Това е много просто. Както и преди, имаме обект на презентатор, създаден от мързеливо зареждане. Потребителят при показване трябва да бъде предаден по намерение. Засега има лек проблем с това и ще го разрешим след малко. Когато имаме намерение потребител, View трябва да го присвои на своя водещ. След това потребителят ще се освежи на екрана или ако е нула, грешката ще се появи (и активността ще приключи, но водещият не знае):
anular divertido showUserDetails(usuario: Usuario) { startActivity(USER_KEY to user) /* extensión anko – empieza UserDetailsActivity y pasa el usuario a USER_KEY in intent */ } Предаването на обекти чрез намерения изисква този обект да реализира интерфейса Parcelable. Това е много 'мръсна' работа. Лично аз мразя да правя това заради всички създатели, имоти, спестявания, реставрация и т.н. За щастие има плъгин подходящ, парцелируем за Kotlin. След като го инсталираме, можем да генерираме Parcelable само с едно щракване.
Последното нещо, което трябва да направим, е да приложим showUserDetails (потребител: Потребител) в нашата основна дейност:
|_+_|
И това е.
Имаме просто приложение, което запазва потребител (всъщност не е запазено, но можем да добавим тази функционалност, без да докосваме водещия или изгледа) и да го представим на екрана. В бъдеще, ако искаме да променим начина на представяне на потребителя на екрана, като например: две дейности на два фрагмента в една дейност или два персонализирани изгледа; промени ще се виждат само в класове View. Разбира се, ако не променим функционалността или структурата на модела. Водещият, който не знае точно какво е View, няма да има нужда от промени.
Имате ли проблеми с развитието на вашите приложения за Android? Вижте тези съвети и техники за оптимизация.Какво следва?
В нашето приложение Presenter се създава всеки път, когато се създава дейност. Този подход или неговата противоположност, ако Presenter иска да продължи чрез случаи на активност, е тема на много дискусии в Интернет. За мен това зависи от приложението, неговите нужди и разработчика. Понякога е по-добре да унищожите водещия, понякога не. Ако решите да продължите да използвате такъв, трябва да използвате много интересна техника LoaderManager За това.
Както бе споменато по-горе, MVP трябва да бъде част от Чистата архитектура на чичо Боб . От друга страна, добрите разработчици трябва да използват Кинжал да инжектирате зависимостите на водещия в дейности. Също така помага за поддържането, тестването и повторното използване на вашия код в бъдеще. В момента Kotlin работи много добре с Dagger (преди официалното издание не беше толкова лесно), а също и с други полезни Android библиотеки.
заключение
За мен Котлин е страхотен език. Той е модерен, ясен и изразителен, докато все още се разработва от велики хора. И ние можем да използваме всяка нова версия на всяко устройство и версия на Android. Това, което ме вбесява в Java, Kotlin го прави по-добро.
Разбира се, както казах, нищо не е идеално. Котлин има и някои недостатъци. По-новите версии на приставките Gradle (главно алфа или бета) не работят добре с този език. Много хора се оплакват, че времето за изграждане е малко по-дълго от чисто Java и apk имат няколко допълнителни MB. Въпреки това, Android Studio Y. Градле Те продължават да се подобряват и телефоните имат все повече място за приложения. Ето защо мисля, че Kotlin може да бъде много приятен език за всички разработчици на Android. Просто опитайте и споделете в раздела за коментари по-долу какво мислите.
Изходният код за примерното приложение е достъпен на Github .
