Android reactive programming with Rxjava
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 46 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/17792 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Berlin |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
droidcon Berlin 20151 / 46
5
7
10
13
16
18
20
21
23
26
31
34
35
36
41
42
45
00:00
Data managementModulo (jargon)Software developerAuthorizationSoftware design patternAndroid (robot)State observerLecture/Conference
00:41
Convex hullComputer programmingUniform resource name3 (number)Android (robot)VoltmeterLevel (video gaming)Mobile appE-bookData managementProjective planeComputer programmingFormal languageProgramming paradigmEvent horizonProcess (computing)Cellular automatonConcurrency (computer science)Android (robot)Lecture/Conference
02:02
Computer programmingWeightMereologyAreaFormal languageIRIS-TVirtual machineRadical (chemistry)State observerImplementationExtension (kinesiology)Computer programmingWeightSoftware design patternLecture/Conference
03:01
DataflowSoftware design patternState observerComplex systemSequenceFront and back endsJava appletScalabilityProcess (computing)MassDataflowServer (computing)State observerLecture/ConferenceComputer animation
03:56
Sound effectPattern languageState observerSpreadsheetTotal S.A.State observerMathematicsMultiplication signCellular automatonEmailPie chartRepresentation (politics)Software design patternQuicksortRandomizationSummierbarkeitLecture/ConferenceMeeting/Interview
05:34
Pay televisionPoint (geometry)MereologySoftware design patternView (database)Server (computing)MathematicsState observerLecture/Conference
06:21
State observerPattern languageElectronic mailing listMobile appStandard deviationAndroid (robot)Personal identification numberPhysical lawMobile appImplementationRevision controlCASE <Informatik>Server (computing)AdditionInstance (computer science)Multiplication signForm (programming)SequenceProcess (computing)Rule of inferenceMathematicsNetwork topologyMereologyMoment (mathematics)Uniform boundedness principleStandard deviation1 (number)State observerElectronic mailing listEvent horizonLecture/Conference
08:39
Mobile appAbelian categoryComputer iconInformationPointer (computer programming)InfinityOptical disc driveBootingInterior (topology)Rule of inferencePhysical lawMoment (mathematics)Loop (music)State observerCoroutineMobile appSequenceRevision controlBoilerplate (text)Point (geometry)Line (geometry)Type theoryControl flowError messageForm (programming)CASE <Informatik>Real numberMetreStandard deviation
10:20
Mobile appInformation systemsDampingElectronic mailing listSequenceMobile appState observerAreaComputer fileElement (mathematics)Error messageException handlingFlow separation
11:58
Level (video gaming)Mobile appWechselseitige InformationUniformer RaumMaxima and minimaPersonal identification numberPhysical lawInterior (topology)Electronic mailing listAndroid (robot)Software testingLine (geometry)Closed setStandard deviationSemiconductor memoryPoint (geometry)Multiplication signState observerView (database)Mobile appLecture/Conference
12:41
LengthBoilerplate (text)BitState observerElectronic mailing listMessage passingVideo gamePoint (geometry)Arithmetic progressionMobile appError messageInformationLambda calculus
13:43
Mobile appGraphical user interfaceVideo gameState observerElectronic mailing listMobile appBitElement (mathematics)Electronic visual displayObject-oriented programmingCodeCondition numberLine (geometry)Lambda calculusBoolean algebraState of matterSequenceLecture/Conference
15:32
Element (mathematics)Software testingSequenceComplete metric spaceInsertion lossSummierbarkeitMeeting/Interview
16:25
ArmMobile appState observerSequenceElectronic mailing listDirection (geometry)Point (geometry)Logic programmingElement (mathematics)Multiplication signJava appletHoaxAreaWhiteboardEvent horizonComputer animationLecture/Conference
17:42
BitExecution unitSample (statistics)Point (geometry)Logic programmingView (database)SequenceOcean currentElement (mathematics)2 (number)Moment (mathematics)Electronic mailing listElectronic visual displayWindowMultiplication signState observerBit ratePerturbation theoryOrder (biology)Medical imagingExecution unitBitTransformation (genetics)Sampling (statistics)MathematicsLecture/Conference
21:01
Amsterdam Ordnance DatumSinguläres IntegralLevel (video gaming)Beta functionMobile appPoint (geometry)Hand fanView (database)CASE <Informatik>Electronic mailing listCodeLine (geometry)Object-oriented programmingFlow separationState observerString (computer science)Multiplication signElement (mathematics)Raster graphicsFunctional programmingSequenceLevel (video gaming)BitInformationMobile appFront and back endsLecture/Conference
23:12
Interior (topology)Metropolitan area networkLevel (video gaming)EmulationRaster graphicsState observerChainLevel (video gaming)Point (geometry)Metropolitan area networkProcess (computing)Functional programmingLecture/Conference
24:01
RepetitionSoftware engineeringData bufferSequenceObject-oriented programmingLevel (video gaming)Process (computing)WordState observerThread (computing)ResultantInstance (computer science)Classical physicsMathematicsMultiplication signTask (computing)Different (Kate Ryan album)Mobile appCASE <Informatik>ChainComputer clusterComputer animation
24:58
Electronic mailing listExecution unitElectronic mailing listCasting (performing arts)InformationBuffer solutionGodRevision controlType theoryLimit (category theory)Form (programming)SubsetMobile appState observer2 (number)SequenceCoroutineOperator (mathematics)Combinational logicInstance (computer science)Single-precision floating-point formatLattice (order)Lecture/Conference
27:05
Execution unitMobile appData typeThread (computing)Android (robot)String (computer science)State observerNumberFood energyElement (mathematics)Object-oriented programmingFunctional programmingProcess (computing)Multiplication signElectronic mailing listAndroid (robot)InformationLambda calculusJava appletMobile app
28:42
Android (robot)Thread (computing)Data typeMobile appAsynchronous Transfer ModeHierarchyView (database)Order (biology)Ideal (ethics)Process (computing)Crash (computing)CASE <Informatik>Real numberTrailSet (mathematics)Asynchronous Transfer ModeView (database)Scaling (geometry)Thread (computing)HierarchyReading (process)MiniDiscMultiplication signSoftwareAndroid (robot)Scheduling (computing)Mobile appElectronic mailing list
31:01
Android (robot)Thread (computing)View (database)HierarchyCurve fittingSynchronizationReading (process)GodResultantMiniDisc3 (number)MeasurementExtension (kinesiology)Task (computing)Line (geometry)Process (computing)Thread (computing)View (database)Key (cryptography)Latent heatAndroid (robot)State observerScheduling (computing)
32:10
Android (robot)Thread (computing)Mobile appFrame problemComputational physicsRootBootingComputer-generated imageryLambda calculusThread (computing)Service (economics)ScatteringCartesian coordinate systemSkeleton (computer programming)Dynamical systemProcess (computing)Domain nameControl flowMultiplication signTrailEvent horizonSystem programmingArrow of timeProduct (business)Frame problemScheduling (computing)NeuroinformatikView (database)Lambda calculusBytecodeBoilerplate (text)Mobile appReal numberMathematicsLecture/ConferenceMeeting/Interview
34:40
Mass flow rateUniform resource nameRepresentational state transferSocial classLevel (video gaming)LogarithmMalwareCartesian coordinate systemMultiplication signProfil (magazine)Representational state transferSummierbarkeitNumberData managementFile viewerObject-oriented programmingResultantMappingElectronic mailing listDependent and independent variablesCuboidStaff (military)Interface (computing)Open setImplementationService (economics)Bit rateWeb pageMathematicsBootingCycle (graph theory)Universe (mathematics)Medical imagingStack (abstract data type)Thread (computing)Square numberWeb 2.0Buffer overflowJava appletScheduling (computing)Maxima and minimaView (database)Keyboard shortcutSource code
37:42
Uniform resource locatorMobile appError messageInformation systemsOvalExecution unitExt functorMultiplicationRepresentational state transferSocial classLevel (video gaming)LogarithmBuildingInstance (computer science)Wide area networkData managementPresentation of a groupStandard deviationBoilerplate (text)Arithmetic progressionElectronic mailing listMessage passingPressureView (database)Bit
38:38
Error messageDigital filterDependent and independent variablesComputer iconMobile appUniform resource locatorComputer-generated imageryPhysical lawEquals signOpen setSequenceThread (computing)Presentation of a groupSoftwareSystem callScheduling (computing)Electronic mailing listComputer iconView (database)MappingProfil (magazine)Line (geometry)Moment (mathematics)BitGame theoryLevel (video gaming)WordService (economics)UsabilityLogic programmingScaling (geometry)Raster graphicsString (computer science)Lecture/Conference
40:39
Operator (mathematics)State observerAreaReverse engineeringData miningEvent horizonSequenceLecture/Conference
41:13
Digital filterSequenceWater vaporWechselseitige Information3 (number)Special unitary groupDataflowWater vaporLecture/Conference
Transcript: English(auto-generated)
00:05
OK, your attention, please. Hi, everybody. My name is Ivan Margielo. I'm an engineer from Southern Italy. So most of the talk will be in English and hand moving.
00:22
Yeah. I'm the author of RxJava Essentials. It's a step-by-step journey from the beginning of observer pattern and back to Android and Android development.
00:40
It has been published last week. You can check it out. My most popular app is Kratis e-books for Kindle, formerly Kindle Kratis by Amazon. We had a small discussion about trademarks. But still, it's a weekend project. It's very popular in Germany.
01:02
It's 100,000 downloads right now. And it's a companion app for Kindle users. And it's all about free books. The e-book, no, but probably it's $20 or something. You can afford it. You're a project manager.
01:20
Come on. I'll buy as a company. You know, charge them. For the next half hour, mostly, we are talking about Android reactive programming with RxJava. Because as Android developers, we have few issue with concurrency, with least
01:44
events and stuff like that. And RxJava can be really useful. It's a switch. It's really a paradigm switch. But you can reuse it in a lot of languages because they are basically compatible with everything.
02:04
If you're iOS, you can use React to Cocoa or Ruby or .NET or whatever. You're just Rx and your language, that's it. There is Rx Scotland too for the brave people.
02:21
Reactive programming is a new idea. It's based on the observer pattern. It's probably 40 years old, so it's quite new. It was made popular by Eric Meyer in Microsoft. Thank you for the truck, guys.
02:41
He created the reactive extensions for .NET and then Ben Kristensen at Netflix ported it to RxJava. It's an implementation. It's not a port. They were targeting the virtual machine, so you can use it with Scala, Closure, or Groovy, whatever.
03:01
And it's a huge effort, and it's a really great solution for scalability and complex systems on a Java backend side. On Android, we are using it lightly. It's not that complex. You will see.
03:21
RxJava is based on a concept of data flow. Basically, it's like thinking about data as a sequence. And you can imagine it as a river that flows, and you can filter it, merge it,
03:40
and you can combine it through rivers. At the end, you will get the river you need, and it's based on the observer pattern, so it's nothing new. We use it every day and then forced the push against the pool concept because you don't ask and wait for the data.
04:06
You just politely subscribe and react when the data come in. The observer pattern is basically nothing new. We use it every day. It's the gang of four pattern, basically, a common concept.
04:26
You just observe something that can change over time, and you just react when the change happens. We don't check our mail every time.
04:40
We just get the notification. So they push the data to us. It's the same as the spreadsheet, is the popular example. We have this total cell, and we update a few values and the total cell updates because we expect it,
05:00
because we are not updating the cell manually every time. We are not checking if everything has changed. We just expect that the value updates. As spreadsheets main example, we have the concept of everybody can observe changing source and represent the data as he likes.
05:26
So for instance, we can have a pie chart or bar chart. We are observing the same amount of data and representing. So the pattern enforce the coupling of stuff.
05:45
RxJava implements the server pattern. It's an enhancement, basically, because it adds a few more methods. We have four players. The observable, that's the entity that changes,
06:01
or generates new values, new items. It's the, let's say, generating the active part. Then we have observer and subscriber, that they are the passive from a subscription point of view,
06:20
because they subscribe to the observable and react when the data changed. Basically, we have the fancy one, the subject that can be at the same time observable and observer. It's useful, for instance, to create edge cases or custom event bus,
06:43
or new version of the observable that you already have. It's really handy. The moment you get it, you figure out what scenario you can exploit and use it.
07:03
Basically, the observer and the observable communicate using three methods. Our next, onError, onCompleted. I'm really scared of this animation thing, so I'm checking that. Basically, we have the onNext method that
07:23
is fired when we get a new item from the sequence. The onError, and basically, that's the one that is compliant with the Java observer implementation. New ones are onError because stuff can go south,
07:43
and onCompleted because we want to get a notification when the sequence is over and we are not expecting any more items. So this is the fanciest thing ever. But it gets you the idea that stuff comes from the observable during time,
08:05
and every time you get a new item, you get it in your onNext method and you use it. So yeah, obviously. We are going to create,
08:21
this is the example app that we are using to show off a few methods. It's a standard app. It's a bit material-ish. It's using a RecycleView and the list of my installed apps. Nothing fancy. First thing first, we create the observable.
08:42
Can you read it? Say yes, please. It's on purpose. It's verbosely on purpose because I want to show a real example, real leash. So we create a new standard method and we are returning an observable of the item that we expect.
09:03
Then we use the create method to create our routine, and in this case, we are fetching the installed apps list, and we create a loop over the list, and the moment we have a new object that we want to emit,
09:25
we call subscriber.onNext, and the moment that we don't have more items, we just complete the sequence. We are doing it in a for loop. You are not doing it in a for loop, but it's for the sake of the example.
09:43
Let's show how a normal routine can be converted in RxJava routine. So you just emit a new item with the onNext. You could use onError at some point if you have some try-catch something that can explode.
10:03
This is the version without retro lambda, so you can appreciate the boilerplate. You can appreciate a few types, something more lines. So now we have created our observable from scratch,
10:23
but I already have my apps list. So what if I already have the sequence somehow, I have a list and observable.from. We pass a list and we have an observable, we can subscribe.
10:42
I don't have a list, I have three items and I want to emit them in a Rx-ish observable sequence. How I do it? I want just emit them, and there is observable.just. So we have our list,
11:02
we are basically creating for the purpose. We are getting three elements, three of them, and we are using just to emit them, and we have an RxJava sequence. What if I want an observable that
11:22
emits nothing and completes normally? Empty. What if I want an observable that does nothing, emits nothing and never complete? Never. What if I want an observable
11:45
that emits nothing and goes on error or throws an exception? You know conventions. You expect that. Yeah, we were discussing why and what the reason,
12:02
throw never, it's the testing purpose. I want to test as some timeout goes off some point, and I will need something that doesn't emit and doesn't close. So never could be useful or throw. Whatever, you can do whatever you want.
12:21
So we have a few lines of standard Android stuff. We have the RecycleView, we have the adapter, we have those fancy swipe refresh layout or rocket science, and we have our observable from apps, we subscribe and we provide an observer. Yes. What's an observer?
12:44
The observer is a bit of boilerplate because we are not fully compliant to retrofit, so to retro lambda for this talk. So the observable, new observer of app info. He has three methods, the standard one.
13:04
Or next, we are getting the app info, we are adding the app info to the adapter, and we are updating the adapter. On completed, we stop the refreshing progress bar and we show a fancy toast message.
13:20
On error or something went wrong and we are stopping the progress bar and we are showing the toast. So here is the list. Piece of cake. Yes. What's the point? It's just a new thing to learn and is showing a list.
13:44
But life is funny, so we are here, we have our list, we subscribe, we have the observer, everything is fine, we are happy. Then marketing guys kick in and we go the change request.
14:01
We want only the apps that start with C. We want to change as less as possible, so we trust in RxJava and we start finding out few methods that are cool.
14:21
Filter. Basically, we are using a bit on retro lambda because we like the fancy arrow, and we are filtering. Filter just return a Boolean, it just check condition and propagate to the observer only the items that are fine with the condition.
14:48
The observer is always the same, he's not aware of anything. He's just waiting for AppInfo objects and display them. So we have a new filter collection with one line of code.
15:06
So what if we want just three elements from the sequence? Guess what? Take three. We change one line, the subscriber always the same.
15:22
Take three. What if we want last three elements? Go on. Guess, try to guess. Try to guess. You're already skilled.
15:44
Yeah, it's for the testing or scientific thing and it's no Boopya tester, it's research. Take last, there's a bunch of filtering methods. You could use skip.
16:00
Skip three because you know that your first element of the sequence is some kind of check element. It can happen, you will ignore it, and you just say skip one or skip last if you know that your sequence complete with a check value or something, you skip it.
16:23
So I hate duplicates. How can we be sure that we are processing one element once? It's one time. The observer, he doesn't know anything, he's just react so we don't know where the data are generated,
16:40
where the data are emitted, when the sequence will complete. We want something that filter out the duplicates. For the example, we don't have duplicates in our app list so we are creating it. We are creating a fake full of
17:00
duplicate sequence with direct Java because why not? We take three, we repeat three. Now we have a nine element sequence full of duplicates. At this point, we can search a method that will get rid of the duplicates. Distinct, piece of cake.
17:22
The observer is still the same, it is the poor guy and this scenario is the poor guy. Basically, it's Italian. He knows nothing. It's just shut up and display the thing. I'm being racist but I'm Italian now so I'm loved. Distinct will work on
17:41
completed sequence because it's from a logical point of view, if I have to get rid of duplicates. But a new scenario comes in. Ongoing sequence. I have this temperature sensor in this room that is emitting the current temperature of this room.
18:04
So I'm getting probably 25 here or more. It's hot. For our American audience, it's 77. It's hot. Not hot like me but hot. So it's time-dependent.
18:21
Every second, we are getting a new value and we are displaying the value on a small display. But we are going cheap. So we are kind of trying to save resources because everything is expensive
18:40
and we don't want to over refresh the display with 25, 25, 25, 25. We need something that will filter out the duplicates but how? It's an ongoing sequence.
19:02
This thing nothing changed. It will listen, mirror the observable and give you only the new value. So you will just wait for the new value and the moment it goes to 24 or 26, we fire on next, he fires on next.
19:22
I don't know anything. And we can subscribe and we can update the display less often, just less often. We are saving resources.
19:41
Loosen it up a bit. Yeah, we are getting the one value every second. Do you think the temperature will change so quickly? No. So we can change somehow the emission rate.
20:01
Guess, sample. Sample creates a time window. You can specify the amount and the unit, time unit and it will emit the last item from the original subject, from the original observer in the time window.
20:21
So you are getting only one item every 30 seconds. Then we could concatenate this thing until changed and we will get probably one element every 10 minutes because it's not changing but we are not stressing with every second.
20:43
Sample take the last throttle first take the first because there is everything in RxJava. If you need the first element of the window, you use throttle first. Now what?
21:00
Transforming. We have our fancy list. It's piece of cake, it took five lines of code and now we have the marketing guys. So they decided that from a marketing point of view, the list has to be changed somehow in lowercase names list.
21:24
So we don't want to change so much code. We want to apply a function to every element emitted from the original observer. We want to map the item.
21:41
Cool concept, huh? So basically we take the element that is emitted from the observable, we chew it somehow and we return the item to the observable sequence.
22:00
It's one line of code and we got the new lowercase. Map is cool because it's taking app info object but it could return everything. So most of the time we are working what we have on Android mobile because probably the backend
22:23
is already there so we are not in charge or changing stuff. What if we just want the list of names? We could use map to extract the name and instead of return app info object, we could return the string.
22:42
The observable course will change. We will be observing a string sequence but still we were using, our original object is a apps list. What if we want the bitmap, just the bitmap?
23:00
We want to observe a bitmap sequence. We take the same list, we extract the bitmap from the object and we return the bitmap and now we have an observer that can change and use just the bitmap list.
23:21
RxJava is a bunch of transforming functions. FlatMap is the famous one. It's kind of tricky to get it because it's like map but it's returning an observable.
23:41
Basically if we start using RxJava, we get at some point that we have a few methods that are small routine because they are testable and they are returning an observable. So how we chain an observable in an observable sequence?
24:06
We use FlatMap. So basically when we are attaching FlatMap to an observable that we have, we are passing the object. It will work on the object, process the object
24:21
and return an observable of some kind. We are chaining observable. That it's unbelievable for a AsyncTask word because we can chain AsyncTask or stuff like that. But FlatMap has this edge case and for instance it interleave the result
24:43
because every observable could run on a different thread. So RxJava just gives you concatMap. That solved the issue because there is a method for that. There is an app for that back in time and there is a method for that now.
25:01
Transforming, easy one, cast. Cast we have to somehow cast every item we get from a list to a new type. Cast and the type. For some reason we need to observe a subset of item in form of a list. We use buffer.
25:22
Buffer mirrors the original observer and gives you back list of this example tree, app info for instance. If we apply it to the previous example. So basically the sky is the limit.
25:43
Combining example we have our app list as an observable list and then we create a reverse version. How can we merge two observable that basically are emitting the same kind of item,
26:00
app info? We don't want to change the observer because it's the poor guy. So what? We are merging two observable. Oh my God. Merge, you know. It's like COBOL, just use English.
26:20
We are creating a new observable, merging two observable. Our observer is not changing and now we have one single emitting sequence. Fancy one. We are introducing a new operators interval.
26:43
We have two different observable. It's our list and the second one, TikTok. It's emitting along every second. It's just a dynamic observable. It's for the purpose.
27:03
Now we have a fancy update title routine. Takes the number and create a new string with the number at the name and return an app info object. How we combine everything together.
27:21
We use zip. Zip takes up to nine observable and mirror them and pass the new, the last unzipped emitted item to the function. So basically this is the fancy Java eight something syntax.
27:45
It comes with retro lambda. Basically we have two observable, a function that takes two element and return app info object. The observer is always the same.
28:04
Now, Android. It's a bit ugly but serves the purpose. Our list fetches stuff from shared preferences.
28:21
It could be interesting, yes. It's RxJava. Yes, works. Could be obviously better because we are instantiating Gzone every time. So it's just for the example. Everything is fine.
28:40
We are using RxJava. We feel very, very, very, very, very comfortable with it and then we enable strict mode. Strict mode just throw out this read violation. Basically we are doing stuff on the main thread.
29:02
We are reading from this on the main thread and we are losing 253 milliseconds to read the list. So that's the main problem. UI thread is the main thread is the UI thread. If you do stuff on the main thread,
29:21
you slow down the UI. Animation starts to suck, stuff like that. So we need some way to do the work away from the main thread. We could use AsyncTask. Please leave the room. We are using RxJava because there is a method for that.
29:43
We have schedulers. We don't do multi-threading manually. Come on, loaders, AsyncTask, threads. No, it's not 1995. So we have schedulers. RxJava gives you schedulers. This case schedulers.io.
30:01
It's based on a pull thread. So Netflix handled the thing, I don't care. I have a daily job, you know, I don't. And basically the thread pool increase the size, decrease the size. Every time we need to do something that is IO related, reading from network,
30:20
from a database or from the disk or whatever, we can use a scheduler.io. We subscribe on the scheduler. So we ask to RxJava to do the routine, the stuff and get the apps list on a different thread.
30:42
That is supposed to be the IO thread or scheduler, I mean. We are happy, we run the app, and the app crashes. Obviously, only the original thread that created the view hierarchy can touch its view because it's Android. Android, back again to Android. We are doing stuff on a different thread
31:01
and we are trying to update the recycle view from a thread that is not the UI thread. So, you know, it's kinda getting tricky because we have to do the job on one thread, somehow come back with a result on another thread
31:21
that is the UI thread. Oh my God, probably the async task is the answer. And no, because we have observer observe on because there is a method for that. So thanks to RxAndroid, we have a scheduler specific for Android that let us get the result
31:43
on the main thread. So basically in four line, we are fetching the stuff from the disk using a different thread. But when the data come in, we want it on the main thread
32:02
because we are updating the UI. That's it. Piss off cake. Read from here using this thread and when you have the data, I'm here on the main thread and waiting politely.
32:23
This is the pointless one. But we are generating a new observable that before emitting something, just does a few of nonsense, math things, just waste time.
32:42
We are on the main thread, so we got the fancy dialogue. And if we are lucky, we got the dialogue. If we are lucky, the system is complaining about we are skipping frames how there was no tomorrow
33:02
because we are blocking the main thread. But it's not a UI thing. So scheduler IO won't serve the purpose. So yeah, we have other schedulers. So if you have to do computational things,
33:23
we have computation scheduler. If you want to execute something now, we have immediate scheduler or we have new thread scheduler because you just want a new thread. So schedulers dot computation, schedulers dot new thread,
33:44
schedulers dot trampoline. If you want something queued on the current thread, could be useful. There is a method for everything. So real world app.
34:01
We are using a retro lambda. I like the arrow. I don't care about the mess it does with a byte code. I like less boiler plate. I'm using retro lambda in huge application in production for huge sports event. It's forking. I don't care about how they do stuff.
34:23
I have a daily job. I need to be on the spot. I don't care about stuff. I'm using butter knife because I hate that fine view by D. I can't stand it. I'm using Lombok. I don't care how it does stuff
34:42
because I'm too old to create manually getters and setters. Come on, I'm too old. I'm using retrofit because it's the only way we can properly communicate with the REST API. Thank you guys at Square and let's hope Google never buy you. I'm using universal image loader
35:02
because work serves the purpose. You can use Picasso. You can use Frisco. It's just an image loading application. This is the application. It's kind of easy things. List view or cycle view or whatever. We are fetching data from Stack Overflow.
35:22
We are displaying the picture, name, reputation, number, city and we are fetching the forecast from open weather map API. We are attaching a listener.
35:41
If the user tap one of the item, if the Stack Overflow user has a web page, opens the profile or it opens the Stack Overflow profile. So we have retrofit. Retrofit has a brilliant implementation. They just map the REST API to a Java interface
36:04
you basically that's it. They support RxJava out of the box because they are smart people. I mean, why not? So we are passing the, we are mapping the response to a Java object.
36:22
I'm too old for creating the objects manually. So we are using JSON schema to POJO because I have not so much time. And that's it. So we go to our API manager for Stack Exchange.
36:43
We create the minimum thing for retrofit. REST adapter, we bind the service, the interface we had and then we provide get most popular SO users method. I like names, you know, there.
37:01
The first thing of documentation is method names. Basically we are wrapping the API because we want to kind of shield it and most of all because we are getting a response that it's not perfectly fitting our needs.
37:20
We are using a list of user. And basically we are getting the stuff, we are mapping the observable. So we are extracting the user list. We are working on a scheduler IO and we are getting back the result on the main thread.
37:42
Piece of cake. It's an activity standard that I get rid of all the boilerplate. I just want to point out that it's a normal recycle view, adapter and swipe. And we have the refresh list method. Basically we are getting the API manager somehow,
38:01
use dagger two. We are getting the users, we stop the progress bar, we update the adapter or if something goes wrong we just print a message and we stop the progress bar.
38:22
Now the weather thing. Same as the stackers exchange thing, we create a manager because stuff is more organized. Don't create a single like that. Use dagger, it's just for the purpose of the presentation.
38:41
We have the get forecast by city method that basically wrap the API, use a scheduler IO because it's a network call and we get the stuff on the main thread. We update our adapter for every user we put in the list.
39:01
We query the forecast service. We filter for null, could happen. Actually it happened. We filter again, we don't need the weather if the size is not, no it has to be greater than one.
39:23
We could use one line, but it's, you know. And then we concat a new observable because we are reactive, so we are fetching the forecast, the bitmap using an observable method that takes a string and gives back a bitmap.
39:46
We want to chain everything together so we flat map. We make sure that we are working on the scheduler IO, we get the stuff on the UI thread because we are changing the view. We get the icon, we set the icon. Something goes wrong, we log it.
40:04
And we have it. Rx Android perks. We can attach listener to a view with view observable dot clicks, it's useful.
40:20
The moment we have the profile, we open the profile, the moment we have the viewer, there's nothing. Yes. We open the stack exchange thing. So basically it was, short presentation, sorry. We have the amount of methods that it's unbelievable.
40:43
There is a method for everything. So I could talk probably for two days, you will kill me at the end. But the thing is that RxJava gives you the opportunity to create your own operator. So it really could be endless.
41:01
There is an operator for everything. The mind switch is that you have to think through observable sequence like water, like rivers. You can create, you can filter a river, you can transform a river, you can combine two rivers into one and it will still flow. In the end, it will be the river you want it to be.
41:24
Be water. Thank you everybody. Thank you.