Android Programjaim

Android fejlesztes, java, kotlin, web.. miegymas:)

Teszteles androidon #1

2016. augusztus 07. 18:42 - lacas82

Ok ez meg nekem is kozepesen uj, ideje jobban megtanulni. Itt ugye nem a manualis tesztekrol lesz most szo

Javaban ugye unit teszt alatt a junit teszteket ertjuk, amivel metodusokat es osztalyokat tesztelhetunk. 

Altalaban minden osztalyra egy teszt osztaly keszul es minden metodusra egy teszt metodus. Az osztaly mukodese soran a mas osztalyokat mokoljuk. Easymock, mockito etc. 

Unit teszteket altalaban akkor kell irni, ha csapatban dolgozunk. 

Androidon a unit tesztek a jvm en futnak a gepen. Ezt local unit tesztnek is hivjak. Van meg az instrumentation unit teszt. Amikhez az android szukseges mar. 

 A local unit teszt nyilvan gyorsabb, mint a masik, ott ugyanis real eszkozon fut le a cucc. 

Unit tesztek jvm en es android runtime on is futtathatok. De persze van az Espresso, ami egy egyszeru user interface teszt framework

Ha az osztalyaid nem hivjak meg az android apit, akkor ezeket junit al tesztelheted. Hogyha fuggosegek vannak az android apival, akkor egy mocking framework kell, mint pl a Mockito.

Miket kell tesztelni egy android appon?

Az uzleti logikat:

maradek % pedig az UI tesztek

70-80% unit tesztek, hogy meggyozodjunk h. a kodbazisunk stabil

20-30% funkcionalis tesztek, h meggyozodjunk, h. az app tenyleg mukodik

TesztPiramisról

Az abran egy forditott mobil teszt piramis lathato.

A mobil applikációk tesztelése más szoftverekhez képest – mint pl. az asztali és a webes applikációk – olyan teljesen különböző tesztelési tevékenységeket igényel, mint a mozgás, a szenzorok, különböző eszközök és hálózatok. Rengeteg manuális tesztelés szükséges, hogy meggyőződjünk arról, egy mobil applikáció az elvárt módon működik a különböző használati esetek során.

Ennyit az elso reszrol, a masodik reszben bemutatom, hogy android eseteben android studional miket kell beallitani, hogy tesztelni tudjunk..

 

Címkék: teszt junit unittest

RxAndroid - 4. resz - RxBinding

2016. július 06. 14:23 - lacas82

RxBinding, tulajdonkeppen annyi, hogy nem kell listenereket, es hosszu csunya kodokat irnunk, hanem minden View-re, stb-re tudunk aggatni egy Bind-ot, subscribe()-al

példák:

@Bind(R.id.button) Button button; //ez ugye a Butterknife-ot hasznalja

...

RxView.clicks(button).subscribe(aVoid -> onButtonClicked());


...

private void onButtonClicked() {
Toast.makeText(this, "onButtonClicked", Toast.LENGTH_LONG).show();
}

Ha Butterknife-al egyutt hasznalnank, akkor kell a gradle-be egy ilyen is hozza:

 

packagingOptions {
exclude 'META-INF/services/javax.annotation.processing.Processor' // butterknife
}

Hogy ne zavarodjon be a build tole. Amugy meg van annotacios @OnClick Butterknife-ba, tehat ez vegulis felesleges, de van ilyen is. Hurra.

Masik pelda:

RxToolbar.navigationClicks(toolbar).subscribe(aVoid -> onToolbarNavigationClicked());


Azt kell latni, hogy ugyszolvan mindenhez van ilyen subscribe, az android osszes
elemehez, es a design libraryhez is, meg a legujabb cuccokhoz is.

 

Es egy kiforrottabb pelda:

usualApproachEditText.addTextChangedListener(new TextWatcher() {
  @Override
public void beforeTextChanged(CharSequence s, int start, int count, int after) {}

@Override
public void onTextChanged(CharSequence s, int start, int before, int count) {
onNewTextChanged(s);
}

@Override
public void afterTextChanged(Editable s) {}
});

 

Ehelyett is tudunk RxBind-os megoldast:

RxTextView.textChanges(reactiveApproachEditText).subscribe(this::onNewTextChanged);

1 sor az egesz. Hat nem szebb es stilusosabb? Olvashatobb, rovidebb?
Kell ez nekunk? IGEEEEEN

RxAndroid - 3. resz - Retrolambda

2016. július 06. 11:56 - lacas82

Ebben a reszben a lambda-krol lesz szo, azon belul is a retrolambdarol.
Eloszor is miert jo nekunk az RxAndroid, es a lambdak?

Lecsokkenti a kod nagysagat, illetve elkerulheto vele a callback hell.

OK, be kell allitanunk nehany dolgot az android projectunkbe, hogy hasznalni tudjuk a retrolambdat, nezzuk mik ezek.

A root build.gradle-be a dependencybe ezt bemasolni:

classpath 'me.tatarka:gradle-retrolambda:3.1.0'

Ez a library atforditja a lamdba kodot valami olyasmive, amit az android studio is erteni fog.

az app gradle elso soraba pedig ezt:

apply plugin: 'me.tatarka.retrolambda'

majd ezt

android {
...
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}

vegul a retrolambdat

retrolambda {
jdk System.getenv('JAVA8_HOME')
oldJdk System.getenv('JAVA7_HOME')
}

Elvileg ha minden flottul ment es run-oljuk a cuccot pl device-en,
akkor megy, ha nem, akkor kiirja valoszinu ezt:

 

Error:Execution failed for task ‘:app:compileDebugJava’.
> When running gradle with java 6 or 7, you must set the path to jdk8,
either with property retrolambda.jdk or environment variable JAVA8_HOME

Valszeg java7 van beallitva a settings-ben, ezert egyszeru a megoldasa:

File -> Project Structure -> SDK Location -> JDK Location

Itt a JDK7 utvonalat atrakjuk a JDK8 utvonalara. Ezutan mukodni fog.

Ha minden jol ment, akkor bizonyos kodreszleteink elszurkulnek, es kiir ra ilyesmiket:

Anonymous new Action1<String>() can be replaced with lambda...

Alt+Enterre pedig ki is csereli a kodot, azaz egyszerusiti.

Nezzuk milyen volt:

public void listTest() {

String[] manyWords = new String[]{"a", "b", "c"};

Observable<String> oneByOneObservable = Observable.from(manyWords);

Action1<String> action = new Action1<String>() {
@Override
public void call(String s) {
Toast.makeText(mAct, s, Toast.LENGTH_LONG).show();
}
};

Func1<String, String> map = new Func1<String, String>() {
@Override
public String call(String s) {
return s.toUpperCase() + s.toLowerCase() + s.toUpperCase();
}
};

oneByOneObservable
.observeOn(AndroidSchedulers.mainThread())
.map(map)
.subscribe(action);
}

Es milyen lett:

 

public void listTest() {

String[] manyWords = new String[]{"a", "b", "c"};

Observable<String> oneByOneObservable = Observable.from(manyWords);

Action1<String> action = s -> Toast.makeText(mAct, s, Toast.LENGTH_LONG).show();

Func1<String, String> map = s -> s.toUpperCase() + s.toLowerCase() + s.toUpperCase();

oneByOneObservable
.observeOn(AndroidSchedulers.mainThread())
.map(map)
.subscribe(action);
}

 Nezzunk egy masik peldat:

Func1<String, String> toUpperCaseMap = new Func1<String, String>() {
@Override
public String call(String s) {
return s.toUpperCase();
}
};

Ezt eloszor egyszerusiteni tudjuk lambdaval:

Func1<String, String> toUpperCaseMap = s -> s.toUpperCase();

majd:

Func1<String, String> toUpperCaseMap = String::toUpperCase;

RxAndroid - 2. resz

2016. július 04. 12:47 - lacas82

Action1<String> textViewOnNextAction = new Action1<String>() {
@Override
public void call(String s) {
txtPart1.setText(s);
}
};


Kezdjunk is bele! Az Action1 tulajdonkeppen egy hivas/tortenes,
ami nyilvan ismeros lehet ha irtunk mar interface-t generikusan. Ez itt 
egy hivas, ami visszaad egy Stringet esetunkben, de persze a String barmi mar lehet. 


Eddig ugye ezt hasznaltuk arra, hogy a textView-be visszakapjuk a "Hello World"-ot.
De mi van, ha nem a Hello World-ot akarjuk, hanem nagybetukkel a HELLO WORLD-ot?

Akkor letre kell hoznunk egy Func1 nevu metodust:

Func1<String, String> toUpperCaseMap = new Func1<String, String>(){
@Override
public String call(String s) {
return s.toUpperCase();
}
};

Ez ugye nagybetuve alakitja siman, ez egy map lesz. A ket String az input, outputot szimbolizalja.

Nezzuk egyszerubben az Observables-unket:

Observable<String> singleObservable = Observable.just(“Hello, World!”);


Lehetosegunk van a "just" statikus metodust meghivni, ami siman egy shortcut a "Hello World"-re.


Majd osszedrotozzuk:

singleObservable.observeOn(AndroidSchedulers.mainThread())
.map(toUpperCaseMap)
.subscribe(textViewOnNextAction);

 

Az uj dolog itt a map operator! Mi ez? Mielott atdobnank az eredmenyt a subscribernek, meg elvegezzuk rajta a

szukseges modositast, azaz nagybetusse alakitjuk. Majd ezt adjuk vissza. Nagyon sok operator erheto el, ezt egyelore ne is ragozzuk.


Eddig azt lattuk, hogyan lehet egy elemet atadni, de akarmennyit lehet, lassunk peldat List-ekre is mondjuk.

Action1<String> toastOnNextAction = new Action1<String>() {
@Override
public void call(String s) {
Toast.makeText(context, s, Toast.LENGTH_SHORT).show();
}
};

Eddig semmi uj dolog...
Observable<String> oneByOneObservable = Observable.from(manyWords);


vagy

Observable.just(manyWordList);

flatMap

Func1<List<String>, Observable<String>> getUrls = new Func1<List<String>, Observable<String>>() {
@Override
public Observable<String> call (List<String> strings) {
return Observable.from(strings);
}
};

Func2<String, String, String> mergeRoutine = new Func2<String, String, String>() {
@Override
public String call (String s, String s1) {
return String.format(“%s %s”,s, s1);
}
};

Observable.just(manyWordList)
.observeOn(AndroidSchedulers.mainThread())
.flatMap(getUrls)
.reduce(mergeRoutine)
.subscribe(toastOnNextAction);


Teljes forraskod
Címkék: RxAndroid

RxAndroid - 1. resz

2016. július 04. 12:10 - lacas82

Eloszor is a megszokott jutub videjo

 

Ezt a videot valasztottam, mert vicces benne a srac, neha hasonloan gondolkozom, hasonlo szohasznalattal, mint o. Kicsit talan tul sok a "shit" benne. :)

Hogy kezdjunk neki:

https://github.com/ReactiveX/RxAndroid

Android Studio gradle, dependencies:

compile 'io.reactivex:rxandroid:1.2.1'

"Observables and Subscribers. The first ones will emit any number of items to all the Subscribers that are listening to the changes."

Elso korben nezzuk az RxAndroid ket fo pontjat, az Observablest, es a Subscriberst. Magyarul talan megfigyelo, feliratkozo.

Observable.OnSubscribe observableAction = new Observable.OnSubscribe<String>() {
public void call(Subscriber<? super String> subscriber) {
subscriber.onNext(“Hello, World!”);
subscriber.onCompleted();
}
};
Observable<String> observable = Observable.create(observableAction);


Eloszor tehat letrehozunk egy observablet, a fenti modon.
A Hello World 'String'et fogjuk visszakapni ebbol ugye. Azert van mindenhol String.
Az observable barmilyen bemenetu cuccot kisugaroz majd a subscriberre, ami figyeli
a valtozast. Huh nem tudom mennyire ertheto, magyarul megfogalmazni ezt eleg nehez,
de primitiv dologrol van szo.

Ilyenkor meg semmi se tortenik, kell egy Subscriber ugye, amivel feliratkozunk ra.

Subscriber<String> textViewSubscriber = new Subscriber<String>() {
public void onCompleted() {}
public void onError(Throwable e) {}
public void onNext(String s) {
txtPart1.setText(s);
}
};
Subscriber<String> toastSubscriber = new Subscriber<String>() {
public void onCompleted() {}
public void onError(Throwable e) {}
public void onNext(String s) {
Toast.makeText(context, s, Toast.LENGTH_SHORT).show();
}
};


Itt van 2 db Subscriberunk, az elso siman kiloki onNext-re
a Hello World-ot egy TextView-be, mig a masodik egy Toast-ban megjeleniti azt. 

Ok megvannak a Subscriberek, es az Observable, mar csak ossze kene kotozni a kettot.


Viszont azt akarjuk, hogy a Main Thread-en kapjuk vissza a cuccokat, mivel az UI threaden akarunk dolgokat csinalni, a TextView ott van.


observable.observeOn(AndroidSchedulers.mainThread());
observable.subscribe(textViewSubscriber);
observable.subscribe(toastSubscriber);


Azaz, observeOn, hol tortenjen meg, subscribe pedig, hogy mire/mikre iratkozzon fel.

Termeszetesen AsyncTask-eket is kivalthatunk majd ezzel, Thread-eken keresztul, majd a kesobbiekben latunk ezekre peldat.

Bovebb leiras