My goal is to provide an easy way to ensure “clean” data from outside sources. Imagine if the server sends you some JSON like

{“fooArray”:[“thing”, “thing”…] ...}

(but with more fields). And you have some class

DangerousBusinessObject

that you can call validate on that returns

BusinessObject?

, and validate does things like make sure the array isn’t null, has the expected number of params, the params are valid and so forth for each value. Then you can make sure internally everything uses

BusinessObject

and not

BusinessObject?

or

DangerousBusinessObject

, which would be helpful for sort of isolating bad data.

Otherwise you probably need something like effect type system…

The annoying part about this pattern as far as I can tell is defining both

BusinessObject

and

DangerousBusinessObject

which are likely to be similar except most of the fields in the latter are going to be nullable.

But why do you even make such a type? Why can’t you have deserialize and validate in one go?

I guess that’s possible, I usually just think of deserialization as a sort of a “mindless” process that’s just responsible for loading the values into the object.

Heh, although it wasn’t my original intent, it also seems like there could be different levels of validation objects, but that’s probably getting too complicated.

Just slam some validation lambdas into deserialization 🙂

Hmmm… I’ll definitely have to think about that a bit.

Every problem in software development can be solved by introducing one more lambda. Except for the problem of having too much lambdas.

On a similar vein, what is the best way to handle loading multiple objects that reference each other? For example, say I have a list of JSON strings, and the objects they represent can reference each other, but you load them one at a time. When you are loading one and it references another that doesn't exist, what's the best way to handle this?

(I would like to have

val

fields in the objects, so not just setting all the fields to null)

@kirillrakhman: haha, yeah, I've heard about a lot of pain that's coming for us in N. We should definitely all be preparing for that

You should only have to really worry about the deprecation warnings if you were already using out dated methods...

(methods that should have been deprecated a few versions ago)

@evanchooly: Like @dalexander said, we've been using most of Java 7 features on Android for a while. And Java 8 lambdas actually with Retrolambda. And Android is transitioning to OpenJDK so it will be soon 100% Java 8 (including streams).

Then again most of this is moot for people using Kotlin on Android anyway. But the platform is moving pretty fast.

someday i’ll write an android app...

@evanchooly: You arn't missing much

except those massive paydays! amirite?

It's amazing to me how the overlap between back end and mobile developers is close to empty.

Most back end developers have never written a mobile app in their life and most mobile engineers know nothing about databases, clusters, transactions or application servers

anyone here using Android Studio 2.2 Preview 4? I just noticed that soft wraps do not seem to work at all for me, can someone confirm if they happen to have the same problem?

Im fine with writing services for mobile apps, and the code they rely on but all my skills are worth nothing when it comes to UI

@cedric: I've been trying to learn both

Well… THat’s a bummer. Github pages limits rouge to 1.10. No Kotlin markup 😞

How decent is it to be able to share the domain logic with both the backend and the frontend with the fact that the backend is based on Java?

Currently we have PHP (I'm not the judge) but I think it would be nice to have a Java backend

@debug: I don't think there is that much added value to using the same language for front end and back end. However, there is tremendous value in using a statically typed language on both sides.

What benefit do you see with a statically typed language in the backend specifically?

More certainty about correctness, performance, automatic refactoring